Kunde von Cloudflare blockiert: welche Regel greift und wie Sie keine Bestellungen mehr verlieren

Ein Kunde schreibt Ihnen, Ihr Shop "lässt ihn nicht rein". Er hat eine Cloudflare-Seite mit einem vierstelligen Code gesehen, aufgegeben und woanders gekauft. In Ihren Server-Logs steht nichts, denn die Anfrage ist nie an Cloudflare vorbeigekommen. Das passiert bei WooCommerce-Shops, bei WordPress-Seiten, die Anfragen sammeln, bei Headless-Frontends auf Astro oder Next.js und bei jeder eigenen Anwendung hinter Cloudflare. Fast immer steckt eine Regel in Ihrer eigenen Zone dahinter, und Cloudflare protokolliert, welche es war.

Die Reihenfolge, die sich bewährt: Ray ID besorgen, nachschlagen, ablesen, welche Funktion eingegriffen hat, und diese Funktion dann so eingrenzen, dass sie keine Käufer und keine Zahlungsrückmeldungen mehr abfängt. Alle beschriebenen Verhaltensweisen stammen aus der Entwicklerdokumentation von Cloudflare, Stand Oktober 2026.

#Cloudflare Fehler 1015, 1020, 1009: was bedeuten die Codes

Der Code verrät, wo Sie suchen müssen. Ein Beitrag in r/CloudFlare vom 21. Oktober 2026 hat die Codes zusammengefasst, und jeder davon deckt sich mit den Fehlerseiten von Cloudflare selbst:

• 1015 (HTTP 429): Eine Rate-Limiting-Regel hat gegriffen. Cloudflare rät, die Schwellenwerte zu prüfen und bei einer Regel, die über einen sehr kurzen Zeitraum wie eine Sekunde zählt, 10 Sekunden auszuprobieren.
• 1020 (HTTP 403): eine Sicherheitsregel mit der Aktion Block und ohne eigene Antwort. Die Seite zu 1020 nennt als Beispiele die Schemavalidierung und die JWT-Validierung von API Shield und stellt klar, dass WAF Custom Rules und Managed Rules keinen 1020 mehr zurückgeben. Sie liefern stattdessen die WAF-Sperrseite aus.
• 1009 (HTTP 403): eine Länder- oder Regionssperre in den IP Access rules. Ländersperren an dieser Stelle gibt es nur im Enterprise-Tarif. In anderen Tarifen ist eine Ländersperre eine Custom Rule, und die zeigt die WAF-Sperrseite.
• 1010 (HTTP 403): Browser Integrity Check hat die Signatur des Browsers abgelehnt.
• “Just a moment…” oder eine Prüfseite: eine Managed Challenge aus einer Custom Rule, einer Rate-Limiting-Regel, aus Bot Fight Mode oder Under Attack Mode.

Das Detail zu 1020 spart Stunden. Wer die Custom Rules nach der Regel durchkämmt, die 1020 zurückgegeben hat, sucht in der falschen Liste.

#Wo finde ich die Ray ID bei Cloudflare

Bitten Sie den Kunden um einen Screenshot der kompletten Fehlerseite. Darauf stehen der Code, die Ray ID und ein Zeitstempel in UTC. Der Verfasser desselben Threads schrieb dazu in einer Antwort:

der code ist der einfache teil, was die leute übersehen, ist die ray id auf demselben bildschirm. in security events einfügen und man sieht, welche der eigenen regeln gegriffen hat.

(u/Hot_Bee_5451, r/CloudFlare, 22. Oktober 2026, eigene Übersetzung)

Eine Ray ID hängt an jeder Anfrage, die über Cloudflare läuft, und wird im Header cf-ray an Ihren Server weitergereicht. Cloudflare weist darauf hin, dass Ray IDs nicht garantiert eindeutig sind. Gleichen Sie deshalb auch Zeitstempel und IP ab. Kann der Kunde keinen Screenshot schicken, fragen Sie nach seiner öffentlichen IP-Adresse, der ungefähren Uhrzeit und dem Land. Bei fehlgeschlagenen Prüfungen gibt es einen zweiten Weg, den jemand in einem anderen Thread vorgeschlagen hat:

Nun, Sie können die RayID, die bei diesem Test erzeugt wird, an den Administrator der Website weitergeben, und er kann den genauen Grund nachschlagen, warum Sie durchgefallen sind.

(u/Logvin, r/CloudFlare, 21. Oktober 2026, eigene Übersetzung)

#Ray ID in Cloudflare Security Events suchen

Öffnen Sie im Dashboard Security > Analytics und dort den Reiter Events. Setzen Sie einen Filter auf die Ray ID oder auf die Client-IP und wählen Sie einen Zeitraum, der die Beschwerde abdeckt. Rechnen Sie vorher die UTC-Zeit von der Fehlerseite in Ihre Zeitzone um. Die Cloudflare-Seite zu 1020 weist ausdrücklich darauf hin.

Zwei Grenzen aus der Dokumentation zu Security Events spielen hier eine Rolle. Die Daten werden bis zu 31 Tage aufbewahrt. Außerdem arbeitet die Liste mit Stichproben, sodass in einer stark besuchten Zone eine einzelne Anfrage fehlen kann. Liefert die Suche nach der Ray ID nichts, verkleinern Sie das Zeitfenster auf wenige Minuten und filtern Sie nach IP. Ein kleineres Fenster zeigt mehr Ereignisse. Eine einzelne Anfrage kann auch mehrere Ereignisse erzeugen, wenn mehrere Funktionen auf sie reagiert haben.

#Welche Cloudflare-Regel hat den Besucher blockiert

Klappen Sie das Ereignis auf. Das Feld Service nennt die Funktion, bei Regeln sehen Sie zusätzlich den Namen oder die ID der Regel. Was die einzelnen Einträge meist bedeuten:

• Custom rules: Ihr eigener Ausdruck. Typische Verursacher sind Ländersperren, ASN-Sperren gegen Hosting-Anbieter (die auch VPN-Nutzer treffen) und zu weit gefasste Pfadregeln auf /wp-login.php oder /checkout.
• Managed rules: Eine Signatur von Cloudflare oder OWASP hat etwas in der Anfrage erkannt. Lange Suchanfragen, Formularfelder mit Codeschnipseln und manche Daten von Page Buildern lösen diese Regeln aus.
• Rate limiting rules: der Fall 1015. Kunden, die sich eine IP teilen, etwa hinter einem Büroanschluss oder einem Mobilfunkanbieter, teilen sich auch den Zähler, wenn die Regel pro IP zählt.
• Bot Fight Mode oder Super Bot Fight Mode: die Bot-Produkte. Laut Bot-Dokumentation von Cloudflare können beide API-Verkehr oder Anfragen aus mobilen Apps mit einer Prüfung belegen.
• Security Level oder Under Attack Mode: die Zwischenseite für die ganze Zone.

Eine gelöschte Regel erscheint als “Rule unavailable”. Im Audit-Log sehen Sie, wer sie entfernt oder geändert hat.

#Cloudflare Skip-Regel anlegen, ohne die ganze Website freizugeben

Die Lösung ist eine Custom Rule mit der Aktion Skip, die oberhalb der blockierenden Regel steht und nur den Verkehr erfasst, dem Sie vertrauen. Mit den Skip-Optionen von Cloudflare lassen sich alle übrigen Custom Rules, alle Rate-Limiting-Regeln, alle Managed Rules und alle Regeln von Super Bot Fight Mode überspringen. Über die API können Sie zusätzlich Browser Integrity Check, Security Level, User Agent Blocking, Zone Lockdown und Hotlink Protection überspringen. Custom Rules laufen der Reihe nach ab, die Position entscheidet also.

Halten Sie den Ausdruck eng. Für die WooCommerce-Stripe-Erweiterung, die als Webhook-Endpunkt nur /?wc-api=wc_stripe nutzt:

