Der Under-Attack-Modus von Cloudflare zeigt jedem Besucher eine Zwischenseite, bevor die eigentliche Seite geladen wird.1 Die Prüfung setzt voraus, dass der Browser JavaScript ausführen kann,1 und Cloudflare warnt, dass der Modus „einige Aktionen auf Ihrer Domain“ beeinträchtigen kann, etwa API-Traffic (Originaltext: „may affect some actions on your domain, such as your API traffic“).2 Für einen Ansturm von Bots auf normale Seiten ist das ein schnelles Mittel. Für Ihre App-API, Zahlungs-Webhooks und andere Server-zu-Server-Aufrufe ist es ein Risiko, und gegen Angriffe, die den Edge umgehen oder die Prüfung bestehen, hilft es nicht. Cloudflare empfiehlt, den Modus nur zu nutzen, wenn eine Website unter einem DDoS-Angriff steht;2 eine feste Dauer nennt die Dokumentation nicht.
So schalten Sie ihn ein und wieder aus
Für die ganze Domain aktivieren Sie den Modus im Dashboard: Domain wählen, Overview, in der Seitenleiste „Quick Actions“ den Schalter „Under Attack Mode“ einschalten.1 Per API setzen Sie die Zoneneinstellung security_level auf under_attack.3
# aktuellen Wert merken
curl -s -H "Authorization: Bearer $CF_API_TOKEN" \
"https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/security_level"
# Modus einschalten
curl -s -X PATCH -H "Authorization: Bearer $CF_API_TOKEN" \
-H "Content-Type: application/json" \
--data '{"value":"under_attack"}' \
"https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/security_level"
Notieren Sie den vorherigen Wert, bevor Sie schalten. Laut Cloudflares Dokumentation hat der Security Level im alten Dashboard den Wert „Always protected“ und lässt sich dort nicht ändern; das neue Dashboard und die API verwenden den Security Level als einstellbare Zoneneinstellung, und „Always protected“ ordnet die Dokumentation keinem API-Wert zu.2 Zurückschalten sollten Sie deshalb auf den Wert, den Ihr erster Abruf geliefert hat, nicht auf einen geratenen. Das API-Token braucht Schreibrechte für Zoneneinstellungen.
Was der Modus bei Ihrer Anwendung kaputt machen kann
Server-zu-Server-Aufrufer können eine Browser-Prüfung nicht lösen. Cloudflare nennt API-Traffic als betroffen;2 dass Zahlungs-Webhooks, Mobile-App-Aufrufe, Uptime-Monitore und Feed-Abrufe scheitern können, ist unsere Schlussfolgerung aus der dokumentierten Funktionsweise, keine Aussage der Dokumentation. Prüfen Sie nach dem Einschalten deshalb gezielt: Rufen Sie einen Ihrer API-Endpunkte ohne Browser auf, sehen Sie nach, ob Ihr Zahlungsanbieter Webhook-Zustellungen als fehlgeschlagen meldet, und lösen Sie eine Testbestellung aus.
Ausnahmen richten Sie so ein: Für Under Attack selbst nennt Cloudflare eine Configuration Rule, die den Modus für API oder andere Teile der Domain ein- oder ausschaltet.2 Für Challenge-Regeln der WAF empfiehlt Cloudflare eine Skip-Regel für bekannten Traffic, die vor der Block- oder Challenge-Regel stehen muss, die sie umgehen soll.4 Begrenzen Sie solche Ausnahmen auf den konkreten Pfad.
Nur den betroffenen Pfad schützen
Wenn nur ein Teil Ihrer Seite angegriffen wird, schalten Sie den Modus nur dort ein. Cloudflare zeigt das mit einer Configuration Rule, die auf den Pfad /admin passt und „I'm Under Attack“ aktiviert.1 Configuration Rules gibt es in allen vier Tarifen, im Free-Tarif bis zu 10 Regeln.5
Die Alternative ist eine WAF-Custom-Rule mit der Aktion Managed Challenge für genau die teure Anfrageform. Cloudflare nennt als Obergrenzen 5 Regeln im Free-, 20 im Pro-, 100 im Business- und 1.000 im Enterprise-Tarif; im Free-Tarif sind alle Aktionen außer Log verfügbar, reguläre Ausdrücke erst ab Business.6
(http.request.uri.path eq "/suche" and http.request.uri.query ne "")
Für eine WAF-Custom-Rule mit dem Ausdruck oben wählen Sie als Aktion Managed Challenge. Davor, an erster Stelle, steht eine Skip-Regel für Pfade, die nie eine Challenge sehen dürfen, zum Beispiel (http.request.uri.path eq "/api/webhooks/payment"). So trifft die Challenge nur Aufrufe mit Query-String auf /suche, und Besucher der übrigen Seiten merken nichts. Passen Sie Pfad und Bedingung an Ihre Anwendung an, nachdem Sie in den Cloudflare-Analysen gesehen haben, welche Anfragen die Last tragen; der Ausdruck ist eine Vorlage, kein Rezept für Ihren Shop.
Ein Ablauf, der Ihnen Fehlentscheidungen erspart
Schalten Sie nicht reflexhaft die ganze Domain um. Ein Ablauf, der sich bewährt, wenn Sie unter Druck stehen:
- Zuerst sehen, was die Last trägt
Öffnen Sie die Cloudflare-Analysen und die Security Events. Welche Pfade und Query-Formen machen den Großteil der Anfragen aus, und welche davon sind auf Ihrem Origin teuer? Notieren Sie Zeit und Befund in UTC.
- Ausnahmen vorbereiten
Listen Sie alle Pfade auf, die von Maschinen aufgerufen werden: Zahlungs-Webhooks, App-API, Feeds, Monitoring. Legen Sie die Skip- oder Configuration-Regel dafür an, bevor Sie die Challenge aktivieren.
- Eng einschalten
Aktivieren Sie die Challenge zuerst nur für den betroffenen Pfad. Erst wenn das nicht reicht, nehmen Sie die ganze Domain.
- Wirkung prüfen
Sinken die Fehler am Origin? Kommen Webhooks an? Zeigen die Security Events Challenges, die echte Kunden getroffen haben? Wenn die Last am Origin nicht sinkt, rechnen Sie mit einem der Fälle weiter unten, statt die Einstellung zu verschärfen.
- Zurückschalten und dokumentieren
Setzen Sie den notierten Ausgangswert wieder ein, sobald der Angriff vorbei ist, und halten Sie Zeitpunkte und Änderungen fest. Ein vergessener Under-Attack-Modus kostet Sie Besucher, die keine Prüfseite sehen wollen.
Wann der Modus nicht reicht
Wer den Origin direkt anspricht, sieht die Prüfseite nie. Cloudflare schreibt selbst: Wer die IP-Adresse Ihres Origin-Servers herausfindet, kann Anfragen direkt senden und damit Cloudflare und alle seine Schutzfunktionen umgehen.7 Dann hilft keine Regel am Edge, bis der Origin nur noch Verbindungen von Cloudflare annimmt.
Auch wenn der Traffic die Prüfung besteht, bleibt die Last. In einem von uns dokumentierten Fall auf einer selbst betriebenen Vergleichsplattform kamen in der stärksten Stunde des erfassten Zeitraums laut Cloudflare-Schätzung rund 74.400 Anfragen an, im Schnitt etwa 21 pro Sekunde, also wenig Volumen. Die Anfragen verteilten sich dort auf so viele Adressen, dass am 6. Oktober in den ausgewerteten Datensätzen im Schnitt nur 1,28 Anfragen auf eine Adresse entfielen. Die Standard-Bot-Challenges von Cloudflare waren durchgehend aktiv und behandelten nur einen kleinen Teil der Anfragen, einige tausend pro Tag. Eine Regel am Edge fing etwa die Hälfte der filterförmigen Datensätze ab (50,6 % zwischen dem 5. Oktober 18:00 und dem 6. Oktober 16:59 UTC), die andere Hälfte änderte ihre Merkmale und kam durch. Ob der Under-Attack-Modus in diesem Fall mehr bewirkt hätte, geben unsere Daten nicht her; wir haben ihn nicht isoliert ausgewertet. Die Fehler der zweiten Welle endeten erst, als Anfragen mit der Angriffsform direkt vor der Anwendung ohne Anwendungs- und Datenbankarbeit beantwortet wurden: In den folgenden rund 23 Stunden gab es 295.587 solcher statischer Antworten und einen einzigen Fehler am Origin. Erkennung allein reichte nicht; entscheidend war, dass erkannte Anfragen nichts mehr kosteten.
Zwei weitere Grenzen: Ob Cloudflares verifizierte Bots, etwa der Googlebot, vom Under-Attack-Modus ausgenommen sind, beschreibt die Dokumentation nicht (Stand 12.11.2026): Weder die Seiten zu Security Level und Under Attack mode noch die zu Verified Bots und Challenges sagen es. Wir behaupten deshalb weder das eine noch das andere; sehen Sie in den Security Events nach, ob Crawler Challenges erhalten haben, bevor Sie annehmen, Ihr Ranking sei geschützt. Und eine Notfall-Telefonnummer von Cloudflare gibt es laut Support-Dokumentation nur im Enterprise-Tarif.8
Wenn Sie bei Origin und Anwendung Unterstützung möchten: Wir arbeiten dort, nicht am Edge allein.
Quellen
- Cloudflare: Under Attack mode (Referenz). https://developers.cloudflare.com/fundamentals/reference/under-attack-mode/, geprüft am 11.11.2026
- Cloudflare WAF: Security Level. https://developers.cloudflare.com/waf/tools/security-level/, geprüft am 12.11.2026
- Cloudflare API: Zone settings. https://developers.cloudflare.com/api/resources/zones/subresources/settings/, geprüft am 11.11.2026
- Cloudflare: Challenges, Fehlersuche. https://developers.cloudflare.com/cloudflare-challenges/troubleshooting/, geprüft am 11.11.2026
- Cloudflare: Configuration Rules. https://developers.cloudflare.com/rules/configuration-rules/, geprüft am 11.11.2026
- Cloudflare WAF: Custom rules. https://developers.cloudflare.com/waf/custom-rules/, geprüft am 11.11.2026
- Cloudflare: Authenticated Origin Pulls. https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/, geprüft am 11.11.2026
- Cloudflare: Contacting Cloudflare support. https://developers.cloudflare.com/support/contacting-cloudflare-support/, geprüft am 11.11.2026