So beheben Sie den Fehler 'ERR_TOO_MANY_REDIRECTS'

ERR_TOO_MANY_REDIRECTS bedeutet, dass der Browser einer Weiterleitungskette gefolgt ist, die sich nie auflöst – am häufigsten URL A → URL B → URL A – und nach Erreichen des integrierten Hop-Limits aufgegeben hat.

Wenn Sie auf diesen Fehler gestoßen sind, haben Sie wahrscheinlich eine Proxy- oder SSL-Einstellung geändert und mussten dann beobachten, wie jede Anfrage zwischen zwei URLs hin- und herspringt, anstatt zu laden. Dieser Fehler ist besonders frustrierend, weil die Seite vor einer Stunde noch einwandfrei funktioniert hat und nichts offensichtlich defekt erscheint. Es handelt sich weder um einen Browser-Bug noch um eine vorübergehende Störung; er signalisiert, dass zwei oder mehr Weiterleitungsregeln in Ihrem Stack unterschiedlicher Meinung darüber sind, wohin eine URL führen soll. Dieser Leitfaden verfolgt einen diagnoseorientierten Ansatz: Sie verfolgen die Schleife, bevor Sie die Konfiguration anfassen, und beheben dann die eigentliche Ursache – für die meisten Entwickler ist das ein Protokoll-Mismatch hinter einem Proxy oder CDN, kein WordPress-Plugin.

Was bedeutet ‘ERR_TOO_MANY_REDIRECTS’?

Eine Weiterleitungsschleife entsteht, wenn Ihre Website eine URL ständig mit einer Weiterleitung zu einer anderen URL beantwortet, die schließlich wieder zurückzeigt, sodass der Browser nie eine abschließende 200-Antwort erhält. Browser begrenzen die Anzahl der Hops, denen sie folgen: Chromium und Firefox stoppen beide bei 20, Safari stoppt früher – an diesem Punkt brechen sie die Anfrage ab und zeigen einen Fehler an.

Die Fehlermeldung variiert je nach Browser, alle beschreiben jedoch denselben Zustand:

Die Weiterleitungen selbst sind gewöhnliche 3xx-Antworten, üblicherweise 301 oder 302, jeweils mit einem Location-Header. In einer Schleife wechseln dieselben zwei Location-Werte ab, bis der Browser aufgibt.

Zuerst diagnostizieren: die Weiterleitungskette verfolgen

Bevor Sie eine Konfiguration ändern, verfolgen Sie die Kette über die Kommandozeile. curl -I -L https://yourdomain.com gibt die Antwort-Header für jeden Hop aus, und eine Schleife zeigt sich als Wiederholung derselben zwei URLs in aufeinanderfolgenden Location:-Zeilen. Im curl-Handbuch ruft -I (--head) nur die Header ab, und -L (--location) folgt jedem Location-Header zur nächsten URL.

Ein Origin-Server in einer Schleife erzeugt eine Ausgabe wie diese:

HTTP/2 301
location: https://app.example.com/

HTTP/2 301
location: http://app.example.com/

HTTP/2 301
location: https://app.example.com/
...
curl: (47) Maximum (50) redirects followed

Das abwechselnde http:// ↔ https:// ist hier das typische Merkmal einer Protokoll-Mismatch-Schleife. Wenn Sie auch die Antwort-Bodies benötigen, verwenden Sie curl -sSL -o /dev/null -D - https://yourdomain.com, das alle Header ausgibt und dabei den Body verwirft.

Alternativen ohne Installation: Der Network-Tab in den Browser-DevTools zeigt dieselbe 301/302-Kette mit jedem Location-Header, und die Erweiterung Redirect Path oder ein Online-Redirect-Checker stellt die Kette für eine URL dar. Achten Sie in der jeweiligen Ausgabe auf die URL, die sich wiederholt: Dieses sich wiederholende Paar ist die Schleife.

Die häufigste Entwickler-Ursache: HTTP↔HTTPS-Schleifen durch SSL-Terminierung

