ERR_TOO_MANY_REDIRECTS: So beheben Sie den Fehler (alle Browser)

Was bedeutet ERR_TOO_MANY_REDIRECTS?

ERR_TOO_MANY_REDIRECTS bedeutet, dass die Seite Ihren Browser mehr als 20-mal an eine andere Adresse geschickt hat, ohne je zu laden: eine Umleitungsschleife. Chrome meldet „Diese Seite funktioniert nicht“ und „example.com hat dich zu oft weitergeleitet.“, Edge zeigt denselben Fehlercode, Firefox meldet „Fehler: Umleitungsfehler“ und Safari „Safari kann die Seite nicht öffnen“ mit „Beim Öffnen von ‚example.com‘ traten zu viele Umleitungen auf.“

Wenn Sie die Website nur besuchen, löschen Sie die Cookies dieser Website und laden Sie neu: Funktioniert die Seite bei allen anderen, ist meist ein veraltetes Cookie schuld. Ist es Ihre eigene Website, wird fast immer HTTPS (oder www) an zwei Stellen gleichzeitig erzwungen, am häufigsten durch den Flexible-SSL-Modus von Cloudflare plus eine HTTPS-Weiterleitung auf dem Server.

Das Limit ist überall gleich, weil der Fetch-Standard, den die Browser umsetzen, es so vorschreibt: „If request's redirect count is 20, then return a network error.“ (Hat eine Anfrage 20 Weiterleitungen hinter sich, endet sie mit einem Netzwerkfehler.) Die Schleife selbst besteht meist aus zwei 301- oder 302-Antworten, die aufeinander zeigen: URL A schickt Sie zu URL B, URL B schickt Sie zurück zu A, und bei 20 hört der Browser auf zu zählen.

Was verursacht Umleitungsschleifen?

Umleitungsschleifen entstehen, wenn zwei oder mehr Weiterleitungsregeln miteinander in Konflikt stehen. Der Server schickt den Browser zu einer URL, und diese URL schickt den Browser wieder zurück. Hier sind die häufigsten Ursachen:

• SSL/HTTPS-Fehlkonfiguration — Die häufigste Ursache. Ihr Server erzwingt eine HTTP-zu-HTTPS-Weiterleitung, aber Ihr CDN oder Load Balancer verbindet sich über HTTP mit dem Ursprungsserver, wodurch eine Schleife entsteht: CDN → HTTP → Server leitet zu HTTPS weiter → CDN entfernt HTTPS → HTTP → Schleife
• Cloudflare Flexible SSL — Cloudflares Flexible-SSL-Modus sendet Anfragen über HTTP an Ihren Ursprungsserver. Wenn Ihr Ursprungsserver ebenfalls eine HTTP-zu-HTTPS-Weiterleitung hat, entsteht eine endlose Schleife zwischen Cloudflare und Ihrem Server
• Widersprüchliche .htaccess-Regeln — Mehrere Weiterleitungsregeln in der .htaccess, die sich widersprechen, z. B. eine Regel, die www erzwingt, und eine andere, die gleichzeitig auf ohne www umleitet
• WordPress-URL-Diskrepanz — WordPress-Adresse (URL) und Website-Adresse (URL) unter Einstellungen > Allgemein stimmen nicht überein, oder eine verwendet HTTP während die andere HTTPS verwendet
• Veraltete Browser-Cookies — Alte Cookies mit veralteten Weiterleitungsanweisungen oder Sitzungsdaten, die den Browser zu einer URL zwingen, die nicht mehr existiert oder verschoben wurde
• Im CDN oder Proxy zwischengespeicherte Weiterleitungen — Ihr CDN hat eine alte 301-Weiterleitung zwischengespeichert, die nun mit Ihrer aktuellen Serverkonfiguration in Konflikt steht
• Serverkonfigurationskonflikte — Nginx- oder Apache-Konfigurationsdateien mit konkurrierenden Weiterleitungsblöcken, z. B. Weiterleitungen sowohl im Server-Block als auch in der .htaccess gleichzeitig
• Login-Schleifen in Web-Apps — eine Anmeldeseite, die abgemeldete Besucher auf sich selbst umleitet, oder ein Sitzungs-Cookie, das der Browser nicht speichert (OAuth, Supabase Auth, NextAuth). Siehe Lösung 8

Wie man eine Umleitungsschleife diagnostiziert

