Redirect-Schleife: So finden und beheben Sie ERR_TOO_MANY_REDIRECTS

Eine Redirect-Schleife ist eine Kette von HTTP-Weiterleitungen, die nie ankommt: URL A schickt den Browser zu URL B, B schickt ihn zurück zu A, und nach etwa zwanzig Hops gibt der Browser auf und zeigt ERR_TOO_MANY_REDIRECTS an. Auf der Zielseite ist nichts kaputt. Zwei Regeln sind sich schlicht uneinig darüber, wo die URL hingehört, und jede macht ständig rückgängig, was die andere tut.

Eine Redirect-Schleife ist einer der wenigen Webfehler, der seine eigene Ursache benennt, solange Sie auf das Richtige schauen. Nicht den Browser, nicht die Fehlerseite und ganz sicher nicht den Cache: die Redirect-Kette. Jeder Hop trägt einen Location-Header, und die beiden Adressen, die sich ständig wiederholen, sind die beiden Regeln, die Sie in Einklang bringen müssen. Dieser Leitfaden führt durch die Diagnose mit einem Befehl, durch die Ursachen hinter fast jedem Redirect-Zyklus, den ich je entwirren musste, und durch die Lösung, die nicht heimlich anderswo eine zweite Schleife erzeugt. Falls die Redirect-Familie selbst unklar ist, ist Arten von URL-Weiterleitungen die Landkarte; dies hier ist die Troubleshooting-Version.

Was ERR_TOO_MANY_REDIRECTS wirklich bedeutet

Browser folgen Redirects in Ihrem Auftrag, aber nicht ewig. Jeder Client führt ein Hop-Budget und bricht die Anfrage ab, wenn es aufgebraucht ist: Chrome stoppt bei 20 und lässt sich nicht ändern, Firefox liefert denselben Standardwert unter network.http.redirection-limit, und curl erlaubt 50, bevor es sich beschwert. Der Standard lässt die Zahl offen. RFC 9110 sagt nur, dass ein Client zyklische Weiterleitungen erkennen und eingreifen sollte, was die höfliche Art der Spezifikation ist zu sagen, dass jeder Browser einen Schutzschalter braucht.

Diese Unterscheidung ist für die Diagnose wichtig, denn der Fehler beweist überhaupt nicht, dass es einen Zyklus gibt. Eine Kette aus einundzwanzig verschiedenen Hops ohne Wiederholungen löst genau dieselbe Meldung aus wie zwei URLs, die ewig hin- und herspringen. Beide sind es wert, behoben zu werden, aber nur bei einem gibt es ein Adresspaar, das in Einklang zu bringen ist. MDNs Referenz zu Weiterleitungen deckt beide Formen ab, und der praktische Unterschied zeigt sich in dem Moment, in dem Sie die Kette ausdrucken.

Noch etwas, das die Fehlerseite verbirgt: Eine permanente Weiterleitung wird vom Browser gecacht. Wurde die Schleife aus 301-Antworten gebaut, bleiben Besucher lokal in der Schleife gefangen, selbst nachdem Sie den Server korrigiert haben, bis dieser Cache-Eintrag abläuft oder sie ihn löschen. Genau diese Tatsache ist der Grund, warum ich Redirect-Änderungen mit einem 302 teste und erst zu 301 befördere, sobald die Kette stimmt - eine Gewohnheit, für die 301 vs. 302 Redirects die vollständige Begründung liefert.

Die Redirect-Kette mit einem Befehl verfolgen

Überspringen Sie den Browser. Der schnellste Weg, eine Redirect-Schleife zu lesen, ist das Terminal, denn curl gibt jeden Hop aus, statt sie zu einer einzigen Fehlerseite zusammenzufalten:

curl -sIL https://example.com | grep -E '^HTTP|^[Ll]ocation'

Sie erhalten pro Hop eine Statuszeile und einen Location-Header, in der richtigen Reihenfolge. Lesen Sie von oben nach unten, und eines von drei Mustern zeigt sich. Zwei abwechselnde URLs bedeuten einen echten Zyklus, und das Paar benennt beide fehlerhaften Regeln. Ein langer Zug unterschiedlicher URLs bedeutet eine Kette, die jemand über die Jahre aufgeschichtet hat, wobei jeder Hop für sich genommen legitim ist. Und eine Kette, die im Terminal problemlos auflöst, im Browser aber weiterhin fehlschlägt, bedeutet, dass die Schleife cookie-getrieben ist, da curl standardmäßig keine Cookies sendet.