Die häufigste Weiterleitungsschleife, auf die Entwickler stoßen, liegt nicht an einem Plugin. Es handelt sich um einen Protokoll-Mismatch: Ein Proxy oder CDN terminiert TLS und leitet einfaches HTTP an Ihren Origin-Server weiter, Ihre Anwendung sieht http, leitet zu https weiter, und der Zyklus wiederholt sich endlos. Der Browser kommuniziert per HTTPS mit dem Edge; der Edge kommuniziert per HTTP mit Ihrer Anwendung; Ihre Anwendung leitet „hilfreicherweise” zurück zu HTTPS weiter.

Bei Cloudflare garantiert das Setzen von SSL/TLS auf Flexible bei gleichzeitiger HTTPS-Erzwingung am Origin-Server eine Schleife, weil Flexible immer HTTP an den Origin-Server sendet. Auslöser ist häufig der separate Schalter „Always Use HTTPS”, der zusätzlich zu Flexible aktiviert wird. Die Lösung: Installieren Sie ein Zertifikat am Origin-Server und wechseln Sie dann den Modus zu Full (strict). Die aktuellen Modi sind Off, Flexible, Full, Full (strict) und Strict – nicht die „drei Modi”, die ältere Anleitungen beschreiben.

Hinter einem eigenen Proxy oder Load Balancer sollte die Anwendung dem weitergeleiteten Protokoll-Header vertrauen, anstatt erneut weiterzuleiten. Der Proxy sollte X-Forwarded-Proto mit dem ursprünglichen Schema des Browsers senden, und die Anwendung sollte diesen Header lesen, nicht den Klartext-Hop. In Express aktivieren Sie trust proxy, damit req.protocol und req.secure den weitergeleiteten Wert widerspiegeln:

// Trust the first proxy hop, then req.secure reflects X-Forwarded-Proto
app.set('trust proxy', 1);

app.use((req, res, next) => {
  if (!req.secure) {
    return res.redirect(301, `https://${req.headers.host}${req.originalUrl}`);
  }
  next();
});

Ohne trust proxy bleibt req.secure hinter einem TLS-terminierenden Proxy false, und genau diese Middleware erzeugt eine Schleife. In Nginx, das die Origin-Weiterleitung übernimmt, prüfen Sie das weitergeleitete Schema, damit die Regel nicht für Traffic ausgelöst wird, der bereits als HTTPS angekommen ist:

# Only redirect when the edge saw plain HTTP
if ($http_x_forwarded_proto = "http") {
  return 301 https://$host$request_uri;
}

Eine Produktionsschleife, die nur für eingeloggte Benutzer oder nur hinter dem CDN auftritt, ist für einen anonymen curl-Aufruf unsichtbar. Eine Session-Replay-Aufzeichnung der betroffenen Sitzung zeigt, welche zwei URLs unter den echten Cookies und dem Edge-Kontext des Benutzers hin- und hersprangen – und reproduziert damit die Bedingung, die Server-Logs zwar beschreiben, aber nicht sichtbar machen.

Cookie- und Auth-Guard-Schleifen

Veraltete Cookies und fehlgeleitete Authentifizierung sind die zweithäufigste Kategorie. Ein Cookie mit altem Weiterleitungsstatus oder eine vom Browser gecachte HSTS-Policy kann einen einzelnen Client in eine Schleife zwingen, während alle anderen die Seite problemlos laden – das ist das Symptom „schlägt im normalen Fenster fehl, funktioniert im Inkognito-Modus”. Löschen Sie zuerst Cookies und Site-Daten für die betroffene Domain.