Bevor Sie Korrekturen versuchen, identifizieren Sie die genaue Weiterleitungskette. So erfahren Sie genau, welche URLs beteiligt sind und welche Weiterleitungsregeln die Schleife verursachen.

Methode 1: Mit curl Weiterleitungen nachverfolgen

Der schnellste Weg, eine Weiterleitungskette zu sehen, ist curl im Terminal. Das Flag -I ruft nur Header ab, -L folgt Weiterleitungen, und --max-redirs begrenzt die Anzahl:

# Trace redirect chain (limit to 10 hops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example output showing a redirect loop:
# HTTP/2 301
# location: http://example.com/
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/
# HTTP/2 301
# location: http://example.com/
# (repeats...)

Wenn Sie sehen, dass dieselben zwei URLs in den Location-Headern abwechselnd auftauchen, haben Sie eine Umleitungsschleife bestätigt. Achten Sie auf die Statuscodes: 301 ist eine permanente Weiterleitung, die Browser zwischenspeichern, 302 eine temporäre Weiterleitung, die nur zwischengespeichert wird, wenn die Antwort es ausdrücklich erlaubt.

Achten Sie auch auf das Schema in jedem Location-Header: Eine Schleife zwischen der http://- und der https://-Version derselben URL ist das häufigste Muster und weist direkt auf eine SSL-Einstellung hin.

Methode 2: Browser-DevTools Netzwerk-Tab

Sie können Weiterleitungen auch visuell in den Chrome DevTools nachverfolgen:

• Schritt 1 — Öffnen Sie Chrome DevTools mit F12 oder Strg+Umschalt+I (Mac: Cmd+Option+I)
• Schritt 2 — Gehen Sie zum Netzwerk-Tab und aktivieren Sie Protokoll beibehalten (dies behält Einträge über Weiterleitungen hinweg bei)
• Schritt 3 — Laden Sie die Seite, die den Fehler auslöst
• Schritt 4 — Sehen Sie sich die Reihenfolge der Anfragen an. Jede Weiterleitung erscheint als separater Eintrag mit Status 301 oder 302. Die Location-Spalte zeigt, wohin jede Weiterleitung zeigt

Der Netzwerk-Tab zeigt die gesamte Weiterleitungskette chronologisch an. Sie werden das Muster erkennen — typischerweise wiederholen sich zwei oder drei URLs in einem Zyklus. Verwenden Sie DNS Robots HTTP-Header-Checker, um Antwort-Header außerhalb Ihres Browser-Caches zu überprüfen.

Methode 3: Redirect Checker von DNS Robot

Wenn Sie kein Terminal haben, fügen Sie die URL in DNS Robots Redirect Checker ein. Er folgt jedem Sprung von unserem Server aus, zeigt jeden Statuscode und Location-Header und meldet, wenn die Kette zu sich selbst zurückführt. Er arbeitet ohne die Cookies Ihres Browsers und zeigt Ihnen deshalb sofort, ob die Schleife an der Website oder an Ihrem Browser liegt.

Lösung 1: Browser-Cookies und Cache löschen

Beginnen Sie mit der einfachsten Lösung. Veraltete Cookies oder zwischengespeicherte Weiterleitungen in Ihrem Browser können Schleifen verursachen, selbst wenn die Serverkonfiguration korrekt ist. Dies ist besonders häufig nach einer Website-Migration von HTTP zu HTTPS — alte Cookies können noch HTTP-URLs referenzieren.

Cookies in Chrome löschen

Löschen Sie die Cookies für die spezifische Website statt aller Cookies — so bleiben Ihre Anmeldungen auf anderen Websites erhalten:

• Schritt 1 — Klicken Sie auf das Schloss-Symbol (oder das Einstellungssymbol) in der Adressleiste neben der URL
• Schritt 2 — Klicken Sie auf Website-Einstellungen
• Schritt 3 — Klicken Sie auf Daten löschen, um Cookies und zwischengespeicherte Daten nur für diese Website zu entfernen
• Schritt 4 — Laden Sie die Seite neu

# Chrome keyboard shortcut to open Delete browsing data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

Oder löschen Sie alles für alle Websites: Drücken Sie Strg+Umschalt+Entf (Mac: Cmd+Umschalt+Rückschritttaste), um Browserdaten löschen zu öffnen, setzen Sie Häkchen bei Cookies und andere Websitedaten und Bilder und Dateien im Cache, wählen Sie Gesamte Zeit und klicken Sie auf Daten löschen.

