Ein Redirect-Zyklus, ein wiederholter 301/302-URL-Ketten im Browser oder eine innerhalb NGINX umgeschriebene URI, wird aufgedeckt. Überprüfen Sie gemeinsam HTTPS, www, Reverse-Proxy, Anwendungs-URL und Rewrite-Flags.
2026/07/17 04:11:31 [error] 2418#2418: *1411 rewrite or internal redirection cycle while internally redirecting to "/index.php"
HTTP/2 301
location: https://example.com/
Der Browser steckt in einer Redirect-Schleife fest, bei der der Client zwischen URLs mit aufeinanderfolgenden 3xx-Antworten hin und her geht. Ein interner Redirect-Zyklus liegt vor, wenn NGINX dieselbe URI innerhalb von Location/Rewrite-Operationen erneut zuordnet.
Kanonische Redirects wie HTTP→HTTPS und www→non-www sollten in einer offenen Regel erfolgen. Wenn ein Serverblock www auf und eine Anwendung non-www auf www umleitet, tritt ein Endlosschleifen auf.
Die Anwendung hinter dem Reverse-Proxy kann das tatsächliche Client-Schema nicht sehen. Wenn X-Forwarded-Proto nicht korrekt weitergeleitet wird, kann die Anwendung den HTTPS-Anfrage auf HTTPS umleiten, als ob es sich um eine HTTP-Anfrage handelt.
Cloudflare Flexible SSL verwendet HTTPS zwischen dem Besucher und Cloudflare, aber HTTP zwischen Cloudflare und der Ursprung. Wenn die Ursprung eine erzwungene HTTPS-Umleitung hat, kann eine Schleife auftreten.
NGINX rewrite-Modul überprüft die Ortssuche erneut, wenn sich die URI ändert und ist durch einen Zyklus begrenzt. Ein falscher letzter, try_files- oder error_page-Ziel kann einen 500 internen Zyklusfehler verursachen.
301-Antworten können von Browsern und CDNs zwischengespeichert werden; bei Korrekturtests zunächst die Kette mit curl anzeigen und bei Bedarf temporäre 302 verwenden.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: Browser folgte einer großen Anzahl externer Umleitungen.
Mögliche Ursache: HTTP/HTTPS, www, Anwendung oder Proxy-Regeln konflikten.
Bedeutung: NGINX verarbeitet die gleiche URI wiederholt in internen Redirects.
Mögliche Ursache: Falsche rewrite last, try_files oder error_page-Ziel.
Bedeutung: Browser-Allgemein-Redirect-Schleifen-Nachricht.
Mögliche Ursache: Server, Anwendung, CDN- oder Cookie-basierte Umleitung.
Bedeutung: Dauerhafte Umleitung erzeugt zwei gegenseitige URLs.
Mögliche Ursache: www/non-www oder Slash-Politik-Konflikt.
Bedeutung: Origin und Proxy-Schema-Informationen passen nicht zusammen.
Mögliche Ursache: X-Forwarded-Proto fehlt oder Flexible SSL.
Bedeutung: Die Fehlerseite reproduziert denselben Fehler selbst.
Mögliche Ursache: error_page-Ziel ist nicht verfügbar oder leitet auf dieselbe Location um.
Bedeutung: WordPress home/siteurl ist von NGINX-Kanonikum verschieden.
Mögliche Ursache: HTTP/HTTPS- oder www-Inkompatibilität.
Bedeutung: Browser upgradet HTTP ohne Zugriff auf NGINX zu HTTPS.
Mögliche Ursache: Vorab gesendete HSTS-Politik.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
curl -skIL --max-redirs 15 https://example.com/ | grep -Ei 'HTTP/|location:'
Zeigt jeden 3xx-Schritt und die Ziel-URL an.
nginx -T | grep -nE 'server_name|return 30[1278]|rewrite |try_files|error_page|X-Forwarded-Proto'
Es listet die wirksamen Direktiven, die einen Loop erstellen können.
curl -skI https://example.com/
curl -skI --resolve example.com:443:ORIGIN_IP https://example.com/
Trennt die CDN- oder Reverse-Proxy-Schicht.
grep -R 'rewrite or internal redirection cycle' /var/log/nginx 2>/dev/null | tail -n 50
Internes Zyklus findet Ziel und Anfrage.
wp option get home --path=/var/www/example
wp option get siteurl --path=/var/www/example
Die Anwendung vergleicht die kanonische URL mit NGINX.
nginx -t && systemctl reload nginx
curl -skIL --max-redirs 10 https://example.com/
Nach der Korrektur wird die Beendigung der Kette bestätigt.
Obwohl die Grundursache des NGINX-Fehlers dieselbe ist, variieren Paketpfade, Dienstnamen, Sicherheitsebenen und die Verwaltung virtueller Hosts je nach verwendeter Linux-Distribution oder Plesk-Infrastruktur.
NGINX Too Many Redirects-Lösung für Systemd, Paketpfad und Journald-Prüfunglen
curl -skIL --max-redirs 15 https://example.com/
nginx -T | grep -nE 'return 30|rewrite |X-Forwarded-Proto'NGINX Too Many Redirects-Lösung für SELinux, PHP-FPM-Pool und RHEL-basierte Dienstkontrollen
curl -skIL --max-redirs 15 https://example.com/
nginx -T | grep -nE 'return 30|rewrite |X-Forwarded-Proto'NGINX virtuelle Host-Dateien von Plesk generiert: Überprüfung von nginx-Weiterleitungen.
grep -R 'return 30\|rewrite ' /var/www/vhosts/system/example.com/conf 2>/dev/null
plesk repair web example.com -nUnterscheiden Sie das Problem mit dem internen NGINX-Zyklus vom externen 3xx-Ketten und erstellen Sie eine einzelne kanonische URL und eine korrekte Proxy-Schaltung.
Jede 301/302-URLs Quelle und Ziel-URL aufzeichnen.
curl -skIL --max-redirs 15 https://example.com/ | grep -Ei 'HTTP/|location:'Finden Sie, wo der Loop startet, indem Sie eine direkte Anforderung an den Origin-IP senden.
curl -skIL --resolve example.com:443:ORIGIN_IP https://example.com/Die HTTPS- und www-Voreinstellung soll nur in einem einzelnen offenen Serverblock angewendet werden.
nginx -T | grep -nE 'server_name|return 30'Die Backend-Anwendung sollte das korrekte Client-Schema sehen.
nginx -T | grep -n 'X-Forwarded-Proto'Bestätigen Sie, dass try_files, error_page und rewrite-letzte Ziele nicht auf dieselbe Location gerichtet werden.
grep 'redirection cycle' /var/log/nginx/error.log | tail -n 20Curl, verstecktes Fenster und CDN-Cache-Löschung werden verwendet, um die Kette zu überprüfen, wenn erforderlich.
nginx -t && systemctl reload nginx
curl -skIL --max-redirs 10 https://example.com/Origin-Schema und X-Forwarded-Proto passen nicht zusammen.
curl -sIL http://example.com/; curl -skIL https://example.com/Die Anwendung kann mit NGINX einen anderen kanonischen Host auswählen.
curl -skI https://www.example.com/; curl -skI https://example.com/Wenn der HTTPS-Origin zwingend ist, ist eine Übergang in den Voll/Strikten Modus und eine Zertifikatsüberprüfung erforderlich.
Vergleichen Sie die Location-Werte der Origin- und Cloudflare-Anfragen.home/siteurl, SSL Proxy-Header und Cookie-Domain werden überprüft.
wp option get home; wp option get siteurlrewrite last, try_files oder error_page leiten den gleichen URI um.
grep 'redirection cycle' /var/log/nginx/error.log | tailDie Anwendung kann mit der trailing-Slash-Politik von NGINX kollidieren.
curl -skIL https://example.com/yol; curl -skIL https://example.com/yol/Dies tritt aufgrund der gegenseitig widersprüchlichen Richtlinien in verschiedenen Schichten auf.
Nein. Der interne Zyklus NGINX ist die URI-Wiederholverarbeitung innerhalb NGINX; der Browser-Loop ist eine sequentielle 3xx-Antwort, die auf der Client-Seite gesehen wird.
Flexible SSL sieht Ursprung HTTP, während Ursprung auf HTTPS umleitet, Cloudflare verbindet sich erneut mit HTTP und eine Schleife kann auftreten.
Reverse proxy, sendet dem Client das ursprüngliche HTTP/HTTPS-Schema an die Backend-Anwendung; andernfalls kann die Anwendung unnötige HTTPS-Redirects erzeugen.
Mit curl die Header-Kette untersuchen, einen privaten Browser verwenden und falls erforderlich den CDN-Cache löschen. Ein temporärer 302 ist während der Testphase sicherer.
home/siteurl, Proxy-SSL-Kopfzeile, www-Präferenz und NGINX-HTTPS-Weiterleitung sollten auf die gleiche kanonische URL abgestimmt werden.
Especially wenn die URI sich ändert, aber immer noch demselben Location- und Rewrite-Regel entspricht, kann ein Loop auftreten; break oder return könnten hier besser geeignet sein.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.