HTTP-Header- und Weiterleitungs-Prüfer

Verfolgen Sie eine URL Schritt für Schritt und lesen Sie, was zurückkommt: jede Weiterleitung in der Kette, den Statuscode, mit dem sie am Ende antwortet, und die Header, die sie sendet. Derselbe Weg, den ein Uptime-Check geht, ohne Cache, Cookies oder Edge-Server Ihres Browsers dazwischen.

GET von unserer Probe · bis zu 10 Schritte · nur Header, nie der Inhalt · nichts wird gespeichert

Geben Sie eine URL ein, um ihre Kette zu verfolgen.

Was jeder Weiterleitungscode bedeutet

Die Zahl ist keine Dekoration. Sie sagt einem Client, ob er sich die neue Adresse merken soll und ob die Anfragemethode den Sprung übersteht, und ein Fehler hier ist der Grund, warum ein funktionierendes Formular plötzlich Daten verliert.

Code	von Clients gecacht	Methode bleibt erhalten	verwenden für
301 Moved Permanently	ja, aggressiv	nein, POST wird meist zu GET	Eine Adresse, die nie zurückkommt. Schwer rückgängig zu machen: Browser behalten sie.
302 Found	nein	nein, POST wird meist zu GET	Ein vorübergehender Umzug. Der Standard, den die meisten Frameworks senden, und der sichere, solange Sie sich noch nicht entschieden haben.
303 See Other	nein	nein, wird immer zu GET	Nach dem Absenden eines Formulars, damit ein Neuladen es nicht doppelt sendet.
307 Temporary Redirect	nein	ja	Ein vorübergehender Umzug, bei dem ein POST ein POST bleiben muss.
308 Permanent Redirect	ja	ja	Ein dauerhafter Umzug für eine API, bei der ein POST, der zu GET wird, die Aufrufer brechen würde.

Warum sich ein Blick auf die Kette lohnt

Sie sehen ERR_TOO_MANY_REDIRECTS? Folgen Sie wie man eine Weiterleitungsschleife Schritt für Schritt debuggt, um die Antworten nachzuverfolgen und die Anwendungs- oder Proxy-Regel zu finden, die die Anfrage zurückschickt.

Ein Monitor verzeichnet die Antwort am Ende des Weges. Eine funktionierende Kette ist also unsichtbar, und eine kaputte sieht aus, als wäre die Website ausgefallen. Zwei Fehler verstecken sich darin: eine Schleife, bei der ein CDN HTTPS erzwingt, während der Ursprungsserver HTTPS zurück auf HTTP schickt, und ein Schritt, der still den Host verlässt, mit dem Sie begonnen haben, wobei Cookies und Authorization-Header unterwegs verloren gehen.

Auch die Länge kostet. Jeder Schritt ist eine neue Verbindung, eine neue DNS-Abfrage und bei HTTPS ein neuer Handshake. Drei Weiterleitungen vor einer Startseite sind fast eine Sekunde, bevor das erste Byte echten Inhalts ankommt, bezahlt von jedem Besucher und jedem Check.

Dieser Prüfer validiert das Zertifikat bei jedem Schritt, so wie ein Monitor, ein TLS-Fehler hier ist also echt. Wenn Sie ein bereits abgelaufenes oder selbstsigniertes Zertifikat lesen müssen, liest der SSL-Zertifikatsprüfer es ohne Validierung. Liegt das Problem beim Namen selbst, vergleicht die DNS-Abfrage zwei Resolver, und was ICMP, TCP und HTTP jeweils beweisen erklärt, auf welcher Schicht ein Fehler tatsächlich liegt. Für Zertifikat, HTTPS-Weiterleitungen und Sicherheits-Header gemeinsam bewertet nutzen Sie den Website-Sicherheitsprüfer.

Häufige Fragen

Was verursacht ERR_TOO_MANY_REDIRECTS?

Zwei Regeln, von denen jede glaubt, die andere hätte die Arbeit erledigen sollen. Das klassische Paar ist ein CDN, das HTTPS erzwingt, während der Ursprungsserver HTTPS zurück auf HTTP weiterleitet, sodass die Kette endlos zwischen beiden hin- und herspringt. Die Schrittliste oben zeigt den Kreis: Achten Sie auf dieselbe URL, die zweimal erscheint.

Welche Weiterleitungscodes behalten die Anfragemethode bei?

307 und 308 behalten sie bei, ein POST bleibt also ein POST. 301 und 302 garantieren das nicht, und in der Praxis macht fast jeder Client daraus ein GET. 303 wird immer zu GET. Wenn ein Formular erst nach einer neu eingerichteten Weiterleitung nicht mehr funktioniert, liegt es meist daran.

Warum zeigt mein Browser etwas anderes?

Ein Browser antwortet aus seinem eigenen Cache, sendet Ihre Cookies und hat womöglich einen anderen Edge-Server zugewiesen bekommen als wir. Die erste Anfrage einer Sitzung ist die ehrliche, und genau die führt diese Prüfung aus: keine Cookies, kein Cache, jedes Mal eine neue Verbindung.

Die Prüfung schlägt hier fehl, aber die Website lädt bei mir. Warum?

Meist liegt es am Zertifikat. Dieser Prüfer validiert die Kette so wie ein Monitor, ein abgelaufenes Zertifikat oder ein fehlendes Zwischenzertifikat scheitert also sofort, während Ihr Browser es womöglich aus dem Cache überspielt. Der SSL-Zertifikatsprüfer liest das Zertifikat ohne Validierung und ist das Werkzeug für diesen Fall.

Sollte ein Uptime-Monitor Weiterleitungen folgen?

Folgen Sie ihnen, wenn Sie beobachten, ob Menschen die Website erreichen, denn das ist der Weg, den sie gehen. Schalten Sie das Folgen ab, wenn Sie einen bestimmten Endpunkt beobachten und eine Weiterleitung bedeuten würde, dass sich etwas geändert hat: Eine API-Route, die plötzlich mit 302 antwortet, ist eine Störung, kein Erfolg.

Welche Antwort-Header sind für die Verfügbarkeit wichtig?

Zuerst der Statuscode, dann alles, was einen schlechten erklärt: Retry-After bei einem 429 oder 503, Cache- und Edge-Header, die sagen, ob ein CDN statt Ihres Ursprungsservers geantwortet hat, und Location bei einer Weiterleitung. Sicherheits-Header wie HSTS beeinflussen die Verfügbarkeit nicht, die Kette, die sie setzt, aber oft schon.

Die Kette überwachen, nicht nur die Startseite

Ein HTTP-Check geht diese Schritte jede Minute aus jeder Region, die Sie aktivieren, und meldet sich, wenn sich der Status an ihrem Ende ändert.

kostenlos starten

weitere kostenlose Tools: SLA-Rechner · Cron-Generator · Fehlerbudget-Rechner · Generator für Störungsmeldungen · DNS-Abfrage · SSL-Zertifikatsprüfer · Domain-Ablaufprüfer · Website-Sicherheitsprüfer · alle Tools