Cookies in Firefox und Safari löschen

Firefox: Drücken Sie Strg+Umschalt+Entf (Mac: Cmd+Umschalt+Rückschritttaste), setzen Sie Häkchen bei Cookies und Website-Daten und Temporäre Dateien und Seiten im Cache, stellen Sie den Zeitraum auf Alles und klicken Sie auf Löschen.

Safari: Gehen Sie zu Safari > Einstellungen > Datenschutz > Websitedaten verwalten, suchen Sie die betroffene Domain, wählen Sie sie aus und klicken Sie auf Entfernen. Leeren Sie dann den Cache mit Cmd+Option+E.

Behebt das Löschen der Cookies den Fehler, hat sich kürzlich eine Weiterleitungsregel auf dem Server geändert, und Ihr Browser trug noch den alten Zustand mit sich. Besucher mit neuen Sitzungen sehen den Fehler womöglich nie.

Gmail, Google Drive oder accounts.google.com „hat dich zu oft weitergeleitet“

Lautet die Meldung „Diese Seite funktioniert nicht“ mit „mail.google.com hat dich zu oft weitergeleitet.“ und dem Link „Lösche deine Cookies.“, oder nennt sie accounts.google.com bzw. drive.google.com, dann kreist die Schleife zwischen Googles Anmeldeseiten und den Cookies Ihres Browsers, nicht auf einer defekten Website. Die Google-Anmeldung funktioniert nur, wenn der Browser Googles Cookies behält. Alles, was sie blockiert oder umschreibt, schickt Sie im Kreis:

• Nur die Google-Cookies löschen — öffnen Sie chrome://settings/content/all (Alle Websites), suchen Sie nach google.com, löschen Sie die Daten und melden Sie sich neu an. Wie Googles eigene Hilfe erklärt, müssen Sie sich danach in diesem Browser wieder in Ihrem Google-Konto anmelden
• Cookies für Google zulassen — entfernen Sie google.com aus jeder Liste von Websites, die keine Cookies verwenden dürfen. Wenn Sie Drittanbieter-Cookies blockieren, fügen Sie [*.]google.com unter Websites, die Drittanbieter-Cookies verwenden dürfen hinzu (Chrome: Einstellungen → Datenschutz und Sicherheit → Drittanbieter-Cookies)
• Von allen Konten abmelden, dann mit einem anmelden — mehrere gleichzeitig angemeldete Konten oder ein Arbeitskonto, das die Anmeldung an die Login-Seite des eigenen Unternehmens weitergibt, können zwischen beiden hin- und herspringen
• Cookie- und Datenschutz-Erweiterungen ausschalten — Erweiterungen, die während der Anmeldung Cookies löschen oder umschreiben, sind ein häufiger Auslöser. Im Inkognitomodus bleiben Erweiterungen in Chrome aus, solange Sie sie dort nicht erlauben; testen Sie deshalb zuerst ein Inkognitofenster

Lösung 2: SSL/HTTPS-Konfiguration prüfen

SSL-Fehlkonfiguration ist die häufigste Ursache für Umleitungsschleifen. Das häufigste Szenario ist ein Konflikt zwischen Ihrem CDN/Proxy und Ihrem Ursprungsserver bezüglich der Verwendung von HTTP oder HTTPS.

Typischerweise passiert Folgendes: Ihr CDN verbindet sich über HTTP mit dem Ursprungsserver (da es die SSL-Terminierung übernimmt), aber der Ursprungsserver hat eine HTTP-zu-HTTPS-Weiterleitung. Der Ursprungsserver schickt das CDN zurück zu HTTPS, das CDN entfernt HTTPS und sendet wieder HTTP — endlose Schleife.

Ein fehlerhaftes Zertifikat im selben Aufbau führt stattdessen zu einem anderen Fehler; siehe ERR_SSL_PROTOCOL_ERROR und „Dies ist keine sichere Verbindung“.

