Die Redirect-Kette sehen, die der Browser wirklich durchlaufen hat

Ein Link landet, wo er nicht landen sollte, und Sie müssen wissen, was zwischen dem Klick und der finalen Seite passiert ist. Der übliche erste Griff ist curl, und er ist richtig: der 60-Sekunden-Test für den gclid auf dieser Seite baut auf curl -sIL, und für Server-Redirects sagt er die Wahrheit. Dann sieht die Kette im Terminal sauber aus, während der Browser trotzdem woanders landet, und das Werkzeug ist still am Ende.

Der Grund: nur ein Teil der Redirects lebt in HTTP-Antworten. Der Rest passiert in der Seite selbst oder im Browser, und kein -L bringt ihn ans Licht. Dieser Artikel handelt davon, eine Kette zu sehen, nicht davon, eine zu bauen; jede Art, auf Cloudflare weiterzuleiten, hat ihren eigenen Vergleich.

Drei Redirects, die curl Ihnen nicht zeigen kann

Ein JavaScript-Redirect ist eine 200. Der Server antwortet mit einer normalen Seite, die Seite ruft location.replace() auf oder setzt location.href, und der Browser navigiert. curl druckt HTTP/2 200, meldet keinerlei Redirect und beendet sich. Jede Zwischenseite, jeder Tracking-Hop auf Skriptbasis, jede „checking your browser“-Seite fällt in diese Klasse.

Ein Meta-Refresh ist ebenfalls eine 200. <meta http-equiv="refresh" content="0;url=..."> steht im HTML-Body, und curl parst kein HTML. Dieselbe saubere Statuszeile, dieselbe lautlose Navigation im Browser.

Ein HSTS-Upgrade verlässt den Browser nie. Nach einem Besuch auf einer Seite, die Strict-Transport-Security sendet, schreibt der Browser http:// zu https:// um, bevor überhaupt eine Anfrage gestellt wird. DevTools zeigt das als 307 Internal Redirect, eine Antwort, die der Server nie gesendet hat. curl hält standardmäßig keinen HSTS-Zustand, trifft die http://-URL also jedes Mal frisch und zeigt Ihnen die 301 des Servers, einen Hop, den Ihre wiederkehrenden Besucher längst nicht mehr nehmen.

Zur Mechanik kommt die Session. curl trägt keine Cookies, also schickt eine Kette, die nach Login-Zustand, Consent-Cookie oder A/B-Zuteilung verzweigt, curl einen anderen Weg als die Person, die das Problem gemeldet hat. Die Kette, die Sie getestet haben, ist nicht die Kette, die sie durchlaufen hat, obwohl beide echt sind.

DevTools zeigt es, wenn man es richtig hält

Der Browser kennt die volle Kette natürlich, und das Network-Panel zeigt sie, mit Zeremonie. Preserve log muss an sein, sonst leert sich das Panel bei jeder Navigation, und der Hop, um den es geht, löscht seine eigenen Spuren. Der Doc-Filter schneidet das Rauschen der hundert Subrequests weg, die eine moderne Seite macht. Server-Hops erscheinen dann als eigene Zeilen mit ihren Statuscodes.

Die clientseitigen Hops sind auch da, aber unmarkiert. Ein JavaScript-Redirect ist nur ein weiterer Dokument-Request; nichts in der Zeile sagt „das war ein Redirect“, und ihn mit der auslösenden Seite zu verbinden heißt, die Initiator-Spalte zu lesen. Ein Meta-Refresh sieht genauso aus. Einmal ist das fünf Minuten Archäologie. Bei jedem Report wünscht man sich, der Browser würde einfach Buch führen.

Ein Rekorder statt einer Observation

Genau das macht Redirect Inspector. Es ist unsere eigene Open-Source-Erweiterung (Apache 2.0, Code auf GitHub), und Version 2.3 ist ihr bisher größtes Update, der Anlass für diesen Artikel. Die Erweiterung hört auf die Request-Pipeline des Browsers und zeichnet jede Kette auf, während Sie surfen: Server-Hops mit ihren Statuscodes, clientseitige Navigationen (ein Skript oder ein Meta-Refresh) mit einem JS-Badge, und die internen Upgrades des Browsers mit HSTS markiert. Ketten werden nach Browsing-Session gruppiert, Tracking-Pixel und Werbe-Beacons sind standardmäßig ausgefiltert, und jede Karte trägt die Gesamtzeit der Kette, mit Timing pro Hop im Analyse-Drawer.

