Warenkorb und Versand stimmen. Doch nach „Zahlungspflichtig bestellen“ erscheint eine Cloudflare Challenge, ein 403 Fehler oder ein endloser Spinner, während die Startseite schnell lädt. Cloudflare soll automatisierten oder schädlichen Traffic abfangen. Leider ähnelt ein echter WooCommerce-Checkout mit Zahlungsrückrufen diesem Muster manchmal. Dieser Guide zeigt dir, wie du die auslösende Regel findest, eine präzise Ausnahme setzt und den Schutz deines Shops behältst.
Cloudflare steht vor deinem Origin-Server. Jeder Checkout-AJAX-Aufruf, Store API POST und Gateway-Rückruf passiert zuerst diese Schutzschicht. Bot Fight Mode, Super Bot Fight Mode, Managed WAF-Regeln, Rate Limits, Under Attack Mode und eigene Firewall-Regeln können dabei einen legitimen WooCommerce-Checkout fälschlich als Bedrohung einstufen.
Auffällige Checkout POSTs
Place Order sendet `?wc-ajax=checkout` oder `/wc/store/v1/checkout` mit Cookies, Nonces und oft Zahlungsskripten anderer Anbieter. Dieses Muster ähnelt Bot und Betrugssignaturen, die Cloudflare besonders genau prüft.
Zahlungsrückrufe
Stripe, PayPal und Bank Gateways senden Webhooks und leiten Kunden über URLs mit Parametern zurück. Prüft oder blockiert Cloudflare diese Pfade, sieht der Käufer beim Anbieter zwar Erfolg. WooCommerce erstellt dann aber möglicherweise keine bezahlte Bestellung.
Gemeinsam genutzte Rechenzentrums-IPs
Agenturen, Staging Systeme und Monitoring-Tools nutzen häufig IP-Bereiche aus der Cloud. Cloudflare kann diese Bereiche als automatisiert bewerten, obwohl es sich um einen bewusst gestarteten Checkout Test handelt.
Challenge Seiten und Checkout Skripte
Eine Challenge Seite oder verzögertes JavaScript kann mit den WooCommerce-Checkout Skripten kollidieren. Gäste lösen die Challenge, doch Place Order scheitert, weil Session oder Nonce bereits vorher erstellt wurden.
Fällt der WooCommerce-Checkout nach einer Sicherheits oder CDN Änderung aus, schau nicht nur auf Plugin Updates. Prüfe zusätzlich Cloudflares Schutzschicht und nutze diese Checkliste: Checkout nach Update kaputt.
Symptome: Woran erkennst du Cloudflare als Ursache?
Tausche nicht vorschnell API Schlüssel aus. Kläre zuerst, ob der Block bei Cloudflare, am Origin Server oder in WooCommerce selbst entsteht.
1
Cloudflare Fehler oder Challenge Seite
Achte auf eine Ray ID, „Attention Required“, eine Managed Challenge oder die Fehler 1020 und 1015 auf Warenkorb, WooCommerce-Checkout oder Danke Seite. Speichere die Ray ID. Damit findest du den Vorgang in Security Events.
2
Im Netzwerk Tab erscheint HTML statt JSON
Fehlgeschlagene `wc-ajax=checkout` oder Store API Aufrufe liefern Cloudflare HTML mit 403, 429 oder einer Challenge statt eines WooCommerce Fehlerobjekts. Die PHP Logs am Origin bleiben bei diesem Klick leer.
3
Am Origin funktioniert es, über die öffentliche Domain nicht
Ein temporärer Test über die Hosts Datei oder DNS only funktioniert, der über Cloudflare geschützte Hostname aber nicht. Das spricht stark für einen Block an der Edge.
4
Gäste im Inkognito Fenster scheitern, Admins manchmal nicht
Angemeldete Admins umgehen oft Caches und manche Bot Regeln. Teste deshalb als Gast. Das ist auch der Checkout Weg deiner Kunden.
5
Monitoring- und Agentur-IPs scheitern immer
Manuelle Tests von zu Hause funktionieren, geplante Browser Tests aus Rechenzentren erhalten aber bei jedem Lauf eine Challenge. Das deutet auf die Cloudflare Bewertung hin und nicht auf einen WooCommerce-Fehler.
Sobald Cloudflare als Ursache infrage kommt, brauchst du einen wiederholbaren Gast Checkout-Test. Lege ein Produkt in den Warenkorb und führe Place Order so aus wie bei einem normalen WooCommerce-Checkout Test ohne echte Belastung. Teste nach jeder Änderung an der Firewall erneut und warte nicht auf das nächste Kundenticket.
Cloudflare WAF blocks a WooCommerce checkout POST until the path is allowed
Animiertes Diagramm: Ein WooCommerce-Checkout Aufruf trifft auf ein Cloudflare Schild. Die WAF blockiert den POST, bis der Pfad freigegeben ist. Danach kann die Bestellung abgeschlossen werden.
Fix 1: Cloudflare Security Events prüfen
Zu raten, welche Regel ausgelöst hat, kostet Zeit. Cloudflare hat die Entscheidung bereits protokolliert.
1Öffne im Cloudflare Dashboard Security → Events, bei älteren Oberflächen Firewall → Events. Filtere nach Hostname und Zeitpunkt des fehlgeschlagenen WooCommerce-Checkouts.
2Suche mit der Ray ID von der Fehlerseite, falls du eine hast. Prüfe die Aktion: Block, Challenge, JS Challenge oder Managed Challenge.
3Notiere den Auslöser: WAF Managed Rule, Custom Firewall Rule, Bot Fight / Super Bot Fight, Rate Limiting oder Browser Integrity Check.
4Öffne URL und Methode der passenden Anfrage. Checkout Blöcke betreffen meist `/checkout`, `?wc-ajax=`, `/wc/store/`, `/wc-api/` oder Zahlungsrückrufe, nicht die Startseite.
5Zeigt das Event einen Fehlalarm für einen bekannten Kunden oder deine Test IP, fahre mit Fix 2 bis 4 fort. Schalte nicht die gesamte WAF ab.
Under Attack auszuschalten oder Cloudflare zu pausieren ist nur ein kurzer Diagnoseschritt, kein Fix. Nutze das höchstens fünf Minuten, um die Edge als Ursache zu bestätigen. Aktiviere den Proxy danach wieder und setze eine gezielte Regel.
Fix 2: Gezielte Ausnahmen für den Checkout setzen
Die meisten Shops brauchen eine präzise WAF-Ausnahme, keine offene Tür. Managed WAF-Regeln lassen sich mit einer passenden WAF-Custom-Rule und Skip behandeln, ohne Super Bot Fight Mode zu aktivieren. Der normale Bot Fight Mode lässt sich dagegen nur für die gesamte Zone deaktivieren. Gezielte Ausnahmen für Super Bot Fight Mode brauchen SBFM plus eine passende WAF-Custom-Rule mit Skip.
Pfade, die oft eine Exception brauchen
/checkout und lokalisierte Varianten (/kasse, /caisse usw.)
/cart sowie Cart Fragments / Mini Cart AJAX
admin-ajax.php und ?wc-ajax=* (besonders checkout, update_order_review)
/wc/store/v1/* (Checkout Block / Store API)
/wc-api/* sowie Zahlungsrückrufe und Webhooks
Konto, Bestellbestätigung und Zahlungsseiten
So konfigurierst du es
1Liegt die Ursache in einer Managed WAF-Regel, öffne Security → WAF → Custom rules und lege eine passende Skip Regel für den betroffenen Checkout-Pfad oder Query String an. Dafür brauchst du Super Bot Fight Mode nicht.
2Nimm Warenkorb und Checkout aus Cache Everything Regeln und aggressiven Rocket Loader Einstellungen heraus, die Checkout JavaScript umschreiben.
3Nutzt du Cloudflare Turnstile oder ein CAPTCHA Plugin im Checkout, dürfen Zahlungs POSTs nach einem gelösten Widget keine zweite Challenge bekommen.
4Leere nach Regeländerungen den Cache. Bei einer Gast Testbestellung darf Security Events diesen Ray Pfad nicht mehr als Block oder Challenge zeigen.
Gezieltes Skip statt Zone pausieren
Für Super Bot Fight Mode nutze eine WAF-Custom-Rule mit Skip für konkrete Komponenten auf /checkout. Der normale Bot Fight Mode kennt keine Pfadausnahmen und lässt sich nur für die ganze Zone abschalten. Breite Ausnahmen laden Scraper ein. Eine Regel nur für den betroffenen Pfad schützt den Rest der Website weiter.
Fix 3: Super Bot Fight Mode für den Checkout abstimmen
Bot Fight Mode und Super Bot Fight Mode können einen WooCommerce-Checkout unbemerkt stoppen. Blockiert der normale Bot Fight Mode eine Checkout-Anfrage, kannst du ihn nicht per Custom Rule für diesen Pfad überspringen, sondern nur zonenweit deaktivieren. Für eine gezielte Ausnahme brauchst du Super Bot Fight Mode plus eine passende WAF-Custom-Rule mit Skip. SBFM kann dabei Checkout-Anfragen gezielt von einer Challenge oder einem Block ausnehmen.
Öffne Security → Bots. Blockiert der normale Bot Fight Mode Checkout-POSTs, kannst du ihn nur für die gesamte Zone deaktivieren. Mit einer Custom Rule lässt sich normaler Bot Fight Mode nicht für einzelne Checkout-Anfragen überspringen.
Setze Super Bot Fight für eindeutig automatisierten Traffic zunächst auf Managed Challenge statt auf Block. Bleiben Security Events eine Woche lang sauber, kannst du auf Block wechseln.
Prüfe aggressive Regeln gegen Scraping bei Zahlungsrückruf URLs. Diese kurzlebigen URLs wirken auf automatische Klassifizierungen schnell ungewöhnlich.
Browser Integrity Check kann ältere Web Views in Apps stören. Scheitern Käufer aus Instagram oder Facebook am Checkout, teste BIC auf /checkout vorübergehend deaktiviert.
Führe nach jeder Änderung am Bot-Schutz einen Test des echten Pfads im WooCommerce Test oder Sandbox Modus aus. Alternativ eignet sich eine kleine erstattbare Live Bestellung auf Staging. So stellst du sicher, dass Place Order unter der neuen Edge Regel weiter durchläuft.
Fix 4: IP Adressen deines Monitorings zulassen
Ein Ping auf `/` kann grün bleiben, obwohl Cloudflare den WooCommerce-Checkout für Browser aus Rechenzentren blockiert. Nutzt du ShopMonitor oder einen anderen echten Browser Checkout-Monitor, muss Cloudflare dessen Worker Monitoring-IP-Adressen erkennen. Sonst scheitern geplante Läufe an der Challenge und melden einen Checkout-Ausfall.
1Hole die aktuelle Liste der Ausgangs Monitoring-IP-Adressen von deinem Anbieter. Aktualisiere sie, wenn der Anbieter seine Bereiche ändert.
2Öffne Cloudflare → Security → WAF → Tools / IP Access Rules. Lasse diese IPs zu oder erstelle eine Custom Rule: IP in Liste → Skip Super Bot Fight + relevante WAF Managed Rules.
3Nutze lieber eine IP Liste mit WAF Regel als dauerhaft Disable Security für den ganzen Hostnamen.
4Prüfe in Security Events, ob Monitoring Läufe das erwartete Skip Ergebnis statt einer Challenge erhalten. Eine Challenge kann einen falschen Ausfall verursachen oder bei einem zu oberflächlichen Test fälschlich als Erfolg zählen.
Wenn du den Shop in ShopMonitor anlegst, folge Website hinzufügen, damit die überwachte URL dem Hostnamen deiner Kunden entspricht, also www oder Apex und HTTPS. Eine Freigabe für den falschen Host bringt nichts.
Lass niemals ein ganzes Cloud ASN zu, nur damit ein Monitor funktioniert. Beschränke die Regel auf die veröffentlichten Monitoring-IP-Adressen und prüfe die Liste vierteljährlich.
Geschützt bleiben und legitimen Traffic erlauben
Ziel ist nicht weniger Schutz, sondern eine präzise Edge. Sie blockiert Missbrauch und lässt nur die wenigen Pfade und IP Adressen durch, die einen Checkout abschließen müssen.
Streng lassen
Eng erlauben
Managed WAF auf Admin, Login, xmlrpc und öffentlichen wp json Schreib Endpunkten
Skip oder Challenge Ausnahmen nur für Warenkorb, Checkout, Store API und Zahlungsrückrufe
Rate Limits auf Login und Passwort zurücksetzen
Höhere oder getrennte Schwellen für Checkout POSTs, damit Flash Sales echte Käufer nicht mit 429 abweisen
Bot Fight auf Marketing Seiten und Content APIs
Skip für Super Bot Fight per WAF-Custom-Rule auf Checkout und Webhook Pfaden sowie für Monitoring-IP-Adressen
Volles Caching für Blog und Listing HTML, wo es sicher ist
Cache umgehen für Warenkorb, Checkout, Mein Konto und die Bestellbestätigung
Prüfe Security Events nach jeder Änderung an Cloudflare oder einem Security Plugin erneut. Fehler an der Edge wirken oft wie zufällige Checkout Probleme und werden tagelang einem Zahlungsanbieter zugeschrieben.
Ergänze saubere Edge Regeln durch geplante echte Browser Checkout Tests. Cloudflare informiert dich nicht, wenn eine neue Managed Rule Place Order um zwei Uhr nachts blockiert. ShopMonitor kann dich bei solchen stillen Ausfällen warnen, wie auch bei WordPress Formular Ausfall Monitoring.
Prüfe Security Events nach jeder Änderung an Cloudflare oder einem Security Plugin.
Führe Monitoring-IP-Adressen in einer freigegebenen Liste und aktualisiere sie nach einer Rotation.
Plane einen echten Browser Checkout Test, damit eine neue Managed Rule zuerst dich informiert und nicht deine Kunden.
Verliere keinen Umsatz durch kaputte Checkouts
ShopMonitor prüft täglich Checkout und Formular Abläufe im Browser und alarmiert dich, sobald etwas nicht mehr funktioniert. Keine Codeänderungen. Kein Plugin erforderlich. Schnell eingerichtet.
Achte auf eine Cloudflare Challenge oder Fehlerseite mit Ray ID auf Warenkorb oder Checkout. Im Netzwerk Tab kann Cloudflare HTML statt eines WooCommerce-Fehlerobjekts erscheinen. Vergleiche den Zugriff über Cloudflare mit DNS only. Funktioniert der Origin-Server, aber nicht der öffentliche Hostname, liegt die Ursache wahrscheinlich an der Edge. Bestätige den Vorgang unter Security → Events.
Nein. Disable Security ist nur für eine kurze Diagnose gedacht. Erstelle für betroffene Managed WAF-Regeln passende Custom Rules mit Skip. Die Managed WAF bleibt für Login, Admin und den Rest der Website aktiv. Normaler Bot Fight Mode ist davon getrennt und lässt sich nicht gezielt per Custom Rule überspringen.
Ja. Der normale Bot Fight Mode kann Checkout-Anfragen blockieren, die automatisiert wirken. Er lässt sich nicht für einzelne Pfade per Custom Rule überspringen, sondern nur zonenweit deaktivieren. Für gezielte Ausnahmen aktiviere Super Bot Fight Mode und erstelle eine passende WAF-Custom-Rule mit Skip. Managed WAF-Regeln kannst du unabhängig davon mit passenden Skip Regeln behandeln. Setze Super Bot Fight während der Abstimmung zunächst von Block auf Managed Challenge.
Trage die veröffentlichten Ausgangs Monitoring-IP-Adressen des Anbieters in eine WAF-Custom-Rule ein. Verwende Skip nur für die in Security Events angezeigten Managed WAF-Regeln oder für Super Bot Fight Mode. Beschränke die Regel auf diese Adressen und nicht auf ein ganzes Cloud ASN. Prüfe danach die Ergebnisse der Monitoring Läufe in Security Events.
Ja. Webhooks sind Server zu Server POSTs und wirken oft automatisiert. Ist die Zahlung beim Anbieter erfolgreich, bleiben WooCommerce Bestellungen aber ausstehend, prüfe Security Events auf Blöcke bei `/wc-api/`, Webhooks oder Gateway Plugins. Verwende Skip für diese Rückruf URLs nur dort, wo die Events einen Fehlalarm zeigen, und prüfe die HTTPS Erreichbarkeit des Hostnamens.
Umgehe den Cache für Warenkorb, Checkout, Mein Konto, Checkout Endpunkte und die Danke Seite nach der Bestellung. Gecachte Seiten können veraltete Nonces und Sessions ausliefern. Das wirkt wie ein kaputter Checkout, auch ohne WAF Block. Leere nach Regeländerungen den Cache und teste erneut als abgemeldeter Gast.
Zuletzt aktualisiert: August 2026. Behandelt Cloudflare WAF Events, Ausnahmen für Checkout Pfade, Bot Fight Mode und zugelassene Monitoring-IP-Adressen für WooCommerce.
Über den Autor
Verfasst vom Winning Solutions Team, der Agentur hinter ShopMonitor. Cloudflare Fehlalarme am WooCommerce-Checkout sehen wir häufiger als einen tatsächlich ausgefallenen Zahlungsanbieter. Diese Checkliste für die Edge nutzen wir, bevor wir Zahlungszugänge prüfen.
Cloudflare blockiert WooCommerce-Checkout – so behebst du es | ShopMonitor