• SSL-Zertifikat prüfen — Verwenden Sie DNS Robots SSL Check, um sicherzustellen, dass Ihr Zertifikat gültig ist, nicht abgelaufen ist und die richtige Domain abdeckt
• Protokolle abgleichen — Wenn Ihr CDN SSL terminiert, entfernen Sie entweder die HTTP-zu-HTTPS-Weiterleitung auf Ihrem Ursprungsserver oder konfigurieren Sie das CDN, sich über HTTPS mit dem Ursprungsserver zu verbinden
• HTTPS-Erzwingungseinstellungen prüfen — Wenn Sie sowohl eine serverseitige Weiterleitung (Nginx/Apache) ALS AUCH eine CDN-seitige HTTPS-Erzwingung haben, entfernen Sie eine davon
• X-Forwarded-Proto-Header überprüfen — Hinter einem Proxy sollte Ihr Ursprungsserver diesen Header prüfen statt des rohen Verbindungsprotokolls, um festzustellen, ob die ursprüngliche Anfrage HTTPS war

Lösung 3: Cloudflare-Umleitungsschleifen beheben

Cloudflare ist der häufigste Auslöser, weil sein Verschlüsselungsmodus bestimmt, ob es Ihren Server über HTTP oder HTTPS erreicht. Cloudflares Seite zur Fehlerbehebung (Stand September 2026) nennt fünf Einstellungen, die eine Schleife erzeugen, jeweils im Zusammenspiel mit etwas, das Ihr Ursprungsserver tut:

Die übliche Lösung für eine Cloudflare-Umleitungsschleife: Ändern Sie den SSL/TLS-Verschlüsselungsmodus von Flexible auf Full oder Full (Strict). Dadurch verbindet sich Cloudflare über HTTPS mit Ihrem Ursprungsserver und die HTTP-zu-HTTPS-Schleife wird eliminiert.

Schritt-für-Schritt Cloudflare-Korrektur

• Schritt 1 — Melden Sie sich im Cloudflare Dashboard an
• Schritt 2 — Wählen Sie Ihre Domain aus
• Schritt 3 — Gehen Sie zu SSL/TLS > Overview
• Schritt 4 — Stellen Sie den Verschlüsselungsmodus auf Full (strict), wenn Ihr Ursprungsserver ein gültiges Zertifikat hat (ein kostenloses Cloudflare-Origin-CA-Zertifikat zählt dazu), oder nur dann auf Full, wenn es selbstsigniert ist
• Schritt 5 — Gehen Sie zu SSL/TLS > Edge Certificates und prüfen Sie, ob Always Use HTTPS aktiviert ist. Wenn Ihr Ursprungsserver bereits zu HTTPS weiterleitet, deaktivieren Sie dies, um eine doppelte Weiterleitung zu vermeiden
• Schritt 6 — Überprüfen Sie die Page Rules und Redirect Rules auf widersprüchliche URL-Weiterleitungen
• Schritt 7 — Leeren Sie den Cloudflare-Cache: Gehen Sie zu Caching > Configuration > Purge Everything

Lösung 4: .htaccess-Weiterleitungsregeln korrigieren (Apache)

Auf Apache-Servern ist die .htaccess der häufigste Speicherort für Weiterleitungsregeln — und der häufigste Ort, an dem Umleitungsschleifen entstehen. Widersprüchliche Regeln, doppelte Weiterleitungen oder fehlende Bedingungsprüfungen können Schleifen verursachen.

• Auf doppelte HTTPS-Weiterleitungen prüfen — Wenn Ihr Hosting-Panel (cPanel, Plesk) HTTPS erzwingt, entfernen Sie die manuelle Weiterleitung aus der .htaccess
• RewriteCond-Bedingungen prüfen — Jede umleitende RewriteRule sollte eine RewriteCond haben, die verhindert, dass sie bei bereits passenden URLs ausgelöst wird. Ohne diese wird die Regel bei jeder Anfrage ausgelöst, einschließlich der weitergeleiteten
• Auf das [L]-Flag achten — Das [L]-Flag bedeutet 'letzte Regel', aber nur für den aktuellen Durchlauf. Wenn in einem Unterverzeichnis eine weitere .htaccess existiert, wird sie erneut ausgeführt. Verwenden Sie auf Apache 2.4+ stattdessen [END]
• Proxy-Header überprüfen — Hinter einem CDN verwenden Sie %{HTTP:X-Forwarded-Proto} statt %{HTTPS}, um das ursprüngliche Protokoll zu erkennen

