Dokumentation · Hilfe
Cloudflare blockiert die Verbindung
Wenn die Verbindung zu deiner Website gestern lief und heute nicht mehr — oder wenn sie nie lief, obwohl Benutzername und Anwendungspasswort stimmen —, dann sitzt oft eine Firewall dazwischen. Am häufigsten Cloudflare.
Das Tückische daran: Deine Seite funktioniert im Browser tadellos. Cloudflare lässt dich durch und weist uns ab, weil wir kein Browser sind.
Woran du es erkennst
| Was du bei uns siehst | Was dahintersteckt |
|---|---|
„Keine WordPress-REST-Schnittstelle" — obwohl /wp-json/ im Browser JSON zeigt |
Cloudflare antwortet uns mit einer Challenge-Seite in HTML statt mit JSON |
403 mit HTML statt JSON |
Managed Rules (WAF) oder eine eigene Regel greift |
403 und im Text steht Error 1020 |
Eine eigene Firewall-Regel von dir (oder deinem Hoster) blockt |
503 mit „Checking your browser" / „Just a moment…" |
Under Attack Mode ist an, oder eine Managed Challenge |
| Error 1015 | Rate Limiting — wir sind zu schnell für deine Regel |
| Die Verbindung klappt, aber Bilder landen nicht in der Mediathek | Der Upload nach /wp-json/wp/v2/media läuft in eine Größen- oder Regel-Sperre |
| Funktioniert mal, mal nicht | Bot Fight Mode — er entscheidet pro Aufruf |
Ein Hinweis, der viel Zeit spart: Steht in der Antwort HTML, wo JSON stehen müsste, dann hat nicht WordPress geantwortet, sondern etwas davor.
Zuerst: nachstellen
Prüfe von einem beliebigen Rechner aus, ob deine Seite uns antwortet. Wichtig ist der User-Agent — genau mit dem melden wir uns:
curl -sS -o /dev/null -w '%{http_code}\n' \
-A 'evnxt-publisher/1.0 (+https://evnxt.de/docs/cloudflare)' \
https://deine-domain.de/wp-json/
Erwartet: 200. Kommt 403, 503 oder 1020, ist die Blockade bestätigt. Zum Vergleich derselbe Aufruf ohne unsere Kopfzeile:
curl -sS -o /dev/null -w '%{http_code}\n' https://deine-domain.de/wp-json/
Antwortet dieser mit 200 und der obere nicht, blockt die Firewall nach User-Agent. Antworten beide mit 403, blockt sie den Pfad oder alles, was kein Browser ist.
Und einmal mit Anmeldung, so wie wir es tun (ersetze Benutzername und Anwendungspasswort — schreib sie nicht in eine Datei und nicht in ein Ticket):
curl -sS -i -u 'benutzer:xxxx xxxx xxxx xxxx xxxx xxxx' \
-A 'evnxt-publisher/1.0 (+https://evnxt.de/docs/cloudflare)' \
https://deine-domain.de/wp-json/wp/v2/users/me
Erwartet: 200 und JSON mit deinem Benutzer. Kommt 401 mit sauberem JSON, liegt es nicht an Cloudflare, sondern am Anwendungspasswort — zurück zu WordPress nativ verbinden.
Unser User-Agent
Alle unsere Aufrufe an dein CMS — WordPress, Ghost, Webflow, Wix, Notion und der Webhook — melden sich mit:
evnxt-publisher/1.0 (+https://evnxt.de/docs/cloudflare)
Darauf kannst du eine Ausnahme bauen. Zwei Dinge dazu, ehrlich gesagt:
- Ein User-Agent ist kein Ausweis. Jeder kann ihn behaupten. Als alleinige Eintrittskarte in
/wp-admin/taugt er nicht — deshalb steht in den Regeln unten immer Pfad und User-Agent, und die Anmeldung mit dem Anwendungspasswort bleibt die eigentliche Sicherung. - Daneben laufen noch zwei andere Kopfzeilen von uns, die nichts mit dem Veröffentlichen zu tun haben:
Mozilla/5.0 (compatible; OutreachPortalBot/1.0; +https://evnxt.de)holt dein Portal für den Zwischenspeicher,OutreachPlatform/1.0 (+https://evnxt.de/bot)prüft Platzierungen und Erwähnungen. Blockst du die, brechen Verbindungen nicht ab — es fehlen nur Prüfungen.
Die Ausnahmeregel in der WAF
Cloudflare-Dashboard → deine Domain → Security → WAF → Custom rules → Create rule.
Name: evnxt Veroeffentlichung
Expression (auf „Edit expression" umschalten und einfügen):
(http.request.uri.path contains "/wp-json/wp/v2/" and http.user_agent contains "evnxt-publisher")
or (http.request.uri.path eq "/wp-admin/admin-ajax.php" and http.user_agent contains "evnxt-publisher")
Action: Skip — und darunter ankreuzen, was übersprungen werden soll:
- All remaining custom rules
- Managed rules (die WAF selbst)
- Rate limiting rules
- Super Bot Fight Mode (nur vorhanden, wenn du ihn hast, siehe unten)
- Browser Integrity Check
Die Regel muss oben stehen. Cloudflare arbeitet Custom Rules von oben nach unten ab; eine blockende Regel darüber kommt zuerst dran.
Warum /wp-admin/admin-ajax.php mit drin ist: Manche Sicherheits- und SEO-Plugins hängen sich dort ein, und ohne den Pfad scheitern Teile der Anbindung, während /wp-json/ sauber durchgeht.
Sicherer: zusätzlich den Pfad einschränken
Willst du enger fassen, nimm nur die Pfade, die wir wirklich brauchen:
http.user_agent contains "evnxt-publisher" and (
http.request.uri.path eq "/wp-json/"
or starts_with(http.request.uri.path, "/wp-json/wp/v2/posts")
or starts_with(http.request.uri.path, "/wp-json/wp/v2/media")
or starts_with(http.request.uri.path, "/wp-json/wp/v2/categories")
or starts_with(http.request.uri.path, "/wp-json/wp/v2/users")
)
Das ist der Bestand: Wurzel zum Erkennen der Fähigkeiten, Beiträge, Mediathek, Kategorien, Autoren.
Bot Fight Mode — die Grenze, die du kennen musst
Hier wird es unangenehm, und darum steht es hier ausdrücklich:
Bot Fight Mode (der einfache, im kostenlosen Tarif) lässt sich nicht per Regel ausnehmen. Er läuft vor den Custom Rules; ein Skip erreicht ihn nicht. Es gibt keine Ausnahmeliste, keine Pfadausnahme, keinen Eintrag für einen User-Agent. Wenn er an ist und uns erwischt, hast du genau zwei Möglichkeiten:
- Bot Fight Mode ausschalten (Security → Bots). Deine anderen Schutzschichten — WAF, Rate Limiting, das Anwendungspasswort — bleiben davon unberührt.
- Auf einen Tarif mit Super Bot Fight Mode wechseln (Pro und höher). Der lässt sich steuern: „Definitely automated" auf
AllowoderManaged Challengestellen, Verified Bots zulassen, und in einer WAF-Regel den Punkt Super Bot Fight Mode überspringen — das geht beim einfachen Bot Fight Mode eben nicht.
Wir sind kein „Verified Bot" bei Cloudflare. Das ist eine Liste, die Cloudflare pflegt (Suchmaschinen und Ähnliches); wir stehen nicht darauf und behaupten das auch nicht. Die Option „Verified Bots zulassen" hilft dir also bei uns nicht — sie ist nur erwähnt, damit du sie nicht als Lösung missverstehst.
Empfehlung: Bot Fight Mode aus, dafür eine saubere WAF-Regel wie oben. Das schützt besser und kostet dich nichts.
„Under Attack" Mode
Ist Under Attack Mode an (Overview → Security Level), bekommt jeder Aufruf eine Challenge — auch unserer, auch mit Ausnahmeregel, denn das Ergebnis ist eine HTML-Seite, keine JSON-Antwort. Solange er läuft, kann keine Anbindung arbeiten.
Wenn du ihn wegen eines echten Angriffs brauchst, lass ihn an und nimm hin, dass wir in dieser Zeit nichts veröffentlichen. Wir versuchen es später erneut; die Beiträge gehen nicht verloren. Ist der Angriff vorbei, stell den Security Level zurück auf Medium oder High.
Wenn das Drop-in-Portal blockiert wird
Das Drop-in beziehungsweise Plugin ist ein Proxy: Es läuft auf deinem Server und holt die Seiten bei uns. Cloudflare steht davor, nicht dahinter. Zwei Stellen können klemmen:
- Besucher kommen nicht ins Magazin. Sie sehen eine Challenge auf
/news/…oder was dein Verzeichnis ist. Dann greift eine Regel auf dem Pfad. Lege für das Verzeichnis eine Ausnahme an —starts_with(http.request.uri.path, "/news/")— und überspringe dort Managed Rules und Rate Limiting. Prüfe auch, ob Bot Fight Mode deine Besucher mit-erwischt: Für eine Magazinseite ist er meist mehr Schaden als Nutzen. - Der Zwischenspeicher wird nicht warm. Wir holen dein Portal mit
Mozilla/5.0 (compatible; OutreachPortalBot/1.0; +https://evnxt.de). Blockst du das, funktioniert das Magazin trotzdem — es wird nur langsamer.
Ein häufiger Nebeneffekt, der nichts mit Blockaden zu tun hat: Cloudflare speichert deine Magazinseiten zwischen und zeigt alte Stände. Prüfe unter Caching → Configuration die Regeln für dein Verzeichnis; bei Zweifeln einmal Purge Cache für den Pfad.
Andere Firewalls
Cloudflare ist nur der häufigste Fall. Dieselben Symptome — HTML statt JSON, 403 ohne Erklärung — erzeugen auch:
- Sicherheits-Plugins in WordPress (Wordfence, iThemes/Solid Security, All In One WP Security). Sie schalten
/wp-json/gerne komplett ab oder sperren nach ein paar Fehlversuchen die IP. Suche nach einer Einstellung „REST API deaktivieren" und nach der Sperrliste. - ModSecurity beim Hoster. Meldet sich als
403mit einer Kennung („Reference #…"). Nur der Hoster kann das lösen — schick ihm die Kennung und die Uhrzeit. - Serverseitige IP-Sperren nach zu vielen Anmeldeversuchen. Tritt auf, wenn ein altes, ungültiges Anwendungspasswort noch bei uns steht.
Wenn nichts hilft
Schick uns:
- Die Ausgabe der drei
curl-Aufrufe von oben (ohne das Anwendungspasswort). - Aus Cloudflare unter Security → Events die Zeilen zur Uhrzeit des Versuchs — dort steht, welche Regel gegriffen hat (Service: WAF, Bot Fight Mode, Rate Limiting …).
Mit diesen beiden Angaben ist es in der Regel in einer Antwort erledigt. Ohne sie raten wir.