„Please wait while your request is being verified“ beheben (Imunify360 + Cloudflare)
Aktualisiert im September 2026
Ein grüner Ladekreis mit „Please wait while your request is being verified…“, der nie verschwindet — oder ein nacktes „403 Forbidden“ von openresty — bedeutet fast immer, dass Imunify360 und Cloudflare sich über Cookies uneinig sind. Hier sind der Mechanismus, die Bestätigung und der Ort, an dem die Einstellung heute liegt, nachdem Page Rules abgekündigt wurden.
Was Sie sehen
Besucher sehen einen grünen Ladekreis und „Please wait while your request is being verified…“ — die Seite lädt neu und zeigt endlos dasselbe. Manche Anfragen liefern stattdessen ein schlichtes „403 Forbidden“ mit einem Servernamen wie openresty im Fuß. Das ist WebShield von Imunify360, das direkt auf dem Server vor Ihrer Website sitzt.
Oft tritt es sporadisch auf und trifft manche Besucher und andere nicht, was die Reproduktion zur Qual macht. Automatisierter Traffic — Uptime-Monitore, SEO-Crawler, Checkout-Monitoring wie Relvato — läuft weit zuverlässiger hinein als Sie selbst.
Die Ursache: ein Cookie, das nie ankommt
WebShield von Imunify360 fordert Besucher heraus, bei denen es unsicher ist, und setzt nach bestandener Prüfung ein Cookie, damit nicht erneut gefragt wird. Der gesamte Mechanismus hängt daran, dass dieses Cookie den Browser erreicht.
Cloudflare zerstört das, sobald es Ihr HTML mit überschriebener TTL cacht. In Cloudflares eigenen Worten zu Cache Everything: „Respects cache headers from the origin web server unless Edge Cache TTL is also set in the Page Rule. When combined with an Edge Cache TTL > 0, Cache Everything removes cookies from the origin web server response.“
Cloudflare legt also die Challenge-Seite ab und liefert sie an alle aus — ohne das Cookie. Der Besucher besteht die Prüfung, bekommt eine gecachte Seite zurück, auf der weiterhin „verifying“ steht, und beginnt von vorn. Das ist die Schleife — und für sich genommen verhält sich keines der beiden Produkte falsch.
Mit einem Befehl bestätigen
Rufen Sie Ihre Startseite ab und sehen Sie sich die Header an: curl -sI https://example.com/ — bei einer normalen WordPress-Website sollte das HTML-Dokument nicht aus einem CDN-Cache kommen.
Zwei Dinge zusammen bestätigen den Konflikt. Erstens cf-cache-status: HIT zusammen mit einem Age:-Header auf dem HTML-Dokument — Cloudflare liefert Ihre Seite aus dem Edge-Cache. Zweitens kein Set-Cookie-Header in dieser Antwort, weil die gecachte Kopie keines mitbringt. Sehen Sie außerdem cf-edge-cache: cache,platform=wordpress, dann markiert das Cloudflare-WordPress-Plugin Ihr HTML als cachebar.
Für die andere Hälfte sehen Sie in den Seitenquelltext und suchen nach imunify-bot-check. Wird dieser Link in Ihre Seiten eingefügt, prüft WebShield aktiv Besucher.
Wo die Einstellung heute liegt (Page Rules sind abgekündigt)
Alle älteren Anleitungen sagen, Sie sollen eine Page Rule bearbeiten. Cloudflare hat Page Rules zugunsten eigener Produkte abgekündigt, die Einstellungen sind umgezogen: Caching liegt jetzt unter Caching → Cache Rules.
Öffnen Sie Caching → Cache Rules und darin die Regel, die Ihr HTML „Eligible for cache“ macht. Scrollen Sie zum Abschnitt „Then…“. Ist unter Edge TTL die Option „Ignore cache-control header and use this TTL“ gewählt, ist das der heutige Name der alten Edge Cache TTL — und genau das entfernt das Cookie. Wählen Sie stattdessen „Use cache-control header if present, bypass cache if not“ und speichern Sie.
Legen Sie dann eine zweite Regel darüber an, die die Challenge komplett aus dem Cache hält: If URI Path contains /imunify-bot-check → Cache eligibility: Bypass cache. Es lohnt sich, denselben Bypass auf /wp-login.php und /wp-admin auszuweiten — die gehören ohnehin nie in einen geteilten Cache.
Leeren Sie danach den Cache, sonst denken Sie, es habe nicht funktioniert. Die Änderung verhindert, dass der Cache neu gefüllt wird — eine vor der Änderung gespeicherte Kopie wird aber weiter ausgeliefert, bis ihre alte TTL abläuft. Bei zwei Stunden TTL sind das bis zu zwei weitere Stunden derselben Schleife. Gehen Sie zu Caching → Configuration → Purge Everything. Prüfen Sie dann die Header erneut: Ihr HTML sollte nicht mehr mit cf-cache-status: HIT und einem Age-Header zurückkommen.
Wenn Sie APO oder das Cloudflare-WordPress-Plugin nutzen
Automatic Platform Optimization cacht Ihr HTML bewusst am Edge und weiß durchaus, dass es den Cache umgehen muss, wenn es WordPress-eigene Login-Cookies sieht. Das Cookie von Imunify360 gehört nicht dazu und löst diesen Bypass daher nicht aus.
Eigene Bypass-Cookies lassen sich hinterlegen, aber nur in den Tarifen Business und Enterprise — in Free und Pro steht die Option nicht zur Verfügung. Wenn Sie auf Pro sind und die Schleife die obigen Änderungen überlebt, ist das Abschalten des HTML-Cachings (APO deaktivieren oder die Regel entfernen, die HTML cachebar macht) der verlässliche Ausweg. Bilder, CSS und JS bleiben gecacht — dort liegt ohnehin der größte Nutzen.
Die Origin-Seite und was Sie Ihrem Hoster sagen
Alles bisher Genannte betrifft Cloudflare — und meist ist das die komplette Lösung. WebShield selbst läuft auf Ihrem Server, in der Regel vom Hoster installiert, und in cPanel gibt es dafür oft keinen Schalter. Vergewissern Sie sich also, dass der Cache wirklich behoben ist, bevor Sie ein Ticket eröffnen.
Das ist wichtiger, als es klingt. In einem realen Shop meldete das Monitoring tagelang harte HTTP-403-Fehler und sah exakt nach einer Firewall-Blockade aus, die nur der Hoster aufheben kann. Nach der Edge-TTL-Änderung und dem Leeren des Caches liefen beim allernächsten Durchlauf alle Checks durch — ohne jede Änderung am Server, inklusive der Checkout-Seite, die zuvor nie durchgelaufen war. Eine gecachte Challenge und eine echte Blockade sind von außen nicht zu unterscheiden.
Schlagen die Checks weiterhin fehl, nachdem Sie bestätigt haben, dass der Cache sauber ist, treffen Sie WebShield selbst — dann muss Ihr Hoster handeln. Speziell fürs Monitoring sendet Relvato bei jeder Anfrage einen festen geheimen Header — X-Relvato-Token, sichtbar in den Einstellungen Ihrer Website —, sodass Ihr Hoster genau diesen Traffic erlauben kann, ohne sonst etwas zu schwächen. Eine Regel auf CDN-Ebene kann das nicht leisten: Imunify blockiert am Origin, nachdem Cloudflare die Anfrage bereits durchgelassen hat.
Alte Page-Rule-Ratschläge, übersetzt ins heutige Dashboard
| Ältere Artikel sagen | Wo es heute liegt | Was einzustellen ist |
|---|---|---|
| Page Rule → „Cache Everything“ | Caching → Cache Rules → Cache eligibility | Eligible for cache |
| Page Rule → „Edge Cache TTL“ | Dieselbe Regel → Edge TTL | NICHT „Ignore cache-control header and use this TTL“ |
| „Edge Cache TTL entfernen“ | Dieselbe Regel → Edge TTL | „Use cache-control header if present, bypass cache if not“ |
| Cache für die Challenge umgehen | Eine Cache Rule darüber | URI Path contains /imunify-bot-check → Bypass cache |
| Bypass über ein eigenes Cookie | Cache Rules / APO Bypass-Cookies | Nur Business und Enterprise |
Fragen
Liegt es an Imunify360 oder an Cloudflare?
An keinem von beiden allein. Imunify360 merkt sich per Cookie, dass ein Besucher die Prüfung bestanden hat, und Cloudflare cacht — wenn es HTML mit überschriebener TTL cachen soll — die Seite und entfernt Cookies aus der Origin-Antwort. Beide verhalten sich wie dokumentiert; zusammen blockieren sie sich.
Wird meine Website langsam, wenn ich HTML-Caching abschalte?
Deutlich weniger, als Sie denken. Bilder, CSS, JavaScript und Schriften machen den Großteil dessen aus, was ein Browser lädt, und bleiben so oder so am Edge gecacht. Sie verlieren gecachtes HTML — das ein guter serverseitiger Seiten-Cache (LiteSpeed Cache, WP Rocket) weitgehend ersetzt.
Warum sind nur manche Besucher betroffen?
WebShield prüft, was es für verdächtig hält — die meisten menschlichen Besucher auf gewöhnlichen Anschlüssen kommen durch und sehen nie etwas. Rechenzentrums-IPs und automatisierte Clients (Monitore, Crawler, API-Nutzer) werden weit häufiger geprüft und stoßen deshalb zuerst auf das Problem.
Ich habe den Cloudflare-Cache geleert, es kam zurück.
Das Leeren entfernt den Cache, ändert aber nicht die Regel, die ihn wieder füllt. Innerhalb von Minuten ist die Challenge-Seite erneut gecacht. Sie müssen die Edge-TTL-Einstellung ändern oder den Pfad umgehen — Leeren allein genügt nicht.
Kann ich das über cPanel lösen?
Meistens nicht. Imunify360 wird von Ihrem Hoster auf Serverebene installiert und konfiguriert, sodass die meisten cPanel-Nutzer keine WebShield-Einstellungen haben. Die Cloudflare-Seite können Sie selbst ändern; alles innerhalb von Imunify360 läuft über den Hoster.
Behebt das auch, dass mein Uptime-Monitor oder Crawler blockiert wird?
Sehr wahrscheinlich — und das sollten Sie testen, bevor Sie etwas anderes verantwortlich machen. Automatisierte Clients werden weit häufiger geprüft als Menschen, hängen deshalb zuerst in der Schleife und melden das als harte Blockade. Im oben genannten Fall lief ein Monitoring, das tagelang mit 403 scheiterte, direkt nach dem Cache-Fix beim nächsten Durchlauf grün — ohne jede Serveränderung. Cache beheben, leeren, erneut laufen lassen — und erst dann den Hoster kontaktieren.
Mein Monitoring wird nach dem Cache-Fix weiterhin blockiert.
Dann treffen Sie WebShield selbst und nicht die Cache-Schleife — der Cache-Konflikt und eine Blockade am Origin sind zwei getrennte Probleme. Bitten Sie Ihren Hoster, den Header des Monitors auf Imunify360-Ebene freizugeben; eine Cloudflare-Regel kann keine Firewall umgehen, die hinter Cloudflare läuft.