Zum Inhalt springen
EuroVPSEuroVPS

ERR_TOO_MANY_REDIRECTS hinter einem CDN: die zwei Einstellungen, die zusammen eine Schleife bilden.

Ein CDN, das den Origin über einfaches HTTP abruft, und ein Origin, das HTTP auf HTTPS umleitet, sind jedes für sich in Ordnung und bilden zusammen eine Schleife. Wie Sie das Paar erkennen, es mit einer einzigen Anfrage reproduzieren und beide Enden schließen.

Von EuroVPS EngineeringDer Maschinenraum

5 Min. Lesezeit
In diesem Artikel 4 Abschnitte
Kurz gesagt
  • Das Paar, nach dem Sie suchen, wenn eine Website hinter einem CDN ERR_TOO_MANY_REDIRECTS zurückgibt: ein SSL-Modus des CDN, der den Origin über einfaches HTTP abruft, und ein Origin, das HTTP zwangsweise auf HTTPS umleitet, ohne zu prüfen, was der Proxy bereits getan hat.
  • Zwei Fehler, jeder für sich harmlos. Viele Origins liefern HTTP hinter einem CDN aus, das TLS terminiert, und viele Origins erzwingen HTTPS. Nur die beiden zusammen bilden eine Schleife.
  • Die Schleife kann gar keinen Eintrag im Access-Log hinterlassen, weil die Schicht, die den Redirect beantwortet, Routineanfragen möglicherweise nicht protokolliert. Die Stille sieht aus wie kein Verkehr und lenkt die Suche in die falsche Richtung.
  • Reproduzieren Sie sie mit einer einzigen Anfrage an den Origin, auf dem Weg, den Besucher nehmen, und beheben Sie dann beide Enden, damit die Schleife sich nicht bilden kann, wie auch immer die Website vorgeschaltet ist.

Den CDN-Proxy vor einem Origin einzuschalten, der HTTPS erzwingt, genügt, um die Schleife zu starten. Beide Einstellungen sind vernünftig, und keine von beiden macht für sich allein etwas kaputt. Eine Einstellung umzuschalten und von einem Weg aus zu testen, der das CDN umgeht, sieht nach einer Lösung aus, während jeder echte Besucher weiter in der Schleife hängt.

Der Mechanismus: zwei Enden, eine Schleife

Der SSL-Modus des CDN stand auf "Flexible": Der Browser spricht HTTPS mit dem CDN, aber das CDN spricht einfaches HTTP mit dem Origin. Für sich allein eine vertretbare Einstellung. Viele Origins liefern HTTP hinter einem CDN aus, das TLS terminiert.

Der Edge des Origins wiederum leitete jede HTTP-Anfrage zwangsweise auf HTTPS um, ohne den Proxy zu kennen: Er gab den Redirect aus, ohne den Header zu prüfen, der besagt, dass diese Anfrage an der Eingangstür bereits HTTPS war. Also ruft das CDN über HTTP ab, der Origin antwortet «geh zu HTTPS», die nächste Anfrage des Browsers erreicht das CDN als HTTPS, das CDN ruft den Origin wieder über HTTP ab, und der Origin leitet erneut um. Unendlich, konstruktionsbedingt. Flexible allein ist in Ordnung. Der erzwungene Redirect allein ist in Ordnung. Nur die beiden zusammen bilden eine Schleife.

ZWEI KONFIGURATIONEN, EIN KREIS
DIE SCHLEIFE
Browser HTTPS
CDN
Origin über einfaches HTTP
301 zu HTTPS
zurück zum CDN
Origin wieder über einfaches HTTP
DIE LÖSUNG
Browser HTTPS
das CDN spricht echtes HTTPS mit dem Origin
der Origin sieht HTTPS
Seite
Die Schleife hat keinen letzten Schritt. Das ist der ganze Fehler.

Der Fehler, der nichts protokollierte

Wenn die Schicht, die den Redirect beantwortet, Routineanfragen nicht protokolliert, hinterlässt die Schleife nichts im Access-Log. Die Stille sieht aus, als wäre gar kein Verkehr angekommen, und die Untersuchung geht überallhin, nur nicht an die richtige Stelle. Die Regel: Wenn ein Fehler keine Logs hinterlässt, hören Sie auf, der Stille nachzujagen, und reproduzieren Sie den Mechanismus.