Die programmatische Variante ist ein Auth-Guard, der auf seiner eigenen Login-Seite eine Schleife bildet. Wenn /login selbst hinter der Regel „Nicht authentifizierte Benutzer zu /login weiterleiten” liegt, springt jeder Aufruf zurück zu /login. Schließen Sie die Login-Route vom Guard aus. Dasselbe passiert, wenn ein Login-Handler zu einer geschützten Seite weiterleitet, deren Guard den Benutzer sofort zurückschickt, weil das Session-Cookie nie gesetzt wurde – ein häufiger Nebeneffekt des oben beschriebenen req.secure-Mismatches, bei dem ein Secure-Cookie über den HTTP-Hop des Proxys abgelehnt wird.

Fehler in Weiterleitungsregeln: zwei Schichten im Widerspruch

Eine Weiterleitungsschleife entsteht fast immer dadurch, dass zwei Schichten unterschiedlicher Meinung über die kanonische URL sind (Framework, Webserver und CDN erzwingen jeweils eine andere Regel). Die dauerhafte Lösung besteht darin, HTTP→HTTPS- und www/non-www-Weiterleitungen in genau einer Schicht zu verwalten. Klassische Fälle: Eine Schicht erzwingt www, eine andere entfernt es; eine Regel, deren Ziel noch immer ihrer eigenen Bedingung entspricht; oder dieselbe Weiterleitung ist über Framework, Host und CDN dupliziert.

Frameworks sind eine vollwertige Weiterleitungsschicht, kein Nachgedanke:

• Next.js definiert Weiterleitungen mit async redirects() in next.config.js, wobei permanent: true einen 308 und false einen 307 ausgibt. Beachten Sie, dass ab Next.js 16 die alte middleware-Dateikonvention in Proxy (proxy.ts) umbenannt wurde; eine verbliebene middleware.ts funktioniert weiterhin für Edge-Runtime-Anwendungsfälle, ist jedoch veraltet und wird in einer zukünftigen Version entfernt, sodass Weiterleitungs- oder Auth-Logik darin zu proxy.ts migriert werden sollte.
• Nginx verwendet eine return 301-Direktive: Sichern Sie diese, wie oben gezeigt, damit sie nicht hinter einem Proxy erneut ausgelöst wird.
• Express verwendet Middleware; halten Sie genau eine HTTPS-Weiterleitungs-Middleware in der Kette.
• WordPress ist ein Beispiel desselben Musters: Ein Mismatch zwischen den Einstellungen WordPress-Adresse und Website-Adresse bedeutet lediglich, dass zwei Schichten im Widerspruch stehen – gelöst wird es, indem beide übereinstimmen.

Auf der Serverseite kann Apache auch einen eigenen Fehler „request exceeded the limit of 10 internal redirects” auslösen, dessen internes Rewrite-Limit von 10 vom 20-Hop-Limit des Browsers getrennt ist – ein nützlicher Hinweis, dass die Schleife in .htaccess liegt, nicht beim Client. Bei Cloudflare platzieren Sie die HTTP→HTTPS-Weiterleitung in einer Redirect Rule in der modernen Rules-Engine; Page Rules werden zugunsten der modernen Rules-Engine schrittweise abgeschafft.

Wie vermeidet man Weiterleitungsschleifen?

Die meisten Schleifen entstehen durch eine Konfigurationsänderung, daher sollten Weiterleitungsänderungen bewusst vorgenommen werden. Halten Sie diese Checkliste bereit:

1. Eine Schicht verwaltet jede Weiterleitung. Entscheiden Sie, ob HTTPS- und www/non-www-Kanonisierung im CDN, im Webserver oder in der Anwendung erfolgt, und entfernen Sie die Duplikate aus den anderen beiden.
2. Dem Proxy vertrauen, nicht erneut weiterleiten. Hinter jedem TLS-terminierenden Hop lesen Sie X-Forwarded-Proto, anstatt HTTPS blindlings zu erzwingen.
3. Die Kette nach jeder Änderung erneut verfolgen. Führen Sie curl -I -L gegen die betroffene URL nach jeder HTTPS-, Domain- oder URL-Strukturänderung aus und bestätigen Sie, dass sie mit einem einzelnen 200 endet.