Dieser letzte Fall verdient eine eigene Prüfung, denn es ist der, bei dem Leute einen ganzen Nachmittag lang ihr DNS beschuldigen:

curl -sIL -c jar.txt -b jar.txt https://example.com/account | grep -E '^HTTP|^[Ll]ocation'

Mit angehängtem Cookie-Jar lässt sich eine Login- oder Consent-Schleife auf der Kommandozeile reproduzieren, wo Sie tatsächlich sehen können, welcher Endpunkt die Sitzung ständig setzt und dann ablehnt. Im Browser ist die entsprechende Ansicht das Network-Panel mit aktiviertem "Preserve log", das verhindert, dass frühere Hops beim Navigieren der Seite gelöscht werden. Wenn Sie lieber gar kein Terminal öffnen möchten, verfolgt unser Link-Checker die Kette im Browser und gibt bei jedem Hop den Statuscode aus.

Die Ursachen hinter fast jedem Redirect-Zyklus

Sobald Sie die Kette sehen können, ist die Ursache meist eine von einer Handvoll. Das sich wiederholende URL-Paar verrät Ihnen, welche Ebene Sie sich ansehen müssen: Wechselt das Schema hin und her, deutet das auf TLS-Terminierung hin, wechselt der Hostname, deutet das auf eine Canonical-Host-Regel hin, und ein Pfad, der ständig einen Schrägstrich gewinnt und verliert, deutet auf die Reihenfolge der Rewrite-Regeln hin.

HTTPS-Regeln hinter einem Proxy, der TLS terminiert

Das ist die häufigste Endlos-Weiterleitung im modernen Web, und sie tauchte in dem Moment auf, in dem Proxys begannen, TLS vor Origins zu terminieren. Der Proxy nimmt eine HTTPS-Anfrage vom Besucher an und ruft dann Ihren Origin über reines HTTP ab. Ihr Origin sieht eine unsichere Anfrage, tut, wozu Sie ihn angewiesen haben, und leitet zu HTTPS weiter. Der Proxy liefert diese Weiterleitung aus, wird erneut angefragt, ruft den Origin wieder über HTTP ab, und so dreht sich alles im Kreis. Cloudflare dokumentiert genau diesen Fehler unter seinem Flexible-Verschlüsselungsmodus, und jeder andere Proxy hat dieselbe Falle unter einem anderen Namen.

Es gibt zwei saubere Lösungen. Stellen Sie den Proxy auf den Full-Verschlüsselungsmodus um, sodass er mit Ihrem Origin über TLS spricht - das ist in fast jedem Fall die richtige Antwort. Oder, falls der Hop zum Origin tatsächlich unverschlüsselt bleiben muss, lassen Sie die Regel des Origins den X-Forwarded-Proto-Header statt der rohen Verbindung auslesen, damit sie aufhört, Anfragen umzuleiten, die am Edge bereits sicher waren.

www und Apex sind sich uneinig, welcher Host gewinnt

Eine Canonical-Host-Regel ist in Ordnung. Zwei davon, zu unterschiedlichen Zeiten von unterschiedlichen Personen geschrieben, ergeben eine Schleife. Die klassische Version hat eine Server-Konfiguration, die die Apex-Domain zu www schickt, während die Anwendungskonfiguration www zurück zur Apex-Domain schickt, und beide sind sich sicher, im Recht zu sein. Sie sehen es sofort in der Kette: example.com zu www.example.com zu example.com, endlos.

Entscheiden Sie sich für einen Host, erzwingen Sie ihn an genau einer Stelle, und löschen Sie die andere Regel, statt zu versuchen, sie in Einklang zu bringen. Dasselbe gilt für ein Trailing-Slash- oder Kleinschreibungs-Rewrite: Wenn zwei Regeln dieselbe URL in entgegengesetzte Richtungen normalisieren, erhalten Sie einen Redirect-Zyklus, obwohl jede Regel für sich genommen sinnvoll ist.

Die CMS- oder App-URL-Einstellung, die nicht mehr passt

Die meisten Anwendungen speichern ihre eigene kanonische Adresse, und dieses Feld ist eine Redirect-Regel mit einem freundlichen Namen. Ändern Sie die Domain, wechseln Sie in eine neue Umgebung oder stellen Sie einen Datenbank-Snapshot von einem anderen Host wieder her, und die App beginnt, jede Anfrage zu einer Adresse umzuleiten, die zurückverweist. Da die Einstellung in der Datenbank lebt und nicht in Ihrer Webserver-Konfiguration, übersteht sie das Konfigurations-Audit, das Sie gerade durchgeführt haben, weshalb sie so lästig zu finden ist.