(http.request.uri.query contains "wc-api=wc_stripe" and ip.src in $stripe_webhooks)

$stripe_webhooks ist dabei eine IP-Liste, die Sie aus den veröffentlichten Webhook-IP-Adressen von Stripe anlegen. Für eine Shop-Anbindung, die die WooCommerce REST API von einem festen Server aus aufruft:

(starts_with(http.request.uri.path, "/wp-json/wc/") and ip.src in $erp_servers)

Bei einem Fehlalarm, der echte Käufer getroffen hat, ist es oft besser, die ursprüngliche Regel anzupassen, statt eine Ausnahme hinzuzufügen: den Zeitraum der Rate-Limiting-Regel verlängern, eine Ländersperre auf /wp-login.php beschränken oder ein Block in eine Managed Challenge umwandeln. Lassen Sie bei der Skip-Regel Log matching requests eingeschaltet, damit Sie sehen, dass sie greift.

#Nur eine Managed Rule ausnehmen statt der ganzen WAF

Zeigt das Ereignis eine Managed Rule, überspringen Sie für den Checkout nicht gleich alle Managed Rules. Mit den Ausnahmen für Managed Rules lassen sich wahlweise alle verbleibenden Managed Rules, ein oder mehrere Managed Rulesets oder einzelne Regeln überspringen, und jede Ausnahme hat ihren eigenen Ausdruck. Kopieren Sie die Regel-ID aus dem Ereignis, legen Sie die Ausnahme nur für diese eine Regel an und beschränken Sie sie auf Pfad und Methode, die den Treffer ausgelöst haben, etwa POST-Anfragen an den Formular-Endpunkt, der die beanstandeten Daten übertragen hat.

Achten Sie auf die Ebene, auf der die Regeln eingerichtet sind. Eine Ausnahme auf Zonenebene hält keinen Treffer aus einem Managed Ruleset auf, das auf Kontoebene eingerichtet ist, denn Rulesets auf Kontoebene laufen in jeder Phase zuerst. Betreuen Sie mehrere Shops unter einem Cloudflare-Konto, prüfen Sie deshalb vor dem Schreiben der Ausnahme, wo die Managed Rules hinterlegt sind.

#Stripe-Webhooks und WooCommerce REST API von Cloudflare blockiert

Aufrufe von Server zu Server haben keinen Browser und können daher keine JavaScript-Prüfung lösen. Jede Funktion, die eine Prüfung verlangt statt zu blockieren, legt sie trotzdem lahm. Ein Shopbetreiber hat genau das in r/CloudFlare beschrieben:

Wenn ich Under Attack Mode einschalte, verschwindet der Verkehr aus Singapur in GA4. Aber Under Attack Mode macht meine Website langsam, und meine API-Aufrufe von Server zu Server (WooCommerce REST API) bekommen die Cloudflare-Prüfung “Just a moment…” und schlagen deshalb fehl.

(u/lastoneinbatumi, r/CloudFlare, 19. Oktober 2026, eigene Übersetzung)

Wie teuer das wird, hängt vom Anbieter ab. Stripe wiederholt einen fehlgeschlagenen Webhook im Live-Modus mit exponentiell wachsenden Abständen bis zu drei Tage lang. Bestellungen, die auf “Zahlung ausstehend” hängen, erholen sich daher meist, sobald die Regel korrigiert ist. Shopify versucht es bis zu achtmal innerhalb von vier Stunden und entfernt danach das Abonnement. Das ist relevant, wenn Ihre App oder Ihr Headless-Backend Shopify-Webhooks hinter Ihrer Cloudflare-Zone empfängt. Prüfen Sie nach jeder Änderung an den Sicherheitseinstellungen im Dashboard jedes Anbieters, ob Zustellungen fehlgeschlagen sind.

