Sie haben die Weiterleitung gebaut. Das Dashboard zeigt die Domain als aktiv, die Wolke ist
orange, und die Regel liegt in der Liste, wo Sie sie gelassen haben. Dann öffnet jemand die
Domain und bekommt einen 522, oder eine Zertifikatswarnung, oder eine Seite, die ihm den
Namen zum Kauf anbietet. Nichts davon ist Ihr 301.
Die Weiterleitung ist nicht laut gescheitert. Sie ist schlicht nicht das, was antwortet, und das Dashboard ist der falsche Ort, um es zu bemerken. Drei verschiedene Fehlkonfigurationen erzeugen das, jede mit ihrer eigenen Signatur, und eine einzige Anfrage trennt sie. Das ist die Fehlerspalte des Audit-Skripts aus der Nähe, und die Kehrseite von jeder Art, auf Cloudflare weiterzuleiten: dieselben Methoden, und die Weisen, auf die jede still wird.
Die Regel griff nie, also rief Cloudflare einen Origin, der nicht da ist
Eine Weiterleitung auf einer geparkten Domain sind zwei Teile, die wie einer aussehen. Da ist
ein DNS-Eintrag, ein A-Record auf der Apex-Domain, über Cloudflare geproxyt, und da ist eine
Regel, die das Weiterleiten erledigt. Das Runbook für geparkte
Domains zeigt mit diesem Eintrag auf 192.0.2.1, und
Cloudflares eigene Notiz erklärt, warum eine Adresse, die nirgendwohin führt, die richtige Wahl
ist:
This address does not route traffic to an origin server but allows Cloudflare to apply rules, redirects, and Workers to incoming traffic.
Die Regel ist es, die das Muster funktionieren lässt. Eine Redirect-Regel läuft am Edge und
beantwortet die Anfrage dort, also öffnet Cloudflare nie eine Verbindung zu 192.0.2.1. Nehmen
Sie die Regel weg, binden Sie sie an einen Hostnamen, der nicht passt, laden Sie die Liste ins
falsche Konto, oder proxyen Sie den Eintrag, bevor die Regel existiert — und Cloudflare tut
genau das, was die orange Wolke sagt. Es proxyt die Anfrage zu 192.0.2.1. Dort lauscht
nichts, mit Absicht.
Was die Besucherin bekommt, ist ein 522. Cloudflares Definition ist wörtlich:
Error 522 occurs when Cloudflare times out contacting the origin web server.
Das Warten ist nicht sofort. Cloudflare schickt ein SYN und gibt im dokumentierten Fall auf,
wenn der Origin-Webserver nicht innerhalb von 19 Sekunden ein SYN+ACK zurückgibt, mit
Wiederholungen auf einem Backoff von 1,1,1,1,1,2,4,8. Die Domain hängt also den besseren Teil
einer halben Minute und zeigt dann eine Cloudflare-Fehlerseite. Der A-Record ist da, der
Proxy ist an, alles im DNS-Reiter sieht fertig aus, und das eine fehlende Stück hat dort keine
Spur hinterlassen.
Tauschen Sie die Platzhalter-Adresse gegen einen echten Origin, zeigt sich dieselbe fehlende
Regel als anderer Code aus derselben Familie: 521, wenn der Origin die Verbindung verweigert,
523, wenn er unerreichbar ist, 524, wenn die Verbindung sich öffnet, aber rechtzeitig keine
Antwort kommt. Die Ursache ändert sich nicht. Die Anfrage erreichte einen Origin, weil keine
Edge-Regel sie zuerst abfing.
Das gibt Ihnen das Erkennungszeichen. Eine Redirect-Regel, die greift, berührt den Origin nie,
kann also gegen keinen ein Timeout haben. Jeder 52x auf einer Domain, die weiterleiten soll,
ist der Beweis, dass die Weiterleitung für diese Anfrage nicht lief.
Full (Strict) macht aus einer Weiterleitung am Origin einen Zertifikatsfehler
Nicht jede Weiterleitung lebt am Edge. Viele sind ein 301, den der Origin-Webserver schickt,
mit Cloudflare davor. Diese Anordnung funktioniert nur, wenn Cloudflare den Origin über TLS
erreicht und das Zertifikat akzeptiert, das er vorlegt, und der SSL/TLS-Verschlüsselungsmodus
entscheidet, wie streng es damit ist.
Stellen Sie den Modus auf Full (Strict), muss das Zertifikat eines sein, dem Cloudflare traut.
Wenn der Handshake selbst nicht zustande kommt, bekommt die Besucherin einen 525:
This error indicates that the SSL handshake between Cloudflare and the origin web server failed.
Cloudflare nennt die üblichen Gründe: kein gültiges Zertifikat installiert, Port 443
geschlossen, keine SNI-Unterstützung, oder ein Cipher-Mismatch. Kommt der Handshake zustande,
aber das Zertifikat geht nicht durch, ist der Code stattdessen 526:
Cloudflare cannot validate the SSL certificate at your origin web server.
Dieser ist speziell an Full (Strict) gebunden und feuert bei einem Zertifikat, das abgelaufen oder widerrufen ist, den falschen Namen trägt, dem ein Teil seiner Kette fehlt, oder das niemand signiert hat, dem ein Browser traut. Die Weiterleitung, die der Origin schicken will, ist in Ordnung. Die Besucherin sieht sie nie, weil die Verbindung, die sie tragen würde, nie fertig wird.
Es gibt eine sanftere Fassung desselben Problems auf einer gerade hinzugefügten Domain. Universal SSL braucht Zeit zum Ausstellen und deckt eine Subdomain-Ebene ab, nicht zwei. Eine Anfrage, die eintrifft, bevor das Zertifikat aktiv ist, oder an einen Namen, den das Zertifikat nicht abdeckt, bekommt einen TLS-Fehler im Browser, bevor irgendeine Weiterleitung laufen kann.
Die Domain zog nie um, also ist Cloudflare gar nicht im Weg
Das dritte Scheitern hat keinen Cloudflare-Fehlercode, weil Cloudflare nicht beteiligt ist. Sie
legten die Zone an, Sie schrieben die Regel, und die Nameserver beim Registrar wurden nie auf
das Paar geändert, das Cloudflare vergab. Die Zone steht auf pending. Alles, was Sie
konfiguriert haben, ist echt, und nichts davon ist live.
Es gibt einen leiseren Weg, an derselben Stelle zu landen. Nameserver gesammelt zu setzen, bevor die Zonen existieren — der Instinkt bei dieser Menge — geht jetzt nach hinten los:
To prevent domain hijacking, you can no longer preset Cloudflare nameservers at your registrar before creating the respective zone in Cloudflare.
Tun Sie es trotzdem, bekommt die Zone ein anderes Paar zugewiesen, der Registrar zeigt auf Nameserver, die sie nicht bedienen, und die Domain aktiviert sich nie. Nichts in einer der beiden Oberflächen sagt, warum.
Solange die Domain pending ist, ist das, was der Registrar ausliefert, das, was die Besucherin
sieht. Oft ist das eine Parkseite, manchmal eine, die den Namen zum Verkauf anbietet, und meist
antwortet sie mit einer 200. Eine Prüfung, die nur fragt, ob die Domain oben ist, besteht,
weil etwas geantwortet hat. Es waren nur nicht Sie, und die Weiterleitung, die Sie schrieben,
schläft hinter einer Zone, die nie aufwachte.
Eine Anfrage trennt die drei
Jeder Modus beantwortet ein curl anders, weshalb das Audit die Statuszeile vor allem anderen
liest:
curl -sI "https://die-domain/"Ein 52x in der ersten Zeile heißt, Cloudflare ist im Weg und die Regel griff nicht. Ein
TLS-Fehler vor jedem HTTP-Status heißt, der Handshake zum Origin scheiterte, oder das
Edge-Zertifikat ist nicht bereit. Eine 200, oder ein 302, dessen location auf einen
Registrar zeigt statt eines 301 auf Ihr Ziel, heißt, die Domain ist gar nicht bei Cloudflare.
Das Audit-Skript legt genau das in seine Spalten CODE und
DESTINATION, und so findet man diese über ein Portfolio hinweg statt eine Domain nach der
anderen.
Wo das weniger ordentlich ist, als es aussieht
Ein 522 gegen einen echten Origin kann eher zeitweise als dauerhaft sein, meist wenn die
Origin-Firewall manche Cloudflare-IP-Bereiche blockiert und andere nicht, sodass dieselbe
Domain stündlich besteht und scheitert. Auf dem 192.0.2.1-Muster gibt es diese Unschärfe
nicht: die Adresse ist reserviert und antwortet nie, der 522 ist also jedes Mal da.
Eine pending-Zone ist der eine Fall, den das Dashboard aktiv vor Ihnen verbirgt, weil von innerhalb des Kontos nichts kaputt ist. Die Regel ist gültig, der Eintrag ist gültig, die Zone wartet nur. Der Beweis existiert allein außerhalb, in dem, was die Domain einer Anfrage zurückgibt, die nicht durch Cloudflare läuft.
Und eine Registrar-Parkseite sitzt nicht immer still auf einer 200. Manche Registrare
antworten mit einem 302 auf ihren eigenen Park-Host, was eine Weiterleitung ist, nur nicht
Ihre. Das Audit-Skript fängt das, indem es liest, wohin die location zeigt, nicht bloß, dass
eine Weiterleitung geschah. Die Codes und Definitionen hier wurden am 23. Juli 2026 gegen
Cloudflares Dokumentation geprüft.
Was ein Blick nicht liefert
Alle drei sind auf den ersten Blick grün und nur von außen sichtbar, also ist sie zu fangen eine Frage davon, jede Domain nach Plan dieselbe Sache zu fragen, statt dem Dashboard zu trauen. Für eine Handvoll Domains ist die Schleife aus dem Audit-Skript in einem Cron-Eintrag die ganze Antwort, und dort sollten Sie anfangen.
In der Größenordnung, in der ein Portfolio einen langen Schwanz von Namen trägt, die seit Monaten niemand geöffnet hat, muss die Frage fortlaufend gestellt und die Antwort gegen die letzte gehalten werden, damit eine Domain, die sich still änderte, eine Flagge hebt. Das ist der Teil, den 301.st für Sie übernimmt: dieselbe Prüfung über das ganze Portfolio, in einer Schleife, mit einer Meldung, wenn sich eine Zeile ändert. Für zwanzig Domains sind der Cron-Eintrag und das Skript wirklich genug.