Grundlegende Ursachen und Lösungen für den Fehler „Zu viele Weiterleitungen”

Der Fehler "Too Many Redirects" — in Browsern als ERR_TOO_MANY_REDIRECTS angezeigt und einer HTTP-Redirect-Schleife entsprechend — tritt auf, wenn ein Webserver und ein Client in eine kreisförmige Umleitungskette geraten, die nie zu einem endgültigen Ziel führt. Der Browser bricht die Anfrage ab, nachdem er seinen Umleitungsschwellenwert überschritten hat (typischerweise 20 Hops in Chrome), und zeigt diesen Fehler anstelle des Seitenladens an.

Dies ist kein vager Netzwerkfehler. Es handelt sich um einen deterministischen Fehler, der durch eine spezifische Fehlkonfiguration in Ihren Serverregeln, SSL-Einstellungen, CMS-Datenbankwerten, CDN-Konfiguration oder zwischengespeicherten Umleitungsdaten verursacht wird. Jede Instanz hat eine nachvollziehbare Grundursache, und jede Grundursache hat eine präzise Lösung. Dieser Leitfaden behandelt alle davon mit der technischen Tiefe, die erforderlich ist, um das Problem dauerhaft zu lösen — unabhängig davon, ob Sie eine WordPress-Website, eine benutzerdefinierte Anwendung oder einen reinen Server-Stack in einer VPS Hosting-Umgebung betreiben.

Was tatsächlich während einer Redirect-Schleife passiert

Wenn ein Browser eine URL anfordert, kann der Server mit einem 301 Moved Permanently-, 302 Found– oder 307 Temporary Redirect-Statuscode antworten, der auf einen neuen Standort verweist. Der Browser folgt diesem Location-Header, stellt eine weitere Anfrage und erwartet irgendwann in der Kette eine 200 OK-Antwort.

Eine Redirect-Schleife entsteht, wenn:

• URL A zu URL B weiterleitet und URL B zurück zu URL A weiterleitet (Zwei-Hop-Schleife)
• URL A zu URL B weiterleitet, welche zu URL C weiterleitet, welche zurück zu URL A weiterleitet (Multi-Hop-Schleife)
• Eine einzelne URL auf sich selbst weiterleitet (selbstreferenzielle Schleife)

Browser schleifen nicht unbegrenzt. Chrome und Firefox beenden beide nach ungefähr 20 Weiterleitungen und zeigen ERR_TOO_MANY_REDIRECTS an. Safari zeigt "Safari kann die Seite nicht öffnen." Das zugrunde liegende HTTP-Verhalten ist bei allen identisch.

Grundursachen und präzise Lösungen

1. Falsch konfigurierte Umleitungsregeln in .htaccess oder Nginx

Die technisch häufigste Ursache sind widersprüchliche oder kreisförmige Rewrite-Regeln in der Serverkonfigurationsschicht.

Apache .htaccess Beispiel einer fehlerhaften Schleife:

RewriteEngine On
RewriteRule ^page$ /page [R=301,L]

Diese Regel leitet /page zu /page weiter — eine selbstreferenzielle Schleife. Ebenso führen zwei Regeln, die zwischen /old-url und /new-url in entgegengesetzte Richtungen weiterleiten, zum selben Fehler.

Diagnose:

Öffnen Sie Ihre .htaccess-Datei und verfolgen Sie jede RewriteRule– und Redirect-Direktive manuell. Suchen Sie nach Regeln, bei denen das Zielmuster mit der Quelle einer anderen Regel übereinstimmen kann.

grep -n "Redirect|RewriteRule|RewriteCond" /var/www/html/.htaccess

Bei Nginx tritt das entsprechende Problem in server– oder location-Blöcken auf:

# Broken example — loop between two location blocks
location /old {
    return 301 /new;
}
location /new {
    return 301 /old;
}

Prüfen Sie Ihre Nginx-Konfiguration mit:

nginx -T | grep -A3 "return 301|rewrite"

Lösung: Stellen Sie sicher, dass jede Umleitungsregel eine eindeutige, nicht überlappende Quelle und ein eindeutiges Ziel hat. Verwenden Sie das [L]-Flag in Apache, um die Regelverarbeitung nach einer Übereinstimmung zu stoppen. In Nginx bevorzugen Sie return 301 gegenüber rewrite für mehr Klarheit und um unbeabsichtigte Verkettungen zu vermeiden.