Under Attack Mode ist als letztes Mittel während eines Angriffs gedacht. Auf der Seite zu Security Level empfiehlt Cloudflare, ihn per Configuration Rule für Ihre API oder einen anderen Teil der Domain ein- oder auszuschalten. Lassen Sie ihn für /wp-json/, Webhook-Pfade und Ihren API-Host ausgeschaltet.

Derselbe Thread enthielt eine zweite Lehre. Taucht blockierter Verkehr weiter in der Statistik auf, sollten Sie fragen, ob er überhaupt über Cloudflare läuft:

Ist der Host so eingerichtet, dass er nur Verkehr von und zu Cloudflare zulässt? Sonst ist er direkt über die IP erreichbar

(u/Wilbo007, r/CloudFlare, 19. Oktober 2026, eigene Übersetzung)

Die Dokumentation zu den IP-Adressen von Cloudflare empfiehlt, am Server allen Verkehr zu sperren, der nicht von Cloudflare oder von vertrauenswürdigen Partnern kommt. Geben Sie in dieser Server-Firewall auch die Adressen Ihrer Zahlungsanbieter frei.

Aktualisierung vom 24. Oktober 2026. Wenn Sie die Webhooks eines Zahlungsanbieters durch Cloudflare lassen, heißt das nicht, dass der Endpunkt jedem Aufrufer trauen darf. Der wöchentliche Schwachstellenbericht von Wordfence für den 12. bis 18. Oktober 2026 nennt WooCommerce-Zahlungs-Plugins, die gefälschte Aufrufe annahmen: Cardinity 3.2.6 bis 3.4.1 prüfte die HMAC-Signatur gegen ein leeres Projekt-Secret, Asaas Gateway vor 2.7.8 verglich ein leeres konfiguriertes Token mit einem leeren Token in der Anfrage, und bei Rede Itaú bis 5.5.2 übersprang der 3DS-Webhook die Prüfung bei Rede, wenn die Transaktions-ID leer war. In allen drei Fällen ließen sich Bestellungen ohne Anmeldung als bezahlt markieren oder umstellen. Cloudflare kann einen gefälschten Webhook nicht von einem echten unterscheiden, die Prüfung gehört also in die Anwendung: Webhook-Secret in den Gateway-Einstellungen setzen, Plugin aktuell halten und bezahlte Bestellungen mit den Transaktionen im Dashboard des Anbieters abgleichen.

#Cloudflare-Sperre mit curl nachstellen und prüfen

Ein Screenshot zeigt, was einmal passiert ist. Wenn Sie die Anfrage selbst wiederholen, sehen Sie, ob sie auch nach Ihrer Korrektur noch scheitert. Rufen Sie im Terminal die Seite auf, die der Kunde nicht öffnen konnte, und lesen Sie die Header der Antwort:

curl -sI https://example.com/checkout/
curl -sI "https://example.com/?wc-api=wc_stripe"

Drei Header sind entscheidend. server: cloudflare bestätigt, dass die Antwort vom Rand des Netzes kam. cf-ray liefert eine frische Ray ID, die Sie in Security Events nachschlagen können. Steht cf-mitigated: challenge in der Antwort, handelt es sich um eine Prüfseite. Laut der Anleitung von Cloudflare zum Erkennen von Prüfseiten wird dieser Header bei jeder Art von Prüfseite gesetzt, challenge ist sein einziger Wert, und der Inhalt ist immer text/html, ganz gleich, welche Ressource angefragt wurde.

Das letzte Detail erklärt einen häufigen Fehler bei Headless-Frontends. Ein Astro- oder Next.js-Frontend, das per fetch seine eigene API aufruft, erwartet JSON, bekommt eine HTML-Prüfseite und bricht mit einem Parse-Fehler ab, der wie ein Programmierfehler aussieht. Fragen Sie vor dem Parsen response.headers.get("cf-mitigated") ab und schreiben Sie den Wert ins Log. Dann wissen Sie nach der nächsten Auslieferung, ob Cloudflare die Ursache ist. Ihre eigene IP und Ihr Browser lösen nicht unbedingt dieselbe Regel aus wie die des Kunden. Ein sauberes Ergebnis vom eigenen Schreibtisch beweist daher weniger als ein sauberes Bild in Security Events.