# Correct HTTPS redirect behind Cloudflare/CDN:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Wenn Sie nicht sicher sind, welche Regel die Schleife verursacht, benennen Sie die .htaccess vorübergehend in .htaccess.bak um und testen Sie, ob die Website lädt. Wenn ja, liegt das Problem in Ihrer .htaccess-Datei. Aktivieren Sie die Regeln einzeln wieder, bis Sie die fehlerhafte Regel finden.

Lösung 5: WordPress-Umleitungsschleifen beheben

WordPress-Umleitungsschleifen stammen typischerweise aus drei Quellen: nicht übereinstimmende URLs in den Einstellungen, Plugin-Konflikte oder falsche wp-config.php-Werte. Wenn Sie wegen der Umleitungsschleife nicht auf das WordPress-Dashboard zugreifen können, müssen Sie die Korrektur direkt über die Datenbank oder Konfigurationsdateien vornehmen.

WordPress-URL-Einstellungen überprüfen

WordPress hat zwei URL-Einstellungen, die übereinstimmen müssen: WordPress-Adresse (URL) und Website-Adresse (URL) unter Einstellungen > Allgemein. Wenn eine http:// und die andere https:// verwendet, oder eine www. hat und die andere nicht, entsteht eine Umleitungsschleife.

Wenn Sie nicht auf das Dashboard zugreifen können, codieren Sie die URLs fest in der wp-config.php:

// Add these lines to wp-config.php (above "That's all, stop editing!"):
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

// If behind a reverse proxy (Cloudflare, Nginx proxy):
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Plugins deaktivieren, um Konflikte zu finden

Weiterleitungs- und Caching-Plugins sind häufige Verursacher. Plugins wie Redirection, Yoast SEO, Really Simple SSL, WP Super Cache und W3 Total Cache können Weiterleitungsregeln hinzufügen, die mit Ihren Server- oder CDN-Einstellungen in Konflikt stehen.

Wenn Sie nicht auf das Dashboard zugreifen können, deaktivieren Sie alle Plugins über FTP oder SSH:

# Rename the plugins folder to disable all plugins at once:
cd /var/www/html/wp-content/
mv plugins plugins.bak

# If the site loads, rename it back and disable plugins one by one:
mv plugins.bak plugins
# Then rename individual plugin folders to find the culprit:
mv plugins/really-simple-ssl plugins/really-simple-ssl.bak

Wenn das Deaktivieren der Plugins den Fehler behebt, aktivieren Sie sie einzeln wieder, um das konfliktverursachende Plugin zu identifizieren. Die häufigsten Verursacher sind SSL-Plugins, die HTTP-zu-HTTPS-Weiterleitungen hinzufügen, wenn Ihr Server oder CDN dies bereits übernimmt.

Lösung 6: Serverseitige Weiterleitungen korrigieren (Nginx & Apache)

Serverkonfigurationsdateien können Weiterleitungsregeln enthalten, die mit Anwendungsebenen-Weiterleitungen (WordPress, .htaccess) oder CDN-Einstellungen in Konflikt stehen.

Nginx: Weiterleitungskonflikte prüfen

Nginx-Umleitungsschleifen treten typischerweise auf, wenn der HTTP-Server-Block zu HTTPS weiterleitet, aber etwas im HTTPS-Block zurück zu HTTP weiterleitet. Überprüfen Sie Ihre Site-Konfiguration:

# Correct Nginx HTTPS redirect (separate server blocks):
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # SSL certificate configuration here
    # DO NOT add another redirect to HTTPS here
}

# If behind Cloudflare/proxy, check real protocol:
server {
    listen 80;
    server_name example.com;
    if ($http_x_forwarded_proto != 'https') {
        return 301 https://example.com$request_uri;
    }
}

Führen Sie nach dem Bearbeiten nginx -t aus, um Syntaxfehler zu finden, und dann systemctl reload nginx, um die Änderung ohne Ausfallzeit zu übernehmen.

Apache: VirtualHost-Weiterleitungen prüfen

Auf Apache prüfen Sie sowohl die VirtualHost-Konfiguration als auch die .htaccess. Eine Weiterleitung in der VirtualHost-Konfiguration plus eine Weiterleitung in der .htaccess erzeugt eine doppelte Weiterleitung, die zu einer Schleife führen kann:

# Check Apache config for redirect rules:
grep -r 'Redirect\|RewriteRule' /etc/apache2/sites-enabled/
grep -r 'Redirect\|RewriteRule' /etc/httpd/conf.d/

