err_too_many_redirects verstehen und beheben: Ursachen, Diagnose, Lösungen

Der Browser bricht das Laden ab und meldet „ERR_TOO_MANY_REDIRECTS“ – eine klassische Redirect-Schleife. Das heißt: Die angeforderte URL verweist über mehrere Sprünge auf eine andere URL, die wiederum zurück- oder weiterleitet, bis der Browser sein Sicherheitslimit erreicht (typisch 5–20 Weiterleitungen) und aussteigt. Gute Nachricht: Mit systematischer Diagnose kannst du die Ursache meist schnell finden und sauber beheben.

Was steckt technisch hinter ERR_TOO_MANY_REDIRECTS?

Eine Weiterleitung (HTTP 301/302/307/308) teilt dem Browser mit, dass die eigentliche Ressource unter einer anderen Adresse liegt. Gerät der Browser dabei in einen Zirkel (A → B → A → …) oder in eine zu lange Kette (A → B → C → …), bricht er ab. Gründe sind fast immer widersprüchliche Redirect-Regeln, falsche HTTPS-/SSL-Einstellungen, doppelte Erzwingung von www/https in mehreren Schichten (Server, CMS, CDN) oder fehlerhafte Cookies/Sessions.

So zeigt sich der Fehler in verschiedenen Browsern
Browser Typische Meldung
Chrome ERR_TOO_MANY_REDIRECTS – „Diese Seite funktioniert nicht. domain.tld hat Sie zu oft weitergeleitet.“
Firefox „Diese Seite leitet nicht richtig weiter. Firefox hat erkannt, dass der Server die Anfrage so umleitet, dass sie nie beendet werden kann.“
Safari / Edge Ähnliche Meldungen mit Hinweis auf zu viele Weiterleitungen/Probleme beim Laden.

Merksatz: Weiterleitungen müssen eine klare Richtung haben – nur eine „Quelle der Wahrheit“ für HTTPS und Domain-Normalisierung (www vs. non-www). Doppelte oder widersprüchliche Regeln führen fast zwangsläufig zur Schleife.

Typische Muster, die Redirect-Schleifen auslösen

  • HTTP ↔ HTTPS: CDN leitet Besucher-HTTPS auf Ursprungsserver per HTTP, der Server erzwingt wiederum HTTPS – Ergebnis: Endlosschleife.
  • www ↔ non-www: Server leitet von non-www auf www, CMS/Plugin leitet von www zurück auf non-www.
  • Login-Schleifen: Veraltete/beschädigte Cookies oder falsche Cookie-Domain führen zu ständiger Rückleitung auf die Login-Seite.
  • Mehrfachregeln: .htaccess-Regeln und CMS-Plugins erzwingen dieselbe Redirect-Logik mehrfach oder in Gegenrichtung.
  • Migrationsreste: Alte Weiterleitungen (A → B) bleiben aktiv, während neue Regeln (B → C) hinzukommen – ungünstige Ketten oder Schleifen.
  • HSTS-Fehlkonfiguration: Strict-Transport-Security zwingt zu HTTPS, kollidiert aber mit externen Regeln oder fehlendem gültigem Zertifikat.

err_too_many_redirects

Schnellmaßnahmen im Browser (um Client-seitige Ursachen auszuschließen)

  1. Cookies & Cache für die betroffene Domain löschen:
    • Öffne die Browser-Einstellungen → Datenschutz/Sicherheit → Cookies & Website-Daten → nur die betroffene Domain löschen.
    • Besonders wichtig bei Login-Schleifen (Session-/Auth-Cookies oft die Ursache).
  2. Inkognito-Modus oder anderen Browser testen:
    • Funktioniert es dort, sind lokale Daten/Erweiterungen beteiligt.
    • Tritt der Fehler in allen Browsern auf, liegt er sehr wahrscheinlich serverseitig.
  3. Erweiterungen temporär deaktivieren:
    • Vor allem Sicherheits-, Proxy- oder Privacy-Add-ons können Weiterleitungen beeinflussen.