Was 2.3 hinzugefügt hat, kurz:

• Eine URL prüfen, ohne sie zu besuchen. URL in das Dock am unteren Rand des Panels einfügen; sie öffnet sich in einem unsichtbaren Hintergrund-Tab, die Kette wird über die normale Pipeline erfasst, und der Tab schließt sich selbst. Der verdächtige Link aus dem Report wird nachverfolgt, ohne je Ihren Bildschirm zu übernehmen.
• Export, der in einen Bug-Report passt. Eine saubere Zusammenfassung kopieren, die rohe Kette als JSON herunterladen oder ein fertiges curl-Kommando kopieren, das die Serverseite der Kette reproduziert und die Schleife zurück ins Terminal schließt, wo die Untersuchung begann.
• Ein Side Panel statt eines Popups auf Chrome und Edge, damit die Kettenliste offen bleibt, während Sie surfen. Firefox behält das Popup.
• Lokale Analyse. Neun Prüfungen pro Kette: Schleifen, Hops, die hin und her springen, Kettenlänge, gemischte Redirect-Typen, Auth-Bounces, Consent-Hops, Tracking-Rauschen, CDN-Erkennung, finales Ergebnis.
• Suche über alle erfassten URLs, ein rückgängig machbares Clear, Tastaturkürzel und vollständige UI-Übersetzungen in sieben Sprachen.

Der Teil, der bei einem Werkzeug zählt, das Ihren Traffic beobachtet: alles läuft lokal. Keine Konten, keine Analytics, keine Telemetrie, und standardmäßig überhaupt keine Netzwerkanfragen; erfasste Ketten liegen im Browser-Storage und verlassen die Maschine nie. Es steht im Chrome Web Store, auf Firefox Add-ons und in den Edge Add-ons.

Welches Werkzeug was sieht

Sie brauchen	curl -sIL	DevTools Network	Redirect Inspector
Server-Hops (301, 302, 307, 308)	ja	mit Preserve log	ja, beim Surfen aufgezeichnet
HSTS-Upgrade	nein, sieht jedes Mal die Server-301	als 307 Internal Redirect	als HSTS markiert
JS und Meta-Refresh	nein, beides ist eine 200	ein unmarkierter Dokument-Request	erfasst, als Client-Redirect markiert
Die Kette Ihrer Session (Cookies, Login)	nein	ja	ja
Timing	eine Gesamtzeit mit -w	pro Request, über Zeilen verteilt	Gesamtzeit pro Kette, Delta pro Hop
Eine Aufzeichnung zum Suchen und Exportieren	nein	weg, wenn das Panel schließt	Sessions, Suche, JSON- und curl-Export

Online-Redirect-Checker fehlen in der Tabelle mit Absicht: sie fragen die URL aus ihrem eigenen Rechenzentrum an. Eine Kette, die nach Land, Sprache oder Cookies verzweigt, zeigt Ihnen die Rechenzentrums-Version, also denselben blinden Fleck wie curl, plus die IP von jemand anderem.

Wo die Erweiterung endet

Die Erweiterung zeichnet auf, was Ihr Browser bekommen hat. Eine Kette, die nach Geografie verzweigt, zeigt Ihnen weiter den Zweig für Ihr Land und für niemanden sonst, und was Googlebot auf derselben URL sieht, ist eine ganz andere Frage. Die URL-Prüfung ist eine echte Navigation in einem inaktiven Tab: Ihre Cookies gelten, und der Besuch landet in Ihrer History; sie ist eine Bequemlichkeit, keine Isolationskammer. Und sie sieht Ketten nur in einem Browser zugleich, auf der Maschine, auf der sie installiert ist.

Für den Link direkt vor Ihnen ist das der ganze Job, und die Erweiterung ist kostenlos. Der Punkt, an dem sie endet, ist der Punkt, an dem die Frage wechselt: von „was ist mit diesem Klick passiert“ zu „welche meiner Domains leiten gerade falsch weiter“. Das zu beantworten heißt, dieselbe Probe nach Zeitplan an jede Domain zu schicken und mit gestern zu vergleichen, und das kann kein Browser-Werkzeug. Das Audit-Skript ist die manuelle Version dieser Antwort, und 301.st ist die Version, die dauerhaft läuft, über das ganze Portfolio, mit einem Alarm, wenn sich eine Kette ändert. Für den Tab, den Sie offen haben: Erweiterung installieren und die Kette lesen.