ERR_TOO_MANY_REDIRECTS: Ursache der Weiterleitungsschleife und Lösung

2026-09-19

ERR_TOO_MANY_REDIRECTS bedeutet, der Browser ist einer Kette von Weiterleitungen gefolgt, die nie eine finale Seite erreicht hat, und hat aufgegeben. Chrome und die meisten anderen Browser stoppen nach rund 20 Sprüngen, und die häufigste Ursache ist eine HTTP-zu-HTTPS-Schleife, erzeugt von einem Proxy oder CDN, der sich mit dem Ursprungsserver nicht darüber einig ist, welches Protokoll gerade verwendet wird.

Was ERR_TOO_MANY_REDIRECTS bedeutet

Eine Weiterleitung sagt dem Browser "die Seite, die Sie wollen, ist woanders, gehen Sie stattdessen dorthin". Eine einzelne Weiterleitung, oder sogar zwei oder drei nacheinander, ist normal: eine nackte Domain, die auf www weiterleitet, oder eine alte URL, die auf ihren Ersatz weiterleitet. Eine Schleife entsteht, wenn eine URL zu einer zweiten URL weiterleitet, die zur ersten zurück oder zu sich selbst weiterleitet. Da der Browser nie eine Seite erreicht, die tatsächlich Inhalt zurückgibt, bricht er die Kette ab und zeigt den Fehler, statt für immer hängen zu bleiben.

Wie sich der Fehler zeigt

Chrome und Edge zeigen "This page isn't working - redirected you too many times" mit dem Fehlercode ERR_TOO_MANY_REDIRECTS. Firefox zeigt "The page isn't redirecting properly." Safari sagt "Safari can't open the page because too many redirects occurred."

curl mit dem Flag -L folgt Weiterleitungen genauso wie ein Browser, und jeden Sprung auszudrucken zeigt genau, wo sich die Schleife wiederholt:

curl -sIL https://example.com/ | grep -E "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
location: http://example.com/
HTTP/1.1 301 Moved Permanently
location: https://example.com/
HTTP/1.1 301 Moved Permanently
location: http://example.com/

Dieses Muster, http zu https und zurück zu http, ist die mit Abstand häufigste Form, die dieser Fehler annimmt. curl stoppt bei seinem eigenen Standardlimit (50 Weiterleitungen), statt ihm für immer zu folgen, und die sich wiederholenden location-Zeilen machen die Schleife offensichtlich, ohne dass überhaupt ein Browser geöffnet werden muss.

Was eine Weiterleitungsschleife verursacht

Eine HTTP-zu-HTTPS-Fehlpassung zwischen einem Proxy oder CDN und dem Ursprung. Das ist der klassische Fall. Steht Cloudflares SSL/TLS-Modus auf Flexible, terminiert Cloudflare TLS am Edge und verbindet sich mit dem Ursprung über einfaches HTTP. Hat der Ursprungsserver zusätzlich eine Regel, die jede HTTP-Anfrage auf HTTPS weiterleitet (ein üblicher Sicherheitsstandard), schickt der Ursprung den Browser zurück zu HTTPS, Cloudflare stuft beim nächsten Sprung wieder auf HTTP herab, und die beiden Einstellungen bekämpfen sich für immer.
www- und Nicht-www-Regeln, die aufeinander zeigen. Eine Regel leitet die nackte Domain auf www weiter, und eine separate Regel, oft später von einem anderen Admin oder Plugin hinzugefügt, leitet www zurück zur nackten Domain weiter.
Eine WordPress-siteurl- oder home-Fehlpassung. Stimmt die in der Datenbank konfigurierte URL der Website nicht mit der URL überein, die Besucher tatsächlich nutzen (eine übrig gebliebene Staging-URL, eine Schema-Fehlpassung nach dem Hinzufügen von SSL), leitet WordPress immer weiter in Richtung des konfigurierten Werts.
Cookies, die der Server erwartet, aber nie erhält, oder eine Login-Weiterleitung, die still scheitert. Eine Seite, die nicht authentifizierte Besucher zu einem Login-Schritt weiterleitet, der dann zur selben Seite zurückleitet, weil das Session-Cookie nie gesetzt wurde (oft von den Regeln für Drittanbieter-Cookies eines Browsers blockiert oder wegen eines fehlenden Secure/SameSite-Attributs), schleift endlos.
Widersprüchliche Regeln für Schrägstrich am Ende oder Sprachpräfix. Eine Regel fügt einen Schrägstrich am Ende hinzu, eine andere entfernt ihn; eine Regel fügt basierend auf der Browser-Locale ein Sprachpräfix hinzu, eine andere entfernt es für kanonische URLs, und die beiden heben sich gegenseitig auf.
Eine Caching-Schicht liefert eine veraltete Weiterleitung. Ein CDN oder Reverse-Proxy hat einen alten 301 zwischengespeichert, der auf eine URL zeigte, die inzwischen geändert wurde und zur ursprünglichen zurückleitet.