Den Redirect-Pfad präzise analysieren

Um gezielt zu reparieren, musst du wissen, wo die Schleife entsteht. Das geht am schnellsten per Kommandozeile oder mit einem Redirect-Checker.

Mit curl den Redirect-Flow sichtbar machen

# Header anzeigen (-I), Redirects folgen (-L), ausführlich (-v)
curl -I -L https://example.com

# kompakter: alle Sprünge mit Statuscodes protokollieren
curl -s -I -L https://example.com | sed -n 's/^HTTP.*\|^Location.*/&/p'

Achte auf wiederkehrende Muster, z. B.:

HTTP/2 301
Location: https://www.example.com/
HTTP/2 301
Location: https://example.com/
HTTP/2 301
Location: https://www.example.com/
... (Schleife)

Weitere hilfreiche Tools: Redirect Path (Chrome-Extension), Online-Redirect-Checker, DevTools (Netzwerk-Tab → einzelne Request-Kette verfolgen). Prüfe in den Headern besonders Location, Set-Cookie, Strict-Transport-Security, CDN-spezifische Header (z. B. cf-cache-status, server).

Hauptursachen und konkrete Fixes

1) HTTPS/SSL-Fehlkonfiguration (inkl. CDN/Proxy)

Weiterleitungs-Schleifen entstehen häufig beim Wechsel auf HTTPS oder in Kombination mit CDNs.

  • Gültiges Zertifikat prüfen/installieren:
    • Nutze z. B. den SSL-Test von Qualys SSL Labs und behebe Zertifikats-/Chain-Probleme.
  • Cloudflare & Co. richtig konfigurieren:
    • Setze den SSL/TLS-Modus nicht auf „Flexible“, wenn dein Origin HTTPS erzwingt.
    • Empfehlung: „Full (Strict)“ + gültiges Zertifikat am Origin.
  • Nur eine Instanz erzwingt HTTPS:
    • Entscheide: Serverseitig (Apache/Nginx), CDN oder CMS/Plugin – aber niemals mehrere Ebenen gleichzeitig.
  • HSTS mit Bedacht:
    • Wenn HSTS aktiv ist, kann der Browser gar nicht mehr per HTTP zugreifen – bei Fehlkonfigurationen verschärft das Schleifen.
Siehe auch  ERR_HTTP2_PROTOCOL_ERROR verstehen und beheben: Ursachen, Diagnose und Lösungen für Admins und Power-User
CDN (z. B. Cloudflare) – typische SSL-Modi und Effekte
Modus CF → Origin Voraussetzung Risiko für Schleifen
Flexible HTTP Kein Zertifikat am Origin nötig Hoch, wenn der Origin HTTP→HTTPS umleitet
Full HTTPS Irgendein Zertifikat am Origin Niedrig (bei korrekter Origin-Weiterleitung)
Full (Strict) HTTPS Gültiges Zertifikat am Origin Sehr niedrig (empfohlen)

Praxis-Tipp: Wenn du Cloudflare nutzt und „Always Use HTTPS“ aktiviert hast, deaktiviere alle parallelen HTTPS-Erzwingungen in .htaccess, Nginx-Serverblöcken und SSL-Plugins – sonst drohen Doppel-Redirects.

2) Apache: .htaccess prüfen und bereinigen

Konflikte in .htaccess sind ein Klassiker. Vorgehen:

  1. .htaccess sichern/umbenennen (z. B. in .htaccess_backup), Seite testen. Läuft die Seite, liegt der Fehler in den Regeln.
  2. Mit Minimalregeln neu aufsetzen (z. B. Standard-WordPress-Regeln):
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

HTTPS korrekt erzwingen (nur an einer Stelle!) – Beispiel für non-www → https://example.com:

RewriteEngine On