Reproduzieren Sie den Mechanismus

ONE REQUEST REPRODUCES THE LOOP
$ curl -I -H 'X-Forwarded-Proto: https' http://origin.example/
HTTP/1.1 301 Moved Permanently
Location: https://origin.example/
# told the origin the request was already HTTPS. it redirects anyway.

Eine Anfrage reproduziert die Schleife, auf dem Weg, den Besucher nehmen. Ein Test von jedem anderen Weg aus geht durch und beweist nichts.

Beheben Sie beide Enden

DAS ENDEDIE LÖSUNG
Die CDN-SeiteSSL-Modus auf "Full (Strict)" umgestellt: Das CDN spricht echtes, verifiziertes HTTPS mit dem Origin.
JEDE DER BEIDEN LÖSUNGEN BRICHT DIE SCHLEIFE. BEIDE MACHEN SIE UNMÖGLICH.Die Origin-SeiteDer Redirect wurde proxy-aware gemacht: Er prüft den Header mit dem weitergeleiteten Protokoll und schickt nie eine Anfrage zurück, die an der Eingangstür bereits HTTPS war.

Nur ein Ende einer Inkompatibilität mit zwei Enden zu beheben, lässt eine «scharf geschaltete» Konfiguration auf die nächste Änderung warten. Schließen Sie beide Enden, und es bleibt keine Kombination übrig, die kreist: das CDN pausieren, das CDN wechseln, den Origin ändern, und die Schleife hat keinen Ort mehr, an dem sie sich neu bilden könnte.

“Keines der beiden Enden war kaputt. Die beiden zusammen waren es.”

Klare Antworten

Wie behebe ich ERR_TOO_MANY_REDIRECTS hinter einem CDN?+

Prüfen Sie das Paar, nicht eine einzelne Einstellung. Wenn das CDN Ihren Origin über einfaches HTTP abruft (ein SSL-Modus nach Art von "Flexible") und Ihr Origin HTTP zwangsweise auf HTTPS umleitet, bilden sie eine Schleife. Stellen Sie das CDN auf volles, striktes HTTPS zum Origin um, und machen Sie den Redirect des Origins proxy-aware.

Warum zeigt meine Redirect-Schleife nichts in den Access-Logs?+

Die Schicht, die die Schleife bildet, protokolliert Routineanfragen möglicherweise nicht, also ist die Schleife unsichtbar. Jagen Sie nicht der Stille nach. Reproduzieren Sie den Mechanismus mit einer Anfrage an den Origin und lesen Sie, was er tut.

Was macht X-Forwarded-Proto?+

Ein Proxy setzt den Header, um dem Origin mitzuteilen, welches Protokoll der Besucher tatsächlich verwendet hat. Ein Origin, der HTTP auf HTTPS umleitet, muss ihn prüfen, sonst schickt er Anfragen zurück, die am Proxy bereits HTTPS waren, und so beginnen Schleifen.

Ist der SSL-Modus Flexible schlecht?+

Er ist ein Tausch mit einer scharfen Kante: Der Verkehr zwischen CDN und Origin ist unverschlüsselt, und zusammen mit einem erzwungenen Redirect am Origin bildet er eine Schleife. Der volle, strikte Modus, mit einem echten Zertifikat auf dem Origin, beseitigt beide Probleme.

Warum hat es funktioniert, als ich es getestet habe?+

Ein Test, der nicht durch das CDN läuft, nimmt einen anderen Weg als Ihre Besucher. Reproduzieren Sie auf genau dem Weg, der fehlschlägt, Header inklusive. In diesem Unterschied versteckt sich diese Klasse von Fehlern.

Kämpfen Sie mit einem Fehler, der nichts protokolliert?

Auch Stille ist ein Symptom. Wir reproduzieren den Fehler, lesen die Primärquellen und beheben beide Enden.

Mit einem Ingenieur sprechen

Sie haben das Ende erreicht.

Setzen Sie das Gelesene um

Was betreiben Sie?

Erzählen Sie uns von Workload, Traffic und Anforderungen an die Wiederherstellung. Beginnen Sie mit dem Server-Konfigurator oder besprechen Sie die Details mit einem Ingenieur.

Geschrieben von den Ingenieuren, die die beschriebene Infrastruktur bauen und betreiben.
Mit einem Ingenieur sprechen
XIn

Noch 5 Min.