Relvato hinter Cloudflare oder einer Firewall zulassen
Wenn deine Website hinter Cloudflare, Sucuri, Wordfence oder einer Host-WAF liegt, kann deren Bot-Schutz Relvatos automatische Monitore mit 403 blockieren — bevor die Anfrage deine Website erreicht. So lässt du Relvato mit einer einzigen Regel sicher durch. Die Relvato-Oberfläche ist auf Englisch, daher stehen ihre Bezeichnungen hier im Original.
Warum die Monitore ein 403 bekommen
Relvato führt deine Monitore in einem echten Browser aus. Eine Firewall oder Bot-Schutz-Schicht (häufig Cloudflare) erkennt diesen automatisierten Verkehr und blockiert ihn mit HTTP 403 am Edge — bevor er deine Website erreicht. Das ist eine harte Sperre, keine Browser-Prüfseite (Challenge), die Relvato aussitzen kann.
Deine Besucher sehen davon nichts: Es betrifft nur Relvatos Verifizierungs-Anfragen. Mit deiner Website ist alles in Ordnung — dem Edge muss nur gesagt werden, dass Relvato erlaubt ist.
Wie Relvato sich ausweist
Jede Anfrage, die Relvato an deine Website stellt, trägt einen stabilen Header, X-Relvato-Token. Sein Wert ist für deine Website einzigartig und aus deinem Signing-Secret abgeleitet — er ändert sich nie und ist nicht erratbar, also ist es sicher, in einer Firewall-Regel darauf zu matchen.
Den genauen Wert findest du in Relvato unter deiner Website → „Settings“ → „Behind Cloudflare or a firewall?“. Kopiere ihn dort.
Die Cloudflare-Regel hinzufügen
Öffne im Cloudflare-Dashboard deine Domain → Security → WAF → Custom rules → Create rule. Setze die Aktion auf Skip und aktiviere alle Managed Rules, Bot Fight Mode und Rate limiting.
Als Ausdruck matchst du den Header auf deinen Wert: http.request.headers["x-relvato-token"][0] eq "<your value>". Relvato zeigt den vollständigen Ausdruck zum Kopieren im Tab „Settings“ deiner Website. Regel veröffentlichen — der nächste Lauf sollte durchgehen.
Andere Firewalls
Dasselbe Prinzip funktioniert überall. In Sucuri, Wordfence oder einer Host-/CDN-WAF: eine Allowlist-Regel für Anfragen, bei denen der Header X-Relvato-Token deinem Wert entspricht. Wenn deine Firewall nur nach IP zulassen kann, geht auch das — aber mit einem Haken: Relvatos Monitore laufen über einen Pool von Adressen, der wechselt. Eine IP-Allowlist muss deshalb nachgepflegt werden, die Header-Regel greift dauerhaft. Die aktuell genutzten Adressen findest du unter deiner Website → „Settings“ → „Behind Cloudflare or a firewall?“ und unter https://app.relvato.com/api/egress-ips. Wo du die Wahl hast, ist der Header außerdem die präzisere Regel: Eine Adresse kann geteilt sein, ein websitespezifisches Secret nicht.
Imunify360 und andere Server-Firewalls
Imunify360, mod_security und cPanel/CSF laufen auf dem Server selbst, nicht am Edge — eine Cloudflare-Regel erreicht sie also nie, und im eigenen Hosting-Panel gibt es meist keinen Allowlist-Schalter. Genau dann schlagen Monitore weiter fehl, obwohl deine CDN-Regel aktiv ist: entweder mit einem klaren 403 oder mit einer Seite „Please wait while your request is being verified“, die als normaler 200 ausgeliefert wird.
Bitte deinen Hoster um eines von beidem: eine Regel, die Anfragen mit dem Header X-Relvato-Token und dem Wert deiner Website durchlässt — oder einen Allowlist-Eintrag für die Adressen, von denen Relvatos Monitore kommen. Bei Imunify360 ist Letzteres ein Befehl pro Adresse: imunify360-agent ip-list local add --purpose white <address> --scope group
Der Tab „Settings“ deiner Website zeigt die aktuellen Adressen und die exakten Befehle, fertig zum Einfügen ins Support-Ticket. Die maschinenlesbare Liste steht unter https://app.relvato.com/api/egress-ips — verweise deinen Hoster darauf statt auf einen in eine E-Mail kopierten Wert. Da die Adressen wechseln: Bitte deinen Hoster nach Möglichkeit um die Header-Regel und prüfe diese Liste erneut, wenn eine Blockade zurückkehrt.
Wo du Relvato zulässt, je Firewall
| Firewall | Wo eintragen | Worauf matchen |
|---|---|---|
| Cloudflare | Security → WAF → Custom rules → Skip | X-Relvato-Token entspricht deinem Wert |
| Sucuri | Firewall → Access Control → Allowlist | X-Relvato-Token entspricht deinem Wert |
| Wordfence | Firewall → zugelassene Regeln | Anfragen mit X-Relvato-Token |
| Host-/CDN-WAF | Bot- oder Sicherheitsregeln | X-Relvato-Token-Header zulassen |
| Imunify360 / Server-Firewall | Beim Hoster anfragen — Imunify360 → Zulassungsregel oder IP-Allowlist (eine CDN-Regel umgeht sie nicht) | X-Relvato-Token-Header oder Relvatos Prüfadressen |
Fragen
Ist das Matchen auf den Header sicher?
Ja. Der Wert ist ein websitespezifisches Secret, aus deinem Signing-Secret abgeleitet — einzigartig und nicht erratbar —, niemand sonst kann ihn senden. Deutlich sicherer als eine pauschale User-Agent- oder IP-Regel.
Schwächt das meine Firewall?
Nein. Die Regel überspringt den Bot-Schutz nur für Anfragen mit deinem exakten Secret-Token; jede andere Anfrage bleibt voll geschützt.
Ich nutze Bot Fight Mode / Super Bot Fight Mode.
Die sind meist die Ursache des 403. Achte darauf, dass deine Skip-Regel Bot Fight Mode abdeckt (und füge auf höheren Tarifen eine Ausnahme für Super Bot Fight Mode hinzu), damit Relvatos Anfragen daran vorbeikommen.
Es scheitert weiter, nachdem ich die Regel hinzugefügt habe.
Gib ihr eine Minute, dann starte den Monitor neu. Scheitert es weiter, prüfe, dass der Header-Wert exakt passt und die Aktion Skip ist (Allow allein umgeht Bot Fight Mode nicht).
Kann ich Relvato stattdessen per IP zulassen?
Ja. Relvatos Monitore laufen über einen kleinen, festen Satz von Adressen — der Tab „Settings“ deiner Website listet sie auf, und https://app.relvato.com/api/egress-ips liefert sie als JSON. Das ist der Weg für eine Server-Firewall wie Imunify360, die am Origin sitzt, wo eine CDN-Regel nie ankommt. Wo du wählen kannst, bleibt der Header die präzisere Regel: Er gehört nur zu deiner Website.