Die Regel liegt in der Liste. Ihr Schalter sagt Active. Sie öffnen die URL, und die alte Seite lädt, genau wie vorher. Nichts im Dashboard deutet auf ein Problem hin, denn nichts im Dashboard ist falsch: Active heißt, dass die Regel gespeichert wurde und laufen darf. Über die Frage, ob je eine Anfrage bei ihr ankam, sagt es nichts.
Diese Lücke ist die ganze Diagnose. Vier Fragen schließen sie, in dieser Reihenfolge, und jede wird von einer einzigen Anfrage beantwortet statt von einem weiteren Blick in die Konfiguration. Wir haben jede Prüfung dieses Artikels am 17. August 2026 gegen eine echte Zone im Free-Tarif laufen lassen, auch die, deren Antwort „die Regel greift nicht“ lautet — das sind die nützlichen. Wenn Sie die Methode noch wählen, ist der Vergleich aller Arten, auf Cloudflare weiterzuleiten die Landkarte; dies hier ist, was zu tun ist, wenn die gewählte Methode scheinbar nichts tut.
Frage eins: kommt die Anfrage überhaupt in Ihrer Zone an
Jede andere Erklärung setzt voraus, dass Cloudflare die Anfrage gesehen hat. Prüfen Sie das zuerst, und prüfen Sie es mit einer Regel statt mit einem Header — eine Regel ist genau das Ding, dessen Ausbleiben Sie diagnostizieren.
Legen Sie eine temporäre Redirect-Regel auf einen Pfad, den Ihre Seite nicht ausliefert, exakt passend, und zeigen Sie damit irgendwohin:
(http.request.uri.path eq "/zone-probe-9f3")Dann fragen Sie danach:
curl -sI "https://ihre-domain/zone-probe-9f3" | head -1Ein 302 heißt: Ihre Zone hat diese Anfrage beendet, Ihre Regeln laufen. Ein 404 aus Ihrer
eigenen Anwendung, oder was auch immer Ihr Origin sonst sagen würde, heißt: sie laufen nicht —
und keine noch so gute Änderung an der Redirect-Regel ändert daran etwas. Auf unserer Zone ging
die Probe von 404 vor der Regel auf 302 etwa drei Sekunden nach dem Anlegen, und zurück auf
404 nach dem Löschen, wobei das Löschen länger brauchte, um jeden Edge-Server zu erreichen,
als das Anlegen. Eine erste Antwort ist in keine Richtung ein Beweis; fragen Sie zweimal.
Bleibt die Probe negativ, gibt es drei Arten, außerhalb der eigenen Zone zu stehen, und im Dashboard sehen sie identisch aus.
Der Eintrag ist nicht geproxyt. Cloudflare formuliert die Voraussetzung deutlich:
Single Redirects and Bulk Redirects require that you proxy the DNS records of your domain (or subdomain) through Cloudflare.
Eine graue Wolke heißt nur DNS: Besucher bekommen die Adresse Ihres Origins und verbinden sich
direkt dorthin. Es gibt eine Warnung dafür, aber sie greift eng. Das Dashboard zeigt This rule
may not apply to your traffic nur dann, wenn Ihr Ausdruck einen Hostnamen nennt, für den es
keinen geproxyten Eintrag gibt. Eine Regel als http.request.uri.path eq "/" nennt keinen
Hostnamen und speichert deshalb schweigend.
Die Zone wurde nie aktiv. Wurden die Nameserver beim Registrar nie umgestellt, steht die Zone auf pending, und alles Konfigurierte ist echt, aber nicht live. Dieser Fehler hat seine eigene Signatur und seinen eigenen Artikel über unbemerkt scheiternde Weiterleitungen.
Ihr Hoster liegt ebenfalls auf Cloudflare. Das ist der Fall, der täuscht, weil auf Ihrer
Seite alles richtig aussieht. Ist Ihr Hostname bei einer Plattform aufgeschaltet, die Cloudflare
for SaaS nutzt, entscheidet die Konstruktion, die Cloudflare Orange-to-Orange nennt, wessen
Regeln laufen — und sie hat genaue Bedingungen: der Eintrag muss ein CNAME auf das Ziel des
Anbieters sein, er muss in Ihrer Zone geproxyt sein, und die beiden Zonen müssen in
verschiedenen Konten liegen. Trifft das zu, steht Ihre Zone vorn, und Ihre Regeln laufen.
Trifft es nicht zu — ein A-Record auf die Adresse des Anbieters, oder gar keine eigene Zone —,
dann ist die Zone des Anbieters die einzige, deren Einstellungen greifen, und Ihre Redirect-Regel
ist eine Notiz in einer Datei, die niemand liest. Ein Merkmal zum Nachsehen gibt es nicht:
Cloudflares Dokumentation sagt ausdrücklich, dass kein API-Feld und keine Zonen-Einstellung
meldet, ob Orange-to-Orange aktiv ist.
Zwei Fallen rund um diese Prüfung. https://ihre-domain/cdn-cgi/trace beweist, dass Sie hinter
einem Cloudflare stehen, nicht hinter Ihrem, und kann die Frage deshalb nicht klären — und
wir haben die Gegenprobe bestätigt: eine Redirect-Regel auf /cdn-cgi/trace greift überhaupt
nicht, der Endpunkt bleibt also ehrlich. Und Zonen-Analytics mit Traffic beweist, dass der
Hostname irgendwo in der Sicht Ihres Kontos auflöst, nicht dass diese Anfrage von Ihrem Ruleset
bewertet wurde.
Die Bestätigung aus dem Dashboard heißt
Cloudflare Trace, in der Beta und in
jedem Tarif. Es simuliert eine Anfrage und listet die Konfigurationen, die gegriffen haben, in
Ausführungsreihenfolge. Der Hinweis steckt schon im Eingabefeld: die URL „must include a hostname
that belongs to your account“. Nimmt Trace den Hostnamen nicht an, ist die Antwort auf Frage eins
nein. Zu beachten: Trace läuft gegen Ihre Konfiguration, nicht gegen echten Verkehr, und kann das
Routing-Problem selbst deshalb nicht sehen — das kann nur die Probe-Anfrage. Die API-Route dafür
existiert, ist aber getrennt berechtigt; ein Token, das Redirect-Regeln anlegen und löschen darf,
bekam von ihr Authentication error.
Frage zwei: passt die Regel auf das, was Sie tatsächlich senden
Hier geht die meiste Zeit hin, und ein einziges Verhalten kostet davon mehr als alles andere zusammen.
Ein Wildcard-Muster wird gegen die vollständige URL verglichen, Query-String eingeschlossen.
Cloudflares Dokumentation zu den Operatoren sagt es in einem Beispiel: eine Anfrage an
https://sub.example.com/folder2/page.html?s=value passt nicht auf *.example.com/*/page.html,
weil „http.request.full_uri includes the query string and its full value does not match“. Als
Regel zum Mitnehmen: ein Wildcard-Muster, das nicht auf * endet, passt nie auf eine Anfrage
mit Query-String. Und genau das passiert, wenn Sie die Regel testen, indem Sie ?v=2 anhängen,
um den Browser-Cache auszuhebeln. Ausgehebelt wird stattdessen die Regel, die Seite lädt normal,
und Sie schließen daraus, die Regel sei kaputt.
Hier ist dieses Paar, gemessen, zusammen mit dem übrigen Abgleichverhalten, das man kennen sollte:
| Regel | Anfrage | Ergebnis |
|---|---|---|
wildcard https://301.sh/rule-probe/*.html |
/rule-probe/x.html |
302 |
| dieselbe Regel | /rule-probe/x.html?v=2 |
404, keine Weiterleitung |
| dieselbe Regel | /rule-probe/deep/x.html |
302 — * überspringt Schrägstriche |
| dieselbe Regel | /rule-probe/x.HTML |
302 — wildcard ignoriert Groß- und Kleinschreibung |
http.request.uri.path eq "/Rule-Probe-Case" |
/Rule-Probe-Case |
302 |
| dieselbe Regel | /rule-probe-case |
404, eq unterscheidet Schreibweise |
http.request.uri.path eq "/rule-probe-slash" |
/rule-probe-slash/ |
404, der Schrägstrich gehört zum Pfad |
Die Zeile zur Schreibweise verdient einen zweiten Blick, denn die beiden Oberflächen
widersprechen sich. Der Operator wildcard ist laut Dokumentation und laut Messung
unabhängig von Groß- und Kleinschreibung; strict wildcard ist die Variante, die sie beachtet.
eq auf einem Pfad vergleicht dagegen Zeichenketten, und so passt eine Regel, die mit
Großbuchstaben aus einem Konzeptdokument abgetippt wurde, still auf nichts, was Besucher senden.
Bulk Redirects haben einen anderen Abgleich-Algorithmus, und der Unterschied wirkt in die andere
Richtung. Ein Bulk Redirect passt auf Schema, Hostname und Pfad — der Query-String nimmt am
Abgleich gar nicht teil, der Cache-Buster, der eine Wildcard-Regel killt, ist hier also egal.
An seine Stelle treten die Voreinstellungen: Subpath matching und Include subdomains sind
beide aus, solange Sie sie nicht einschalten, /blog deckt also nicht /blog/post ab, und
example.com deckt nicht www.example.com ab. Und eine Liste allein tut nichts. Cloudflare
prüft die Weiterleitungen jeder Liste, „that is enabled by a Bulk Redirect Rule“ — eine Liste
hochzuladen und die Regel, die sie einschaltet, nie anzulegen, ist ein vollständiger, stiller
Leerlauf.
Frage drei: hat etwas geantwortet, bevor Ihre Regel dran war
Die Rules-Produkte laufen in fester Reihenfolge, und eine Weiterleitung ist eine terminierende Aktion. Cloudflare sagt es ohne Einschränkung:
for terminating actions (Block, Redirect, or one of the challenge actions), rule evaluation will stop and the action will be executed immediately
Daraus folgen drei Dinge, eines davon haben wir gemessen. Zwei Redirect-Regeln, die auf dieselbe Anfrage passen: die erste gewinnt, immer — wir haben ein Paar mit verschiedenen Zielen ausgerollt, und die Antwort trug das Ziel der ersten. Single Redirects laufen in der Produktreihenfolge vor Bulk Redirects, wenn also beide eine Regel für eine URL haben, antwortet der Single Redirect. Und Page Rules, falls Sie noch welche haben, verlieren gegen all das: die modernen Rules-Produkte „take precedence over Page Rules“. Eine alte Weiterleitungs-Page-Rule ist nicht das, was gegen Ihre neue Regel kämpft. Sie ist das, was läuft, wenn Ihre neue Regel nicht passt — und das erzeugt das verwirrendere Symptom: eine Weiterleitung passiert, aber irgendwohin, wo Sie nichts konfiguriert haben.
Dieselbe Phasenreihenfolge ist der Grund, warum eine Weiterleitung an dem Edge, der sie ausliefert, nicht gezählt werden kann — das hat seinen eigenen Artikel.
Frage vier: hat sie gegriffen, während Sie auf eine gecachte Antwort schauen
Eine funktionierende Weiterleitung lässt sich leicht verstecken. Ein 301 ist eine dauerhafte
Weiterleitung, und Cloudflares Regeln senden ihn ohne Cache-Control-Header, ein Browser darf
ihn also heuristisch cachen und Sie noch lange nach der Änderung zum alten Ziel schicken.
Umgekehrt gilt dasselbe: ein Browser, der für diese URL einmal ein 200 bekam, kann es weiter
aus dem Cache liefern, während der Edge alle anderen weiterleitet. Testen Sie mit curl -sI,
das nichts cacht, bevor Sie mit einem Browser-Tab testen.
Und wenn Sie zum Cache-Buster greifen, denken Sie an Frage zwei: ein angehängtes ?v=2 ändert,
ob eine Wildcard-Regel passt. Der Standardrat, wie man einen Browser zu einem frischen Abruf
bringt, ist der Standardweg, diesen Test lügen zu lassen. Nehmen Sie ein privates Fenster, einen
anderen Browser oder curl — keinen Query-Parameter.
Wenn die Weiterleitung nie Cloudflares Sache war
Ein Fall gehört außerhalb des Baums. Liegt die Weiterleitung an Ihrem Origin — ein Rewrite in
.htaccess, eine Route im Framework —, dann hat Cloudflare keine Regel zum Auslösen und nichts
zu tracen. Es reicht weiter, was der Origin sagt, und der Origin kann sich auf eine Weise
widersprüchlich verhalten, die vom Dashboard aus unsichtbar ist. Im Juli beschrieb jemand genau
das: dieselbe URL antwortete mit 301, wenn sie durch das eine Cloudflare-Rechenzentrum lief,
und mit 200 durch ein anderes, während der Origin bei direkter Anfrage jedes Mal sauber 301
lieferte. Was auch immer die Ursache war, die Abhilfe ist strukturell. Eine Weiterleitung als
Edge-Regel antwortet, bevor der Origin überhaupt kontaktiert wird, und kann deshalb nicht davon
abhängen, was der Origin in dieser Sekunde beschließt.
Wo es unordentlich wird
Eine Regel, deren Ziel gleich ihrer Quelle ist, erzeugt eine Schleife, und Cloudflare stoppt sie
nicht. Wir haben eine Regel auf ihren eigenen Pfad zeigen lassen und der Kette folgen können:
sechs Sprünge später leitete sie immer noch auf sich selbst. Ein Browser nennt das zu viele
Weiterleitungen; eine Monitoring-Prüfung nennt es womöglich 302 und lässt es durch.
Free-Zonen bekommen 10 Single-Redirect-Regeln, und die Quote gilt pro Zone. Sie zu erreichen scheitert beim Anlegen, nicht zur Laufzeit, ist also keine Ursache dieses Symptoms — aber sehr wohl ein Grund, warum Leute Logik in eine einzige Wildcard-Regel packen, wo das oben beschriebene Query-String-Verhalten zu beißen anfängt. Die vollständige Quotentabelle steht im Artikel über die Weiterleitungslimits.
Trace bewertet inaktive Regeln nicht, was richtig und gelegentlich irreführend ist: eine abgeschaltete Regel sieht im Ergebnis genauso aus wie eine, die nicht gepasst hat. Und Trace spiegelt die Konfiguration: eine Anfrage, die Ihre Zone nie erreicht, sieht im Trace sauber aus und scheitert trotzdem in der Produktion. Deshalb kommt Frage eins zuerst und wird mit einer echten Anfrage beantwortet.
Was das über ein Portfolio kostet
Für eine Domain ist das eine Sache von zehn Minuten. Zwei curl-Aufrufe und eine temporäre Regel
sagen Ihnen, welche der vier Fragen die falsche Antwort hat, und die Abhilfe folgt daraus.
Die Rechnung ändert sich, sobald dieselbe Frage an zweihundert Domains zu stellen ist, die diesen Monat niemand geöffnet hat, denn keiner dieser Fehler meldet sich von selbst. Eine Regel, die nach einer Plattform-Migration nicht mehr passt, sieht von innen genauso aus wie eine, die funktioniert. Das ist das Argument dafür, jeder Domain dieselbe Frage nach Plan zu stellen — die Schleife aus dem Audit-Skript, wenn Sie Skripte mögen, und 301.st, wenn Ihnen lieber ist, dass das Portfolio dauerhaft beobachtet wird und sich meldet, wenn eine Zeile sich ändert. Für eine Handvoll Domains reichen das Skript und ein Cron-Eintrag völlig.