So finden Sie heraus, wer schuld ist

Passiert die Schleife bei jedem Besucher in jedem Netzwerk, ist es ein Server- oder CDN-Konfigurationsproblem, nichts Lokales. Passiert es nur bei Ihnen, löschen Sie zuerst die Cookies für die Website, da ein schlechtes oder abgelaufenes Session-Cookie einen großen Teil der Einzelbesucher-Schleifen verursacht. Eine HTTP-Prüfung von mehreren Standorten klärt das in einer Anfrage: Zeigt sich dieselbe Weiterleitungskette (oder derselbe Fehlschlag) von jedem Standort, liegt die Lösung auf der Serverseite.

So beheben Sie ERR_TOO_MANY_REDIRECTS

Wenn Sie Besucher sind

Löschen Sie die Cookies für die Website. Klicken Sie in Chrome auf das Schloss- oder Einstellungssymbol neben der Adressleiste, öffnen Sie die Website-Einstellungen, und löschen Sie Cookies und Website-Daten nur für diese Domain.
Probieren Sie ein Inkognito- oder privates Fenster. Das schließt eine Browser-Erweiterung oder ein gespeichertes Cookie als Ursache aus, ohne Ihr reguläres Profil anzufassen.
Probieren Sie ein anderes Netzwerk, etwa mobile Daten statt WLAN. Manche Firmen- oder Internetanbieter-Proxys schreiben Anfragen auf eine Weise um, die eine Schleife nur in diesem Netzwerk erzeugt.
Leeren Sie den Browser-Cache, falls eine Weiterleitungsantwort selbst von vor der Behebung der Website zwischengespeichert wurde.

Wenn Sie die Website betreiben

Prüfen Sie den SSL-Modus Ihres CDN gegen die Weiterleitungsregel Ihres Ursprungs. Öffnen Sie in Cloudflare SSL/TLS und setzen Sie den Modus auf Full oder Full (strict), nicht Flexible, wann immer der Ursprung HTTP auf HTTPS weiterleitet. Full erlaubt dem Ursprung weiterhin ein selbstsigniertes Zertifikat; Full (strict) verlangt ein gültiges.
Vertrauen Sie dem weitergeleiteten Protokoll-Header, statt blind weiterzuleiten. Sitzt ein Proxy vor Ihrer App, muss der Ursprung anhand von X-Forwarded-Proto weiterleiten, nicht anhand der rohen Verbindung, die hinter dem Proxy immer wie HTTP aussieht. Bei nginx:
```
if ($http_x_forwarded_proto = "http") {
    return 301 https://$host$request_uri;
}
```
und stellen Sie sicher, dass das CDN oder der Load Balancer diesen Header tatsächlich bei jeder Anfrage setzt.
Prüfen Sie Ihre Weiterleitungsregeln der Reihe nach, einschließlich .htaccess, nginx-server-Blöcken, Middleware auf Anwendungsebene, und jeder CDN-Page-Rule, auf zwei Regeln, die aufeinander zeigen. Ein häufiges Apache-Muster, das hinter einem Proxy schleift:
```
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
```
scheitert auf dieselbe Weise wie der nginx-Fall oben, da %{HTTPS} die Verbindung liest, die der Proxy herstellt, nicht die, die der Besucher hergestellt hat; prüfen Sie stattdessen %{HTTP:X-Forwarded-Proto}.
Beheben Sie die WordPress-Site-URL, falls das zutrifft: Bestätigen Sie unter wp-admin > Settings > General, dass sowohl die WordPress Address als auch die Site Address der URL entsprechen, die Besucher tatsächlich nutzen, Protokoll eingeschlossen. Ist das Admin-Panel selbst wegen der Schleife unerreichbar, setzen Sie WP_HOME und WP_SITEURL direkt in wp-config.php.
Wählen Sie eine kanonische Form und leiten Sie alles andere einmal dorthin um, nicht in einer Kette: www oder nicht-www, Schrägstrich am Ende oder nicht, eine Regel pro Entscheidung statt mehrerer, von verschiedenen Tools über die Zeit übereinandergeschichteter Regeln.
Leeren Sie den CDN-Cache, nachdem Sie die Regel behoben haben, da ein zwischengespeicherter 301 oder 302 die alte Antwort weiter sendet, bis er abläuft oder geleert wird.