#Rate Limiting bei Cloudflare einstellen, ohne Käufer zu sperren

Wie fein Ihre Korrektur ausfallen kann, hängt vom Tarif ab. Die Seite zu Rate-Limiting-Regeln listet, was jeder Tarif einstellen darf:

Weil pro IP gezählt wird, kann ein Büro oder ein Mobilfunkanbieter eine Regel auslösen, die für einen einzelnen Bot gedacht war. Hinter einer gemeinsamen Adresse addieren sich die Anfragen vieler Kunden. Drei Anpassungen aus den Empfehlungen von Cloudflare für Rate Limiting verringern das:

• Bekannte Partner ausnehmen. Im Beispiel von Cloudflare sind 10 Anfragen pro Minute und IP an /status erlaubt, es sei denn, die Adresse steht in einer IP-Liste namens partner_ips. Der Ausdruck enthält dafür not ip.src in $partner_ips. Die Quell-IP steht in Rate-Limiting-Ausdrücken erst ab Business zur Verfügung. In Free und Pro gehört die Partnerliste deshalb in eine Custom Rule mit der Aktion Skip, die alle Rate-Limiting-Regeln überspringt, denn Custom Rules können die Quell-IP prüfen.
• Nur Fehlschläge zählen. Ab Business gibt es einen eigenen Zählausdruck. Eine Login-Regel kann damit nur POST-Anfragen zählen, die mit 401 oder 403 beantwortet wurden. Wer sich beim ersten Versuch anmeldet, erhöht den Zähler nie.
• Den genauen Pfad treffen. Dieselbe Seite warnt, dass eine Regel für /validate/otp nicht auf /api/otp/validate greift. Prüfen Sie den tatsächlichen Pfad in der Analyse, bevor Sie die Regel schreiben, und halten Sie /wp-json/ und die AJAX-Endpunkte des Checkouts aus Regeln heraus, die für Login-Seiten gedacht sind.

Im Enterprise-Tarif zeigt der Reiter Request rate analysis in Security Analytics die Verteilung der Anfragerate für die 50 aktivsten Clients und kann aus der gewählten Rate eine Rate-Limiting-Regel vorbefüllen. Cloudflare empfiehlt, eine solche Regel zuerst mit der Aktion Log einzusetzen.

#Kann man Bot Fight Mode mit einer WAF-Regel umgehen

Nein. Auf der Seite zu Bot Fight Mode steht, dass er sich weder mit WAF Custom Rules noch mit Page Rules umgehen oder überspringen lässt, weil er nicht auf der Ruleset Engine läuft. Skip, Bypass und Allow wirken daher nicht. Die Seite zu den Skip-Optionen wiederholt, dass sich nur Super Bot Fight Mode überspringen lässt. Eine Ausnahme ist dokumentiert: Bot Fight Mode wird nicht ausgelöst, wenn vorher eine IP-Access-Regel auf die Anfrage zutrifft.

Belegt Bot Fight Mode im Free-Tarif also Ihren Zahlungsanbieter, Ihr ERP oder Ihr Uptime-Monitoring mit einer Prüfung, bleiben drei Möglichkeiten: eine IP-Access-Regel mit Allow für die Adressen dieses Anbieters, Bot Fight Mode abschalten oder in einen kostenpflichtigen Tarif wechseln, in dem Super Bot Fight Mode Skip-Regeln akzeptiert. Super Bot Fight Mode hat außerdem die Einstellung Optimize for WordPress, die Loopback-Anfragen von WordPress durchlässt. Damit verschwinden die Fehler im Website-Zustand ohne eigene Custom Rule.

#Cloudflare-Sperren: Ursache und Lösung im Überblick

#Neue Cloudflare-Regel testen, ohne Kunden auszusperren