# www -> non-www
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

# HTTP -> HTTPS
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

Achte darauf, dass kein Plugin oder CDN dieselbe Erzwingung parallel vornimmt.

3) Nginx: Serverblöcke sauber definieren

Wenn du Nginx statt Apache nutzt, gehören Redirects in die passenden Server-Blöcke:

# 80 -> 443
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}

# 443 (Ziel!)
server {
  listen 443 ssl http2;
  server_name example.com;

  # SSL-Konfiguration (Zertifikate etc.)
  # ...

  # Root, Index, PHP-FPM usw.
  # ...
}

Wichtig: Kein zusätzlicher Redirect von example.com zurück zu www.example.com in anderen Blöcken – sonst A↔B-Schleife.

4) WordPress-URLs: WP_HOME und WP_SITEURL

Für WordPress sind die beiden Felder unter Einstellungen → Allgemein kritisch: WordPress-Adresse (URL) und Website-Adresse (URL).

  • Sollten identisch sein (inkl. Protokoll und www/non-www).
  • Bei Lockout wegen Redirect-Schleife kannst du die Werte in wp-config.php hart setzen:
define('WP_HOME',    'https://example.com');
define('WP_SITEURL', 'https://example.com');

Alternativ via WP-CLI:

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

Achtung: Wenn Plugins oder Server-Regeln eine andere Variante (z. B. www) erzwingen, entsteht sofort eine Schleife.

5) Plugins und Themes systematisch ausschließen

Häufige Auslöser sind SEO-Plugins, Security-Suites, Redirect- und SSL-Plugins. Vorgehen:

  1. Per FTP/Dateimanager den Ordner wp-content/plugins temporär umbenennen (z. B. plugins_off), um alles zu deaktivieren.
  2. Seite testen. Läuft sie, liegt die Ursache in einem Plugin. Aktiviere die Plugins einzeln wieder, bis der Übeltäter gefunden ist.
  3. Problem-Plugin ersetzen oder sauber konfigurieren (insbesondere HTTPS-/Redirect-Optionen).

6) CDN-/Proxy-/Firewall-Regeln prüfen

Neben dem SSL/TLS-Modus können auch Page Rules, Workers, Rewrite-/Transform-Regeln und Caching-Einstellungen zu Schleifen führen.

  • Page Rules auf redundante Weiterleitungen prüfen.
  • „Always Use HTTPS“ in CF nur aktivieren, wenn du nicht schon serverseitig HTTPS erzwingst.
  • Cache leeren (Purge), nachdem du Redirects geändert hast.

7) Cookies, Sessions und Login-Schleifen

Bei Auth-geschützten Bereichen führen defekte oder falsch gesetzte Cookies oft zu Loops (z. B. wenn die Cookie-Domain auf .www.example.com fixiert ist, die Seite aber auf example.com läuft).

  • Cookies der Domain löschen und neu einloggen.
  • In WordPress ggf. COOKIE_DOMAIN bereinigen (idealerweise nicht setzen; wenn gesetzt, dann leeren):
define('COOKIE_DOMAIN', '');

Wenn du hinter einem Proxy/Load-Balancer terminierst, achte darauf, dass das Backend (z. B. WordPress/PHP) HTTPS korrekt erkennt, sonst erzwingt es unnötige Redirects:

# In wp-config.php (Beispiel)
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
  $_SERVER['HTTPS'] = 'on';
}

8) Migrationen: alte Regeln aufräumen

Bei Domain- oder Strukturwechseln bleiben oft alte Regeln aktiv. Beispiel: A → B (alt), B → C (neu). Ergebnis: lange Ketten oder Loops, wenn C wieder nach A verweist. Lösung: Altlasten entfernen, nur eine eindeutige Zielroute definieren (A → C direkt). Dokumentiere Weiterleitungen und halte sie so kurz wie möglich.

Siehe auch  JavaScript Void(0): Definition, Einsatz, Alternativen und Best Practices