# Check .htaccess:
cat /var/www/html/.htaccess | grep -i 'rewrite\|redirect'

Entfernen Sie doppelte Weiterleitungen — behalten Sie die Weiterleitung nur an einer Stelle bei. Best Practice ist es, HTTPS-Weiterleitungen in der VirtualHost-Konfiguration (nicht in der .htaccess) zu behandeln, da VirtualHost-Regeln einmal pro Anfrage verarbeitet werden, während die .htaccess bei jeder Anfrage verarbeitet wird.

Lösung 7: Browserspezifische Fehlerbehebung

Wenn der Fehler nur in einem Browser auftritt, ist das Problem wahrscheinlich eine zwischengespeicherte Weiterleitung oder ein Erweiterungskonflikt und kein Serverproblem.

Chrome: HSTS und Socket-Pool leeren

Chrome speichert HSTS-Richtlinien (HTTP Strict Transport Security), die HTTPS erzwingen. Wenn eine Website zuvor einen HSTS-Header gesendet hat, aber HTTPS nicht mehr korrekt nutzt, leitet Chrome auch nach dem Löschen der Cookies weiterhin zu HTTPS weiter.

• HSTS-Cache leeren — Gehen Sie zu chrome://net-internals/#hsts, geben Sie die Domain unter Delete domain security policies ein und klicken Sie auf Delete
• Socket-Pools leeren — Gehen Sie zu chrome://net-internals/#sockets und klicken Sie auf Flush socket pools, um zwischengespeicherte Verbindungen zu löschen
• DNS-Cache leeren — Gehen Sie zu chrome://net-internals/#dns und klicken Sie auf Clear host cache (weitere Wege unter DNS-Cache leeren)
• Im Inkognito-Modus testen — Öffnen Sie ein Inkognito-Fenster (Strg+Umschalt+N) und versuchen Sie die URL. Wenn es im Inkognito-Modus funktioniert, aber nicht im normalen Fenster, ist eine zwischengespeicherte Weiterleitung oder eine Erweiterung die Ursache

Korrekturen für Firefox und Safari

Firefox: Geben Sie about:config in die Adressleiste ein, suchen Sie nach network.http.redirection-limit und prüfen Sie, ob der Wert 20 (der Standard) ist. Ein niedrigerer Wert, von Hand oder per Unternehmensrichtlinie gesetzt, lässt Weiterleitungen früher scheitern. Versuchen Sie auch, Website-Daten zu löschen: Einstellungen > Datenschutz & Sicherheit > Daten verwalten > Domain suchen > Ausgewählte löschen.

Safari: Safari zeigt „Safari kann die Seite nicht öffnen“ mit „Beim Öffnen von ‚example.com‘ traten zu viele Umleitungen auf.“; die Konsole des Web Inspector meldet „Load cannot follow more than 20 redirections“ (sinngemäß: Der Ladevorgang kann nicht mehr als 20 Weiterleitungen folgen; diese WebKit-Meldung ist nicht übersetzt und erscheint auch auf deutschen Systemen auf Englisch). Gehen Sie zu Safari > Einstellungen > Datenschutz > Websitedaten verwalten, suchen Sie die Domain und klicken Sie auf Entfernen. Hängt die Seite weiter in der Schleife, testen Sie ein privates Fenster: Hängt auch das fest, ist die Website falsch konfiguriert.

Lösung 8: Login-Umleitungsschleifen in Web-Apps

In einer Web-App steckt die Schleife oft im eigenen Code: Eine Seite, die einen angemeldeten Nutzer verlangt, leitet auf /login um, und etwas schickt /login (oder den Anmelde-Callback) direkt zurück. Die Browserkonsole zeigt das als net::ERR_TOO_MANY_REDIRECTS bei der fehlschlagenden Anfrage.

• Die Login-Seite ist selbst geschützt — Auth-Middleware, die auf jeder Route läuft, leitet auch /login und die Callback-Route auf /login um. Nehmen Sie beide von der Prüfung aus
• Das Sitzungs-Cookie wird nie gespeichert — ein Cookie mit SameSite=None muss auch Secure sein, sonst verwirft der Browser es; ein Cookie für die falsche Domain wird nie zurückgeschickt. In beiden Fällen sieht jede Anfrage weiter abgemeldet aus
• Die Callback-URL passt nicht — der Anbieter (Google, GitHub, Supabase Auth) schickt Nutzer an einen Callback, den Ihre App nicht verarbeitet, und diese Route leitet wieder zum Login um
• HTTP statt HTTPS hinter einem Proxy — die App baut ihre Weiterleitungs-URLs mit http://, weil sie X-Forwarded-Proto ignoriert: die Schleife aus Lösung 2, eine Ebene höher

