ERR_TOO_MANY_REDIRECTS

Was dieser Fehler bedeutet und wie du ihn erkennst

• Der Browser zeigt „Diese Seite funktioniert nicht – [domain] hat Sie zu oft weitergeleitet“ oder den Fehlercode ERR_TOO_MANY_REDIRECTS an.
• Die Adressleiste wechselt wiederholt zwischen HTTP und HTTPS oder zwischen www- und non-www-Hostnamen, bevor der Browser das Laden beendet.
• Die gesamte Website kann ausfallen, oder das Problem ist auf eine URL, den Administrationsbereich, eingeloggte Sitzungen oder bestimmte Geräte beschränkt.
• Das Problem beginnt häufig nach der Aktivierung von HTTPS, dem Hinzufügen eines CDNs oder Reverse-Proxys, der Änderung des kanonischen Hostnamens oder der Installation eines Weiterleitungs- oder SSL-Plugins.
• Das Löschen von Cookies kann das Verhalten vorübergehend ändern, wenn Authentifizierungs- oder Sitzungslogik beteiligt ist. Einen serverseitigen Weiterleitungskonflikt behebt es jedoch nicht.

Hauptursachen nach Wahrscheinlichkeit

1. Widersprüchliche HTTP/HTTPS-Regeln — Eine Ebene leitet HTTP zu HTTPS weiter, während eine andere HTTPS fälschlicherweise zurück zu HTTP leitet. Das geschieht häufig, wenn ein Proxy oder CDN TLS beendet, der Origin aber nicht erkennt, dass die ursprüngliche Anfrage sicher war.
2. Nicht passender CDN-SSL/TLS-Modus — Ein CDN kann HTTP verwenden, um eine Verbindung zu einem Origin herzustellen, der HTTPS erzwingt. Der Origin leitet zu HTTPS weiter, das CDN wiederholt jedoch die HTTP-Anfrage zum Origin, wodurch eine Schleife entsteht.
3. Konkurrierende kanonische www- und non-www-Regeln — CDN, Webserver, CMS oder ein Plugin können sich darüber widersprechen, welcher Hostname kanonisch ist.
4. Fehlerhafte Verarbeitung von Proxy- oder weitergeleiteten Protokollen — Die Anwendung vertraut dem konfigurierten Proxy möglicherweise nicht oder verarbeitet X-Forwarded-Proto beziehungsweise einen gleichwertigen Header nicht korrekt. Dadurch behandelt sie eine sichere Anfrage wiederholt als HTTP.
5. Veraltete Weiterleitungen im Cache — Ein Browser, CDN, Reverse-Proxy oder Seiten-Cache kann weiterhin eine Weiterleitung ausliefern, die vor der Korrektur der Konfiguration gespeichert wurde.
6. Doppelte Regeln in Anwendung oder Plugins — Plugins für SSL-Erzwingung, Login, Wartungsmodus oder Weiterleitungen können mit Regeln auf Serverebene kollidieren.
7. Fehlerhafte Cookie- oder Sitzungskonfiguration — Falsche Einstellungen für Secure, Domain oder Pfad können bei einigen Nutzern Authentifizierungsweiterleitungen auslösen, insbesondere bei eingeloggten Besuchern.

So behebst du den Fehler

1. Erfassen Sie zuerst die Weiterleitungskette

Verwenden Sie eine schreibgeschützte Anfrage im Terminal und ersetzen Sie den Platzhalter durch den betroffenen Hostnamen:

curl -IL https://[your-hostname]

Damit werden Header angefordert und Weiterleitungen verfolgt. Notieren Sie jeden Location:-Wert und jeden HTTP-Statuscode. Testen Sie die exakt fehlerhafte URL, die HTTP-Version sowie, sofern relevant, die www- und non-www-Varianten. Der Netzwerkbereich des Browsers liefert ähnliche Informationen.

Achten Sie auf Muster wie:

• HTTPS → HTTP → HTTPS
• non-www → www → non-www
• Eine URL leitet wiederholt auf sich selbst weiter
• Eine Weiterleitung zu einer Login- oder kanonischen URL, die unmittelbar zurückleitet

Beginnen Sie nicht damit, Caches zu leeren oder mehrere Einstellungen gleichzeitig zu ändern. Die Kette hilft dabei, die betroffene Ebene zu identifizieren.

2. Beheben Sie eine HTTP/HTTPS- oder CDN-Schleife

Wenn ein CDN oder Reverse-Proxy die öffentliche HTTPS-Verbindung verarbeitet, prüfen Sie dessen SSL/TLS-Modus sowie das Zertifikat und die HTTPS-Konfiguration des Origins. Der Verbindungsmodus vom CDN zum Origin muss zu dem passen, was der Origin unterstützt. Bei Cloudflare ist für einen Origin, der HTTPS korrekt unterstützt, in der Regel Full oder Full (strict) erforderlich, nicht Flexible, wenn der Origin selbst HTTPS erzwingt.