9) HSTS-Fallen vermeiden

Strict-Transport-Security teilt dem Browser mit, eine Domain ausschließlich via HTTPS aufzurufen. Ist HSTS aktiv und dein HTTPS-Setup fehlerhaft, kommst du schnell in eine Sackgasse mit Schleifen.

  • HSTS nur aktivieren, wenn HTTPS stabil läuft (inkl. Subdomains, falls includeSubDomains gesetzt ist).
  • Für Preload-Einträge gilt: Rückweg ist aufwendig (Entfernung aus der Preload-Liste beantragen, Browser-Caches abwarten).

err_too_many_redirects

Diagnose-Checkliste (kurz & pragmatisch)

  1. Inkognito-Test und Cookies löschen → Client-Faktoren ausschließen.
  2. curl -I -L laufen lassen → Redirect-Kette identifizieren.
  3. SSL/TLS prüfen (Zertifikat gültig? CDN-Modus „Full (Strict)“?).
  4. Nur eine Stelle erzwingt HTTPS (Server, CDN oder CMS) → doppelte Regeln deaktivieren.
  5. Domain-Normalisierung (www vs. non-www) an nur einem Ort definieren.
  6. .htaccess/Nginx auf Minimalregeln zurücksetzen, dann gezielt ergänzen.
  7. WordPress-URLs (WP_HOME/SITEURL) und Plugins prüfen.
  8. CDN-Page-Rules/Workers und Cache kontrollieren.
  9. Proxies/Load-Balancer: X-Forwarded-Proto richtig durchreichen/auswerten.

Ursache–Symptom–Lösung: Schnellübersicht

Ursache Typisches Symptom Wie erkennen? Behebung
CDN „Flexible“ + Origin erzwingt HTTPS HTTP↔HTTPS-Pingpong curl zeigt abwechselnd http/https CDN auf „Full (Strict)“ umstellen, Zertifikat am Origin
.htaccess + Plugin erzwingen beide HTTPS Doppelte 301-Kette Header verraten mehrere 301 hintereinander Nur eine Erzwingung beibehalten
www- und non-www-Regeln widersprüchlich www ↔ non-www Schleife curl zeigt abwechselnde Hostnamen Nur eine klare Normalisierung definieren
Falsche WP_HOME/SITEURL Weiterleitung zur „anderen“ Variante Admin nicht erreichbar, curl zeigt Mismatch In wp-config oder DB korrigieren
Login-Cookies defekt Login-Seite lädt immer wieder Nur eingeloggte Pfade betroffen Cookies löschen, Cookie-Domain prüfen
HSTS bei fehlerhaftem HTTPS Nur HTTPS erreichbar, Schleife bei Redirects HSTS-Header vorhanden HTTPS fixen, HSTS erst danach setzen

Profi-Werkzeuge und Log-Analyse

  • Access Logs (Apache/Nginx): Folge einer Anfrage-ID/Client-IP und prüfe 301/302-Ketten.
# Beispiel Nginx-Access-Log (schematisch)
203.0.113.5 - - [27/Feb/2026:10:12:01 +0000] "GET / HTTP/1.1" 301 0 "-" "Mozilla/5.0" "-"
203.0.113.5 - - [27/Feb/2026:10:12:01 +0000] "GET / HTTP/2" 301 0 "-" "Mozilla/5.0" "-"
  • curl mit erweiterten Ausgaben:
    • curl -I -L -s -S https://example.com
    • curl -I -H "Host: example.com" https://SERVER-IP (um DNS/CDN zu umgehen und direkt den Origin zu testen)
  • SSL-Checker (z. B. Qualys) zur Zertifikats- und Chain-Prüfung.

Praxisbeispiele: Von der Schleife zur Lösung

Beispiel 1: Cloudflare „Flexible“ + Server erzwingt HTTPS