Die Anleitung für Custom Rules bietet zum Prüfen einer Regel vor dem Scharfschalten die Aktion Log an, allerdings nur im Enterprise-Tarif. Für alle anderen Tarife schlägt Cloudflare vor, mit Managed Challenge zu beginnen, die erfassten Anfragen in Security Events durchzusehen und erst auf Block umzustellen, wenn die Treffer stimmen. Ein echter Kunde kann eine Managed Challenge lösen. Bei Block bleibt ihm kein nächster Schritt.

Wer eine Prüfung besteht, erhält das Cookie cf_clearance. Wie lange es gilt, legt die Einstellung Challenge Passage fest: standardmäßig 30 Minuten, Cloudflare empfiehlt 15 bis 45 Minuten. Für Support-Anfragen hat das zwei Folgen. Ein Kunde, der Cookies blockiert, wird auf jeder Seite erneut geprüft und meldet dann, die Website “prüft ihn ständig”. Außerdem gilt Challenge Passage nicht für Rate-Limiting-Regeln, eine bestandene Prüfung hebt einen 1015 also nicht auf.

#Cloudflare-Sperrseite anpassen: was blockierte Kunden tun sollen

Die Standard-Sperrseite sagt dem Besucher nichts über Ihren Shop. In kostenpflichtigen Tarifen gibt es zwei Wege, das zu ändern. Custom Errors stehen in Pro, Business und Enterprise zur Verfügung, im Free-Tarif nicht. Eine Error Page vom Typ WAF block ersetzt die Seite, die bei WAF-Sperren in der ganzen Zone erscheint. Ab Pro kann außerdem eine einzelne Custom Rule mit der Aktion Block eine eigene Antwort liefern, mit einem Statuscode zwischen 400 und 499 und einem Inhalt als HTML, JSON oder reiner Text.

Fragen Sie auf dieser Seite genau das ab, was Sie zur Fehlersuche brauchen: einen Screenshot mit der Ray ID, die Uhrzeit und eine E-Mail-Adresse oder Telefonnummer, die nicht hinter derselben Zone liegt. Für einen API-Pfad geben Sie JSON zurück, damit angebundene Systeme einen lesbaren Fehler protokollieren statt einer HTML-Seite. Unter den Beispielregeln für Custom Errors findet sich eine für Fehler 1020, die auf cf.response.1xxx_code eq 1020 prüft.

#Cloudflare-Sperren nach der Korrektur überwachen

Hören Sie nicht beim einen Kunden auf. Filtern Sie in Security Events nach Action gleich Block oder Managed Challenge und gruppieren Sie nach Pfad. Anfragen an /checkout, /cart, /my-account, /wp-json/ oder an den Endpunkt Ihres Kontaktformulars sind die, die Geld kosten. Die gefilterte URL lässt sich teilen, sodass eine Kollegin oder ein Kollege dieselbe Ansicht sieht. Bis zu 500 Ereignisse aus der Stichprobe lassen sich als JSON exportieren.

Prüfen Sie dann die andere Seite: fehlgeschlagene Zustellungen bei Stripe, PayPal oder Shopify, WooCommerce-Bestellungen, die auf “ausstehend” hängen, und Kontaktformular-Eingänge pro Tag. Ein Einbruch am Tag nach einer Sicherheitsänderung führt direkt zu der Regel, die Sie hinzugefügt haben. Unsere Leistungen rund um Cloudflare Edge umfassen solche Regelprüfungen, und die laufende WooCommerce-Betreuung enthält diese Überwachung für WooCommerce-Shops.

Weiterlesen: Ob die KI-Bot-Einstellungen von Cloudflare auch Suchmaschinen-Crawler aussperren, klärt der Beitrag Blockiert Cloudflare den Googlebot. Wie viel Verkehr auf einer kleinen Website automatisiert ist und warum das zu scharfen Bot-Regeln verleitet, zeigt unsere Messung in Bot-Traffic auf einer kleinen Website. Wie sich Logik an den Rand des Netzes verlagern lässt, zeigt Cloudflare Workers und WooCommerce.