Das Erkennungsmerkmal ist eine Kette, die Ihren aktuellen Hostnamen verlässt und nie zu ihm zurückkehrt. Korrigieren Sie die gespeicherte Adresse auf die Domain, die Sie tatsächlich ausliefern, und leeren Sie dann jeden Anwendungs- oder Seiten-Cache, der die falsche erfasst hat.

Cookie- und Session-Schleifen, die nur angemeldete Nutzer betreffen

Hier sind die Regeln unschuldig, und der Zustand ist das Problem. Ein Gate leitet nicht authentifizierte Besucher auf eine Login-Seite um, die Login-Seite leitet authentifizierte zurück, und ein Session-Cookie, das auf der Zieldomain nicht gelesen werden kann, lässt beide Seiten überzeugt sein, die jeweils andere solle sich darum kümmern. Consent-Banner verursachen dieselbe Form, wenn die Weiterleitung, die das Consent-Cookie setzt, selbst blockiert wird.

Das Erkennungsmerkmal ist dasselbe wie im vorherigen Abschnitt: Ein sauberes privates Fenster funktioniert, oder curl ohne Cookie-Jar löst normal auf. Prüfen Sie den Domain- und Path-Geltungsbereich des Cookies, seine Secure- und SameSite-Attribute gegen das Schema, das Sie tatsächlich ausliefern, und ob es auf der Apex-Domain gesetzt, aber auf www gelesen wird.

Redirect-Schleifen sind selten mysteriös, sobald die Kette auf dem Bildschirm steht, aber sie fressen einen Nachmittag, wenn Sie raten statt zu verfolgen. Wenn Sie die Redirect-Ebene lieber besitzen als sich mit ihr zu streiten, gibt Ihnen Elidos kostenloser Plan Links, deren Ziel ein einzelner gespeicherter Wert ist, den Sie neu ausrichten können, wobei jeder Hop protokolliert wird.

Beheben, ohne eine zweite Schleife zu erzeugen

Die Reparatur selbst ist kurz, und die Reihenfolge zählt mehr als die Syntax. Ändern Sie eine Regel, dann verfolgen Sie erneut. Drei zu ändern und neu zu laden, verrät Ihnen nichts darüber, welche davon entscheidend war, und ich habe ein Team beobachtet, das auf diese Weise eine Stunde mit einer Schleife verbrachte, die von einer Regel verursacht wurde, die sie beim ersten Versuch bereits korrigiert hatten.

1. Entfernen oder kehren Sie genau eine der beiden von der Kette benannten Regeln um, sodass eine Anfrage in einem einzigen Hop einen 200 erreichen kann.
2. Führen Sie die curl -sIL-Verfolgung erneut aus und bestätigen Sie, dass die Kette jetzt höchstens eine Weiterleitung umfasst, ohne wiederholten Hostnamen.
3. Leeren Sie den Cache des Browsers, oder testen Sie in einem privaten Fenster, denn jeder 301, den Sie zuvor ausgeliefert haben, ist lokal noch gecacht und täuscht einen Fehler vor, der nicht mehr existiert.
4. Erst dann befördern Sie temporäre Weiterleitungen zu permanenten, sobald die Form der Kette feststeht.

Am Ende dieser Liste lauern zwei Fallen. HSTS ist eine davon: Sobald ein Host einen Strict-Transport-Security-Header gesendet hat, stufen Browser jede Anfrage von sich aus auf HTTPS hoch, sodass eine Origin-Regel, die ebenfalls HTTPS erzwingt, jetzt redundant ist und eine Proxy-Fehlkonfiguration in eine Schleife verwandeln kann, die Sie ohne Löschen des HSTS-Eintrags nicht reproduzieren können. Die andere Falle ist Caching vor der Schleife. Ein CDN, das einen 301 gecacht hat, liefert ihn munter weiter aus, nachdem der Origin aufgehört hat, ihn zu senden, weshalb ein Purge zur Lösung gehört und nicht danach kommt. Lange Ketten, die nie in eine Schleife münden, lohnt es sich im selben Zug zu kürzen: Jeder zusätzliche Hop ist eine weitere Gelegenheit, dass ein Query-String verloren geht, genau so, wie UTM-Parameter in GA4 verlorengehen, und das ist mit ein Grund, warum Kurzlinks der SEO nicht schaden müssen, solange sie nur einen Hop tief bleiben.