Symptom: curl zeigt abwechselnd http:// und https://, Nutzer sehen ERR_TOO_MANY_REDIRECTS.

Fix: Cloudflare auf „Full (Strict)“ umstellen, am Origin ein gültiges Zertifikat installieren. „Always Use HTTPS“ entweder in Cloudflare oder serverseitig – aber nicht beides.

Beispiel 2: WordPress-URL-Mismatch

Symptom: WP_HOME auf https://www.example.com, WP_SITEURL auf https://example.com. Ergebnis: Schleifen zwischen den Varianten.

Fix: Beide Werte identisch setzen (z. B. https://example.com) per wp-config.php oder WP-CLI. Parallel sicherstellen, dass .htaccess/Nginx nicht in die Gegenrichtung normalisiert.

Beispiel 3: .htaccess kollidiert mit SSL-Plugin

Symptom: Zweifache HTTPS-Erzwingung via 301; Kette wird zu lang, bis der Browser abbricht.

Fix: SSL-Erzwingung nur an einer Stelle. Meist serverseitig die robusteste Wahl; dann Plugin-Optionen deaktivieren oder Plugin ersetzen.

SEO- und Performance-Aspekte

  • Redirect-Budget: Browser (und Crawler) folgen nur begrenzt vielen Redirects. Lange Ketten kosten Zeit und Ranking-Signale.
  • Statuscodes korrekt wählen:
    • 301/308 für dauerhaft, 302/307 für temporär.
    • Fehlwahl kann Caches verwirren, Fehlerdiagnosen erschweren.
  • Konsistente Ziel-URL: Eine kanonische Domain/Protokoll-Variante konsequent beibehalten.

Prävention: So verhinderst du Redirect-Schleifen dauerhaft

  • Ein Ort für jede Richtlinie:
    • HTTPS-Erzwingung: Entscheide dich für Server ODER CDN ODER CMS – nicht mehrere.
    • www-Normalisierung: Genau eine klare Regel.
  • Änderungen dokumentieren:
    • Redirect-Regeln versionieren, Changelogs führen (besonders bei Migrationen).
  • Vor dem Livegang testen:
    • Staging-Umgebung nutzen, curl -I -L, verschiedene Browser/Devices prüfen.
  • Monitoring:
    • Regelmäßig mit Crawlern/SEO-Tools Redirects und Ketten checken.
  • HSTS konservativ einführen:
    • Erst wenn HTTPS vollständig stabil ist; klein starten (niedrige max-age), dann steigern.
Siehe auch  Wie sicher sind Passwortmanager im Alltag wirklich?

Fehlerbehebung als Ablaufplan

  1. Client ausschließen (Inkognito, Cookies löschen).
  2. Redirect-Kette mit curl -I -L erfassen.
  3. SSL/TLS prüfen; CDN-Modus auf „Full (Strict)“ setzen; Zertifikat am Origin.
  4. .htaccess/Nginx auf Minimalzustand zurücksetzen; nur eine HTTPS- und eine Domain-Regel aktivieren.
  5. WordPress-URLs harmonisieren; ggf. per wp-config.php temporär fixieren.
  6. Plugins/Theme als Verursacher per Deaktivierungstest einkreisen.
  7. CDN-Page-Rules/Workers/Caches prüfen; Purge ausführen.
  8. Proxies/Load-Balancer (X-Forwarded-Proto) korrekt konfigurieren.
  9. Logs kontrollieren; bei Bedarf Hosting-Support einschalten.

Fazit

ERR_TOO_MANY_REDIRECTS bzw. err_too_many_redirects ist lästig, aber selten mysteriös. In nahezu allen Fällen steckt eine widersprüchliche oder doppelte Weiterleitungslogik dahinter – häufig bei HTTPS-Erzwingung, www-Normalisierung oder durch eine ungünstige Kombination aus Server-, CMS- und CDN-Regeln. Mit einem klaren Diagnosepfad (Client ausschließen, Redirect-Kette analysieren, SSL/CDN prüfen, Serverregeln konsolidieren, CMS/Plugins justieren) lässt sich die Ursache schnell isolieren und nachhaltig beheben. Entscheidend für Stabilität ist eine saubere Architektur: Eine Quelle der Wahrheit für jede Weiterleitungsentscheidung, gründliches Testen vor Live-Änderungen und regelmäßige Überwachung deiner Redirects.

FAQ

Was bedeutet err_too_many_redirects genau?

Der Browser hat beim Laden einer Seite zu viele Weiterleitungen registriert und abgebrochen. Das ist ein Schutz gegen Endlosschleifen – meist ausgelöst durch widersprüchliche Redirect-Regeln oder HTTPS-/Domain-Mismatches.

Wie finde ich die Ursache am schnellsten?

Starte mit curl -I -L https://deinedomain.tld und beobachte die Location-Header. Erkennst du ein Muster (A ↔ B, http ↔ https, www ↔ non-www), kannst du gezielt in Server-, CMS- oder CDN-Einstellungen ansetzen.

Kann das an Cookies liegen?

Ja, vor allem bei Login-Schleifen. Lösche die Cookies der Domain und teste erneut. Prüfe zusätzlich, ob die Cookie-Domain korrekt gesetzt ist (keine unnötigen www-Fixierungen).

Welche Rolle spielen 301/302/307/308?

Das sind Redirect-Statuscodes. 301/308 sind dauerhaft, 302/307 temporär. Schleifen entstehen unabhängig vom Code, aber dauerhaft gecachte 301/308 erschweren die Fehlersuche. Nutze im Zweifel temporär 302/307 für Tests.

Was ist das Problem mit Cloudflare „Flexible“?

„Flexible“ spricht deinen Origin per HTTP an. Wenn der Origin HTTP→HTTPS umleitet, entsteht eine Schleife. Besser: „Full (Strict)“ und ein gültiges Zertifikat am Origin.

Wie behebe ich widersprüchliche www-Regeln?

Lege eine klare Strategie fest (mit oder ohne www) und setze eine Regel auf einer Ebene (Server oder CDN). Entferne/Deaktiviere alle gegenläufigen Regeln in CMS/Plugins.

Ich komme nicht ins WordPress-Backend – was tun?

Setze vorübergehend in wp-config.php:

define('WP_HOME','https://example.com');
define('WP_SITEURL','https://example.com');

Passe die Domain an. Dadurch übersteuerst du falsche DB-Werte und bekommst wieder Zugang, um weitere Korrekturen vorzunehmen.

Wie gefährlich ist HSTS bei Fehlkonfiguration?

Sehr. HSTS zwingt Browser zu HTTPS. Wenn HTTPS nicht korrekt funktioniert, bist du schnell in einer Sackgasse. Aktiviere HSTS erst, wenn Zertifikate/Weiterleitungen stabil stehen. Preload-Einträge sind nur mit Aufwand rückgängig zu machen.

Hilft es, Redirects über ein Plugin zu managen?

Nur, wenn du keine parallelen Server-/CDN-Regeln setzt. Generell sind serverseitige Redirects performanter und eindeutiger. Plugins eignen sich für inhaltliche Weiterleitungen (alte Slugs), nicht für Protokoll-/Domain-Normalisierung, sofern der Server das bereits übernimmt.

Schadet eine Redirect-Schleife meinem SEO?

Ja. Crawler brechen ab, Seiten werden nicht indexiert oder verlieren Signale. Zudem kosten lange Ketten Ladezeit. Behebe Schleifen zügig und halte Redirect-Strecken möglichst kurz (idealerweise 1 Hop).

Was kann ich als reiner Besucher tun?

Cookies/Cache für die Domain löschen, Inkognito probieren, Erweiterungen deaktivieren. Greift das nicht, liegt es serverseitig – Betreiber informieren.