Vergewissern Sie sich vor der Änderung des Modus, dass Sie zur Änderung des CDNs berechtigt sind und dass der Origin über ein gültiges Zertifikat für den Hostnamen verfügt, wenn eine strikte Zertifikatsvalidierung verwendet wird. Änderungen an CDN-TLS-Einstellungen können den Live-Datenverkehr beeinflussen. Befolgen Sie daher den freigegebenen Änderungsprozess oder die Anforderungen für ein Wartungsfenster.

3. Korrigieren Sie die HTTPS-Erkennung hinter einem Proxy

Wenn die Anwendung HTTPS erzwingt, während sie hinter einem Proxy läuft, konfigurieren Sie die Anwendung oder das Framework so, dass es dem vorgesehenen Proxy vertraut und das weitergeleitete Protokoll erkennt. Je nach Plattform können diese Einstellungen trust proxy, Trusted Proxies oder Force-SSL-Einstellungen heißen.

Vertrauen Sie Headern für weitergeleitete Protokolle nur über einen bekannten, kontrollierten Proxy-Pfad. Vertrauen Sie auf einem direkt erreichbaren Origin nicht blind von Clients gelieferten Headern. Prüfen Sie die Dokumentation der Plattform auf die korrekte Einstellung und testen Sie anschließend die Weiterleitungskette erneut.

4. Beheben Sie Widersprüche zwischen www und non-www

Wählen Sie einen kanonischen Hostnamen und dokumentieren Sie ihn. Prüfen Sie das CDN, die Webserver-Konfiguration, gegebenenfalls .htaccess-Regeln, die URL-Einstellungen des CMS und Weiterleitungs-Plugins.

Verwenden Sie genau eine maßgebliche Hostname-Weiterleitung – beispielsweise von non-www zu www oder von www zu non-www – und entfernen Sie doppelte oder gegensätzliche Regeln. Prüfen Sie nach der Änderung alle HTTP- und HTTPS-Varianten. Eine Einstellung für die kanonische URL, die vom Ziel des Webservers abweicht, kann die Schleife erneut erzeugen, selbst wenn HTTPS korrekt konfiguriert ist.

5. Prüfen Sie das Verhalten von Anwendung, Login und Cookies

Wenn anonyme Nutzer die Seite laden können, eingeloggte Nutzer jedoch nicht, vergleichen Sie die Weiterleitungskette mit und ohne Sitzungscookie. Verwenden Sie dafür ein autorisiertes Testkonto oder ein privates Fenster. Prüfen Sie Force-SSL-, Login-, Membership- und Weiterleitungs-Plugins sowie die konfigurierte Website-URL der Anwendung.

Stellen Sie sicher, dass Sitzungscookies für den gewählten HTTPS-Hostnamen das korrekte Attribut Secure, die richtige Domain und den richtigen Pfad verwenden. Deaktivieren oder ändern Sie jeweils nur ein verdächtiges Plugin und befolgen Sie dabei den Änderungsprozess. Entfernen Sie auf einer Produktionswebsite keine Authentifizierungs- oder Sicherheitskontrollen ohne Wiederherstellungsplan.

6. Leeren Sie veraltete Weiterleitungen und testen Sie erneut

Leeren Sie nach der Korrektur der Konfiguration relevante Einträge im CDN-, Reverse-Proxy- und Seiten-Cache, sofern Sie dazu berechtigt sind. Browser-Weiterleitungen können ebenfalls bestehen bleiben. Testen Sie daher erneut mit curl, einem privaten Fenster und bei Bedarf über ein anderes Netzwerk oder Gerät.

Ein erfolgreicher Test sollte die vorgesehene Seite erreichen, ohne eine sich wiederholende Location-Sequenz. Prüfen Sie den kanonischen Hostnamen, das Verhalten von HTTP zu HTTPS, den Login-Ablauf und repräsentative interne URLs, statt nur die Startseite zu testen.

Vorbeugung und Überprüfung der Lösung

• Dokumentieren Sie den kanonischen Hostnamen und das gewünschte Verhalten von HTTP zu HTTPS, bevor Sie ein CDN, einen Reverse-Proxy, ein CMS-Plugin oder eine Serverregel hinzufügen.
• Legen Sie Weiterleitungsentscheidungen nach Möglichkeit in genau einer Ebene verbindlich fest und stellen Sie sicher, dass andere Ebenen keine gegensätzliche Regel ausgeben.
• Konfigurieren Sie beim Betrieb einer Website hinter einem Proxy die Verarbeitung von Trusted Proxies und weitergeleiteten Protokollen bewusst. Akzeptieren Sie von Clients gelieferte Weiterleitungs-Header nicht uneingeschränkt.
• Testen Sie nach Änderungen an HTTPS, Hostnamen, CDN, CMS oder Plugins die vollständige Weiterleitungskette mit den exakt von Nutzern aufgerufenen URLs.
• Nehmen Sie anonymer Nutzer, eingeloggte Nutzer sowie www, non-www, HTTP und HTTPS in die Bereitstellungsprüfungen auf, sofern diese Pfade unterstützt werden.
• Leeren oder versionieren Sie relevante Caches nach Änderungen an Weiterleitungen und prüfen Sie anschließend in einem privaten Fenster oder mit einem sauberen Client.

Häufig gestellte Fragen