Wenn die Schleife bei einem Kurzlink liegt

Kurzlinks fügen eine weitere Stelle hinzu, an der ein Zyklus entstehen kann, und es ist nicht die Weiterleitung des Shorteners. Ein Kurzlink ist ein einzelner gespeicherter Hop: Slug rein, Ziel raus. Die Schleife entsteht, wenn das Ziel zurückverweist, was häufiger vorkommt, als es klingt. Jemand bearbeitet einen Kampagnenlink so, dass er auf eine Landingpage zeigt, die Landingpage hat eine alte Regel, die zur Kurz-URL weiterleitet, weil das letztes Quartal die kanonische Share-Adresse war, und jetzt springen die beiden hin und her. Beide Hops verhalten sich genau wie konfiguriert.

Zwei weitere Varianten zeigen sich in derselben Kette. Die eine ist ein Paar von Kurzlinks, die nach einer Massenbearbeitung aufeinander verweisen, meist aus einem Tabellenimport, bei dem die Ziel-Spalte Kurz-URLs statt endgültiger Adressen enthielt. Die andere ist eine eigene Domain, die weiterhin auf einen Host auflöst, der zurück zum Shortener leitet - ein DNS-Überbleibsel und kein Link-Problem, und eigene Domains für Kurzlinks behandelt, wie die Einträge aussehen sollten. In allen drei Fällen besteht die Lösung darin, das Ziel auf die endgültige Seite zu setzen statt auf einen weiteren Redirect, was Sie tun können, ohne irgendetwas bereits Gedrucktes oder Veröffentlichtes anzufassen.

Weil das Ziel gespeichert und nicht fest in die URL eingebacken ist, braucht nichts davon einen Neudruck. Das ist das ganze Argument für verwaltete Links, und Kurzlink funktioniert nicht ist der breitere Triage-Leitfaden, wenn das Symptom nicht speziell eine Schleife ist.

Verhindern, dass die nächste Schleife live geht

Redirect-Schleifen sind ein Configuration-Drift-Bug, also sind die dauerhaften Lösungen die langweiligen. Behalten Sie die Canonical-Host-Entscheidung an genau einer Stelle, und behandeln Sie jede zweite Regel, die Schema oder Hostnamen berührt, sofort als Bug. Verfolgen Sie neue Redirects mit curl -sIL, bevor Sie sie ankündigen, nicht nachdem jemand eine leere Seite meldet. Wenn Links für den Umsatz zählen, richten Sie eine Prüfung dafür ein: Eine geplante Verfolgung, die fehlschlägt, wenn die Kette über einen Hop hinauswächst, fängt Drift lange ab, bevor ein Kunde es tut, und Link-Redirect-Monitoring zeigt, wie sich das mit echtem Alerting verdrahten lässt.

Die umfassendere Gewohnheit besteht darin, Ziele als Daten zu behandeln, die Sie auditieren können. Vermeidung von Linkfäule behandelt dieselbe Disziplin für Links, die still und leise aufhören aufzulösen, und es ist so oder so dieselbe wöchentliche Prüfung. Ehrlich gesagt wurden die meisten Schleifen, die ich gesehen habe, von zwei kompetenten Personen verursacht, die jeweils dasselbe Problem in einer anderen Ebene behoben haben, einen Monat auseinander. Schreiben Sie die Regel einmal auf, und die Schleife wird unmöglich.

Die Grundlagenserie lesen

Dieser Beitrag gehört zum Engineering-Cluster. Für die Form des Redirect-Pfads selbst behandelt p95 unter 15 ms für Redirects erreichen, was ein einzelner, wohlerzogener Hop kostet, und Arten von URL-Weiterleitungen behandelt, welcher Statuscode wohin gehört, bevor Sie anfangen, Regeln zu stapeln.

Verwandte Beiträge im Blog

• Arten von URL-Weiterleitungen: 301, 302, 307, 308 und mehr
• 301 vs. 302 Redirects: Welchen sollten Kurzlinks verwenden
• Kurzlink funktioniert nicht? Diagnostizieren Sie es mit einem Befehl
• Eigene Domain-Kurzlinks: DNS, TLS und der Edge
• Open-Redirect-Schwachstellen und wie man sie verhindert
• Kurzlink-Monitoring mit Sentry und Datadog