2. Fehlkonfiguration der HTTP-zu-HTTPS-Weiterleitung

Dies ist die mit Abstand häufigste Ursache in modernen Hosting-Umgebungen, insbesondere nach dem Hinzufügen eines SSL-Zertifikats ohne Aktualisierung der Konfiguration auf Anwendungsebene.

Das Fehlermuster sieht folgendermaßen aus:

• Der Webserver erzwingt den gesamten HTTP-Traffic zu HTTPS über .htaccess oder Nginx-Konfiguration
• Die Anwendung (z. B. WordPress) hat ihre siteurl– oder home-Option in der Datenbank auf http:// gesetzt
• Die Anwendung leitet HTTPS-Anfragen dann zurück zu HTTP weiter
• Die Schleife lautet: HTTP → HTTPS (server) → HTTP (app) → HTTPS (server) → ...

Korrekte Apache .htaccess HTTPS-Weiterleitung:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Korrekte Nginx HTTPS-Weiterleitung:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Kritische Falle: Wenn Sie sich hinter einem Load Balancer oder Reverse Proxy (einschließlich Cloudflare) befinden, sieht der Backend-Server HTTPS möglicherweise nicht direkt. Der Proxy beendet SSL und leitet die Anfrage als HTTP an Ihren Ursprung weiter. Ihr Server sieht dann %{HTTPS} = off und leitet erneut zu HTTPS weiter — was eine Schleife erzeugt.

Die Lösung besteht darin, stattdessen den X-Forwarded-Proto-Header zu prüfen:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

3. Cloudflare und CDN SSL-Modus-Konflikt

Wenn Sie Cloudflare oder ein anderes CDN vor Ihrem Ursprungsserver verwenden, muss der SSL/TLS-Verschlüsselungsmodus dem tatsächlichen Zertifikatsstatus Ihres Ursprungs entsprechen.

Das häufigste Cloudflare-Schleifenszenario: SSL-Modus ist auf Flexible gesetzt, und der Ursprungsserver hat eine .htaccess-Regel, die HTTP zu HTTPS erzwingt. Cloudflare sendet HTTP an den Ursprung, der Ursprung leitet zu HTTPS weiter, Cloudflare empfängt diese Weiterleitung, sendet erneut HTTP — unendliche Schleife.

Lösung: Setzen Sie den Cloudflare SSL-Modus auf Full (Strict) und stellen Sie sicher, dass Ihr Ursprung ein gültiges Zertifikat hat. Wenn Sie alternativ Flexible verwenden müssen, entfernen Sie die HTTP→HTTPS-Weiterleitung vollständig von Ihrem Ursprungsserver und lassen Sie Cloudflare dies über eine Page Rule oder den Schalter "Always Use HTTPS" verwalten.

Deaktivieren Sie außerdem Automatic HTTPS Rewrites in Cloudflare, wenn Ihr Ursprung bereits Weiterleitungen verwaltet — wenn beide aktiv sind, verdoppelt sich die Weiterleitungslogik.

4. WordPress URL-Einstellungskonflikt

WordPress speichert seine kanonischen URLs in zwei Datenbankfeldern: siteurl (die WordPress-Kerninstallations-URL) und home (die öffentlich zugängliche URL). Wenn diese Werte mit den Umleitungsregeln des Servers oder untereinander in Konflikt geraten, ist eine Schleife fast unvermeidlich.

Aktuelle Werte über WP-CLI prüfen:

wp option get siteurl
wp option get home

Oder die Datenbank direkt abfragen:

mysql -u dbuser -p dbname -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"