So beugen Sie ERR_TOO_MANY_REDIRECTS vor

Eine Weiterleitungsschleife wird fast immer durch eine Konfigurationsänderung eingeführt: ein neues CDN, ein neues SSL-Zertifikat, ein Plugin-Update, oder eine Migration, die die Website-URL berührt hat. Eine HTTP-Prüfung, die den Antwortcode beobachtet und Weiterleitungen planmäßig verfolgt, erkennt eine Schleife in dem Moment, in dem sie erscheint, von über 300 Prüfpunkten in 158 Städten, statt auf ein Support-Ticket zu warten. HostTracker überwacht Websites seit 2004 und kann per E-Mail, SMS, Sprachanruf, Slack, Telegram und mehr alarmieren, sobald eine Prüfung zu scheitern beginnt.

Häufig gestellte Fragen

Wie viele Weiterleitungen erlaubt ein Browser, bevor er aufgibt?

Chrome und Chromium-basierte Browser stoppen bei rund 20. Curls Standardlimit mit -L ist 50. Die genaue Zahl variiert je nach Client, aber jeder von ihnen stoppt irgendwann, statt einer Schleife für immer zu folgen.

Warum passiert die Schleife erst, nachdem ich zu Cloudflare (oder einem anderen CDN) gewechselt bin?

Fast immer der SSL/TLS-Modus. Der Flexible-Modus spricht mit dem Ursprung einfaches HTTP; besteht der Ursprung auf HTTPS, leiten sich die beiden Seiten gegenseitig endlos weiter. Der Wechsel zu Full oder Full (strict) behebt das meist sofort.

Kann eine Browser-Erweiterung das verursachen?

Ja, besonders Erweiterungen, die HTTPS erzwingen, Anfragen umschreiben, oder Cookies verwalten. Das Testen in einem Inkognito-Fenster mit deaktivierten Erweiterungen schließt das schnell aus.

Beeinflusst das die SEO?

Ja. Suchmaschinen-Crawler geben bei einer Weiterleitungsschleife genauso auf wie ein Browser, und eine schleifende URL wird nicht indexiert oder fällt aus dem Index, falls sie früher funktioniert hat.

Ich sehe den Fehler nur auf einer bestimmten Seite, nicht auf der ganzen Website. Was ist daran anders?

Prüfen Sie auf eine seitenspezifische Regel: eine Seite, die einen Login verlangt, eine zwischengespeicherte alte Weiterleitung für genau diese eine URL, oder eine Schrägstrich-Fehlpassung, die nur auf dieser Route existiert. Vergleichen Sie die genaue Weiterleitungskette für diese URL mit einer funktionierenden Seite mit curl -sIL.

Ist eine einzelne Weiterleitung (wie nicht-www zu www) etwas, das man beheben sollte?

Nein, eine einzelne Weiterleitung für sich ist normal und erwartet. Nur eine sich wiederholende Kette, die nie eine finale 200-Antwort erreicht, ist das Problem, das dieser Fehler beschreibt.