// Next.js: proxy.ts (middleware.ts before Next.js 16).
// Never run the sign-in check on the sign-in pages themselves.
export const config = {
  matcher: ["/((?!login|auth/callback|_next/static|_next/image|favicon.ico).*)"],
};

Testen Sie die Korrektur im abgemeldeten Zustand mit dem Redirect Checker oder curl -IL: Eine gesunde Kette endet auf der Login-Seite mit 200, nicht mit einer weiteren Weiterleitung.

Umleitungsschleifen verhindern

Nachdem Sie den unmittelbaren Fehler behoben haben, befolgen Sie diese Empfehlungen, um Umleitungsschleifen künftig zu vermeiden:

• Nur an einer Stelle weiterleiten — Wählen Sie eine Ebene für Ihre HTTPS-Weiterleitung: entweder das CDN, den Webserver oder die Anwendung. Leiten Sie niemals auf mehreren Ebenen gleichzeitig weiter
• Beim Testen 302 verwenden — Verwenden Sie während des Debuggings 302-Weiterleitungen (temporär) statt 301 (permanent). Browser speichern 301er aggressiv zwischen, was das Testen von Änderungen erschwert. Wechseln Sie zu 301, wenn Sie bestätigt haben, dass die Weiterleitung korrekt funktioniert
• Immer mit curl testen — Führen Sie nach dem Hinzufügen einer Weiterleitungsregel curl -ILs https://ihreseite.com | grep -i 'HTTP/\|location:' aus, um zu überprüfen, dass die Weiterleitungskette mit einer 200-Antwort endet
• Mit Tools überwachen — Verwenden Sie regelmäßig DNS Robots HTTP-Header-Checker, um sicherzustellen, dass Ihre Website eine saubere 200-Antwort ohne unerwartete Weiterleitungen zurückgibt
• Weiterleitungen dokumentieren — Führen Sie ein Verzeichnis aller Weiterleitungsregeln in Ihrer Serverkonfiguration, .htaccess, CDN-Regeln und Anwendungseinstellungen. Wenn mehrere Teammitglieder eine Website verwalten, sind undokumentierte Weiterleitungen die häufigste Ursache für Schleifen
• CDN-Cache nach Änderungen leeren — Leeren Sie nach dem Ändern einer Weiterleitungsregel sofort Ihren CDN-Cache. Zwischengespeicherte alte 301-Weiterleitungen können tagelang bestehen bleiben

Eine gesunde Kette hat höchstens ein oder zwei Sprünge (zum Beispiel HTTP → HTTPS → 200 OK). Drei oder mehr bedeuten meist eine Weiterleitung, die Sie nicht mehr brauchen.

SEO-Auswirkungen von Umleitungsschleifen

Umleitungsschleifen nehmen Seiten aus der Suche. Laut Googles Crawling-Dokumentation folgen Googles Crawler bis zu 10 Weiterleitungen; eine Schleife erreicht nie den Inhalt, deshalb meldet die Search Console einen Weiterleitungsfehler, und die URL fällt aus dem Index, bis die Schleife behoben ist.

Lange Ketten kosten auch dann, wenn sie enden: Jeder Sprung ist eine weitere Anfrage, die Browser und Googlebot stellen müssen, bevor die Seite laden kann. Lassen Sie Links und Weiterleitungen deshalb direkt auf die endgültige URL zeigen.

• Verlorene Indexierung — Seiten, die in Umleitungsschleifen feststecken, werden nicht indexiert und verschwinden vollständig aus den Suchergebnissen
• Verschwendetes Crawl-Budget — Googlebot verwendet sein begrenztes Crawl-Budget für das Verfolgen von Weiterleitungen statt für das Crawlen tatsächlicher Inhalte
• Langsamere Seiten — jeder Sprung ist eine weitere Anfrage samt Roundtrip, bevor Inhalte laden, und ein Sprung zu einem anderen Host braucht zusätzlich eine neue Verbindung