Der schnellste Weg aus einer Weiterleitungsschleife ist immer die Analyse, nicht das Raten. Führen Sie curl -I -L gegen die fehlerhafte URL aus, finden Sie die zwei URLs, die in den Location-Headern hin- und herspringen, und beheben Sie dann die eine Schicht, die gegen den Strom weiterleitet – meistens ein Proxy, der HTTP an einen Origin-Server übergibt, der auf HTTPS besteht.

Häufig gestellte Fragen

Warum verschwindet die Weiterleitungsschleife im Inkognito-Modus, nicht aber in meinem normalen Browser-Fenster?

Der Inkognito-Modus startet ohne gespeicherte Cookies oder gecachte HSTS-Policy. Wenn eine Schleife beim normalen Surfen auftritt, im privaten Fenster jedoch verschwindet, deutet das auf einen clientseitigen Zustand hin, nicht auf eine Serverregel. Ein veraltetes Cookie mit altem Weiterleitungsstatus oder eine gecachte HSTS-Policy, die HTTPS auf einem falsch konfigurierten Origin-Server erzwingt, erzeugt nur für das betroffene Profil eine Schleife, während andere Benutzer die Seite problemlos laden. Löschen Sie Cookies und Site-Daten für die Domain, und wenn HSTS verdächtig ist, überprüfen Sie chrome://net-internals/#hsts.

Was ist der Unterschied zwischen Cloudflare Flexible und Full (strict) SSL in Bezug auf Weiterleitungsschleifen?

Flexible sendet immer einfaches HTTP von Cloudflare an Ihren Origin-Server. Wenn der Origin-Server HTTP zu HTTPS weiterleitet, wiederholt sich die Anfrage endlos. Full (strict) sendet HTTPS an den Origin-Server und validiert dort ein vertrauenswürdiges Zertifikat – das entspricht den Erwartungen des Origin-Servers und unterbricht die Schleife. Installieren Sie zuerst ein gültiges Zertifikat am Origin-Server und wechseln Sie dann den SSL/TLS-Modus von Flexible zu Full (strict). Der separate Schalter 'Always Use HTTPS' in Kombination mit Flexible ist ein häufiger Auslöser.

Warum zeigen curl und der Browser unterschiedliches Weiterleitungsverhalten für dieselbe URL?

curl läuft als anonymer Client ohne Cookies, ohne gecachte HSTS-Policy und ohne Login-Sitzung. Daher reproduziert es nur Schleifen, die durch Server- oder CDN-Regeln verursacht werden, die auf jede Anfrage zutreffen. Schleifen, die von einem bestimmten Cookie, einer authentifizierten Sitzung oder einem bestimmten CDN-Edge abhängen, erscheinen nicht in einer anonymen curl-Analyse. Erfassen Sie in diesen Fällen den echten Benutzerkontext: Browser-DevTools in der betroffenen Sitzung oder eine Session-Replay-Aufzeichnung, die zeigt, welche zwei URLs unter den Cookies und dem Auth-Status dieses Benutzers hin- und hersprangen.

Gilt eine Next.js 16-Weiterleitung in next.config.js auch für clientseitige Navigation mit Link oder router.push?

Bei Verwendung des Pages Routers werden Weiterleitungen, die in der redirects()-Funktion von next.config.js definiert sind, nicht auf clientseitiges Routing über Link oder router.push angewendet, es sei denn, eine Proxy-Datei – früher Middleware – ist vorhanden und stimmt mit dem Pfad überein. next.config.js-Weiterleitungen werden auf dem Server für vollständige Seitenladevorgänge und initiale Anfragen ausgeführt, sodass clientseitige Übergänge sie umgehen können. In Next.js 16 wurde die Middleware-Dateikonvention in Proxy (proxy.ts) umbenannt; eine verbliebene middleware.ts sollte migriert werden, da Weiterleitungs- und Auth-Logik dort möglicherweise nicht mehr ausgeführt wird.