Beide Werte müssen dasselbe Protokoll (https://) und dasselbe Domainformat (mit oder ohne www) verwenden, das Ihre Serverkonfiguration erzwingt.

Lösung über WP-CLI:

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

Lösung über wp-config.php (überschreibt Datenbankwerte, nützlich wenn der Admin-Bereich nicht zugänglich ist):

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

Plugin-Konflikte: Redirect-Manager-Plugins (Redirection, Simple 301 Redirects, Yoasts SEO-Redirect-Modul) können datenbankgespeicherte Umleitungsregeln erstellen, die mit serverseitigen Regeln in Konflikt geraten. Benennen Sie das Plugins-Verzeichnis vorübergehend um, um das Problem zu isolieren:

mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled

Aktivieren Sie Plugins einzeln wieder, nachdem Sie bestätigt haben, dass die Schleife verschwunden ist.

5. Browser-Cache und zwischengespeicherte 301-Weiterleitungen

Browser speichern 301 Moved Permanently-Antworten aggressiv zwischen — by Design. Wenn zuvor eine 301-Weiterleitung für eine URL bereitgestellt wurde und das Weiterleitungsziel dann geändert wurde, folgt der Browser möglicherweise noch der alten zwischengespeicherten Weiterleitung, die auf ein jetzt in einer Schleife befindliches Ziel verweisen kann.

Dies ist ein besonders trügerisches Szenario, da sich die Schleife in einem neuen Browser oder auf einem anderen Gerät möglicherweise nicht reproduziert, was Administratoren dazu verleitet, fälschlicherweise zu schlussfolgern, dass der Server in Ordnung ist.

Diagnoseschritte:

1. Öffnen Sie die URL in einem Inkognito-/Privatfenster (keine zwischengespeicherten Daten)
2. Testen Sie mit curl, um das Browser-Caching vollständig zu umgehen:

curl -I -L --max-redirs 10 https://example.com

1. Verwenden Sie einen Online-Redirect-Chain-Tracer (z. B. redirect-checker.org oder httpstatus.io), um jeden Hop serverseitig zu sehen

Lösung: Löschen Sie den Browser-Cache und die Cookies für die betroffene Domain. In Chrome: Einstellungen > Datenschutz und Sicherheit > Browserdaten löschen > Zwischengespeicherte Bilder und Dateien + Cookies auswählen.

Für serverseitiges Caching (Varnish, Redis, OPcache oder ein Caching-Plugin wie W3 Total Cache):

# Flush Varnish cache
varnishadm ban req.url ~ .

# Flush OPcache via PHP CLI
php -r "opcache_reset();"

6. www vs. Nicht-www-Weiterleitungskonflikte

Eine häufig übersehene Quelle von Redirect-Schleifen ist die inkonsistente Behandlung der www-Subdomain. Wenn Ihr Server www.example.com zu example.com weiterleitet und gleichzeitig example.com zu www.example.com weiterleitet, haben Sie eine Schleife.

Überprüfen Sie Ihre aktuelle DNS- und Weiterleitungskonfiguration:

curl -sI http://www.example.com | grep -i location
curl -sI http://example.com | grep -i location

Korrekte Apache-Konfiguration (kanonisches non-www):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

Stellen Sie sicher, dass diese Regel nicht mit einer anderen Regel kombiniert wird, die die non-www-Version zurück zu www weiterleitet.

7. Beschädigte oder widersprüchliche Cookies

Einige Anwendungen verwenden Cookies zur Verwaltung des Weiterleitungsstatus (z. B. Login-Weiterleitungen, Spracherkennung, A/B-Test-Frameworks). Wenn ein Cookie ein Weiterleitungsziel speichert, das selbst eine weitere Weiterleitung auslöst, wird die Schleife durch die Anwendungslogik und nicht durch die Serverkonfiguration angetrieben.

Diagnose: Testen Sie die URL mit allen für diese Domain gelöschten Cookies. Gehen Sie in Chrome DevTools (F12) zu Anwendung > Speicher > Cookies, wählen Sie die Domain aus und löschen Sie alle Einträge. Laden Sie die Seite neu.

Wenn der Fehler nach dem Löschen der Cookies verschwindet, liegt das Problem in der Sitzungs- oder Weiterleitungslogik Ihrer Anwendung und nicht in der Serverkonfiguration.

Vergleich: Häufige Redirect-Schleifenszenarien und ihre Lösungen

Systematischer Diagnose-Workflow

Bevor Sie eine Konfigurationsdatei anfassen, folgen Sie dieser Reihenfolge, um die Ursache zu isolieren:

Schritt 1 — Ohne Cache reproduzieren:

curl -v -L --max-redirs 25 https://example.com 2>&1 | grep -E "Location:|< HTTP"

Dies zeigt jeden Weiterleitungs-Hop und den endgültigen Antwortcode. Wenn Sie sehen, dass sich dieselben URLs wiederholen, haben Sie die Schleife bestätigt und identifiziert, welche URLs beteiligt sind.

Schritt 2 — Server-Fehlerprotokolle prüfen:

# Apache
tail -100 /var/log/apache2/error.log | grep -i redirect

# Nginx
tail -100 /var/log/nginx/error.log | grep -i rewrite

Schritt 3 — Die Schicht isolieren:

• Wenn die Schleife verschwindet, wenn Sie .htaccess-Regeln auskommentieren, liegt das Problem in der Apache-Konfiguration
• Wenn sie verschwindet, wenn Sie Cloudflare umgehen (Test über direkte IP), liegt das Problem in den CDN-Einstellungen
• Wenn sie verschwindet, wenn Sie das Plugins-Verzeichnis umbenennen, liegt das Problem in einem WordPress-Plugin
• Wenn sie im Inkognito-Modus verschwindet, aber nicht im normalen Modus, liegt das Problem im Browser-Cache oder in Cookies

Schritt 4 — SSL-Zertifikatsbindung validieren:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "subject|issuer|Verify"

Ein ungültiges oder nicht übereinstimmendes Zertifikat kann HTTPS-Weiterleitungsfehler verursachen, die sich als Schleifen manifestieren.

Redirect-Schleifen in der Produktion verhindern

Nach der Behebung verhindern diese Praktiken ein erneutes Auftreten:

• Verwenden Sie eine einzige kanonische Umleitungsregel, die sowohl HTTP→HTTPS als auch www→non-www in einem Durchgang verarbeitet, nicht zwei separate Regeln, die interagieren können
• Testen Sie Weiterleitungsketten vor dem Deployment mit curl -L oder einem Online-Redirect-Checker nach jeder Konfigurationsänderung
• Setzen Sie 301-Weiterleitungen nur wenn permanent — verwenden Sie 302 beim Testen, damit Browser die Weiterleitung nicht zwischenspeichern
• Dokumentieren Sie jede Umleitungsregel in Ihrer .htaccess– oder Nginx-Konfiguration mit Inline-Kommentaren, die den Zweck erklären
• Überwachen Sie mit Uptime-Tools, die Weiterleitungsketten verfolgen und alarmieren, wenn die Hop-Anzahl einen Schwellenwert überschreitet

Für Teams, die mehrere Websites auf einem VPS mit cPanel verwalten, bietet das Redirects-Modul von cPanel eine visuelle Oberfläche zur Verwaltung von Umleitungsregeln, schreibt jedoch in .htaccess — überprüfen Sie die Ausgabe nach der Verwendung der GUI immer manuell.

Wenn Sie eine Website mit hohem Traffic oder mehrere Domains betreiben, gibt Ihnen ein Dedicated Server vollständige Kontrolle über die Nginx- oder Apache-Konfiguration auf Systemebene, wodurch Einschränkungen in gemeinsam genutzten Umgebungen entfallen, die das Debugging von Weiterleitungen erschweren können.

Für Websites, die VPS Control Panels wie Plesk oder DirectAdmin verwenden, können Umleitungsregeln sowohl über die Panel-Oberfläche als auch direkt in Konfigurationsdateien verwaltet werden — prüfen Sie beide Orte, um sicherzustellen, dass sie sich nicht widersprechen.

Technische Schlüssel-Checkliste

Verwenden Sie dies als Vorab-Checkliste bei der Diagnose von ERR_TOO_MANY_REDIRECTS:

• [ ] Führen Sie curl -v -L --max-redirs 25 aus, um die vollständige Weiterleitungskette zu kartieren, bevor Sie eine Konfiguration ändern
• [ ] Bestätigen Sie, dass sowohl siteurl als auch home in WordPress mit dem Protokoll und der Domain übereinstimmen, die Ihr Server erzwingt
• [ ] Überprüfen Sie, ob der Cloudflare SSL-Modus Full (Strict) ist, wenn Ihr Ursprung ein gültiges Zertifikat hat
• [ ] Prüfen Sie, ob .htaccess oder Nginx-Konfiguration X-Forwarded-Proto anstelle von %{HTTPS} verwendet, wenn hinter einem Proxy
• [ ] Stellen Sie sicher, dass www– und non-www-Weiterleitungen unidirektional sind — nur eine kanonische Form
• [ ] Deaktivieren Sie vorübergehend alle weiterleitungsbezogenen Plugins und aktivieren Sie sie einzeln wieder
• [ ] Löschen Sie den Browser-Cache und testen Sie im Inkognito-Modus, um zwischengespeicherte 301-Antworten auszuschließen
• [ ] Untersuchen Sie Anwendungs-Cookies auf Weiterleitungsstatus, der eine Schleife antreiben könnte
• [ ] Überprüfen Sie, ob das SSL-Zertifikat gültig und korrekt an die Domain gebunden ist
• [ ] Verwenden Sie nach der Behebung vorübergehend 302, bevor Sie zu 301 wechseln, um das erneute Zwischenspeichern einer fehlerhaften Weiterleitung zu verhindern

FAQ

Was ist der Unterschied zwischen ERR_TOO_MANY_REDIRECTS und einem 310 HTTP-Statuscode?

ERR_TOO_MANY_REDIRECTS ist ein clientseitiger Browser-Fehler, der ausgelöst wird, nachdem der Browser sein Weiterleitungslimit überschritten hat (typischerweise 20). HTTP 310 ist ein selten verwendeter Statuscode, der "Too Many Redirects" auf Protokollebene bedeutet. In der Praxis sind fast alle Redirect-Schleifenfehler, die Sie in der Produktion begegnen, der browserseitige ERR_TOO_MANY_REDIRECTS — keine vom Server ausgegebene 310-Antwort.

Warum erscheint die Redirect-Schleife nur auf einigen Browsern oder Geräten, aber nicht auf anderen?

Der häufigste Grund ist eine zwischengespeicherte 301-Weiterleitung im Browser, die auf ein jetzt ungültiges Ziel verweist. Da 301-Antworten standardmäßig unbegrenzt zwischengespeichert werden, kann ein Browser, der die URL zuvor besucht hat, einer veralteten Weiterleitungskette folgen. Das Testen im Inkognito-Modus oder auf einem neuen Gerät umgeht diesen Cache und zeigt das aktuelle Verhalten des Servers.

Wie behebe ich eine Redirect-Schleife in WordPress, wenn ich keinen Zugriff auf das Admin-Panel habe?

Fügen Sie die folgenden Zeilen direkt zu wp-config.php hinzu, um die Datenbank-URL-Werte zu überschreiben, und greifen Sie dann auf das Admin-Panel zu, um die Einstellungen korrekt zu korrigieren:

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

Alternativ können Sie die Werte direkt in der Datenbank mit wp-cli oder einer direkten MySQL-Abfrage gegen die wp_options-Tabelle aktualisieren.

Kann eine Redirect-Schleife SEO-Rankings beeinflussen?

Ja. Eine Redirect-Schleife gibt keine 200 OK-Antwort zurück, was bedeutet, dass Googlebot die betroffene URL nicht crawlen oder indexieren kann. Wenn die Schleife Ihre Homepage oder wichtige Landing Pages betrifft, führt dies im Laufe der Zeit zur Deindexierung. Darüber hinaus geht jede 301-Link-Equity, die durch die in der Schleife befindliche URL fließt, effektiv verloren. Die schnelle Behebung der Schleife und die Überprüfung der Crawlbarkeit in der Google Search Console ist unerlässlich.

Wie verhindere ich, dass Cloudflare mit meinem SSL-Setup Redirect-Schleifen verursacht?

Setzen Sie den SSL/TLS-Verschlüsselungsmodus von Cloudflare im SSL/TLS-Dashboard auf Full (Strict). Dies stellt sicher, dass Cloudflare mit Ihrem Ursprung über HTTPS mit einem validierten Zertifikat kommuniziert, wodurch die HTTP↔HTTPS-Schleife eliminiert wird, die der Flexible-Modus erzeugt, wenn der Ursprungsserver ebenfalls HTTPS erzwingt. Deaktivieren Sie außerdem "Automatic HTTPS Rewrites", wenn Ihr Ursprung oder .htaccess bereits die HTTP-zu-HTTPS-Weiterleitung verwaltet, um doppelte Weiterleitungslogik zu vermeiden.