Arama Yap Mesaj Senden
Rückruf anfordern
+90
X
X

Wählen Sie Ihre Währung

Türkische Lira $ US Dollar Euro
X
X

Wählen Sie Ihre Währung

Türkische Lira $ US Dollar Euro

Kontaktieren Sie uns

Standort Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Technischer Leitfaden für NGINX

NGINX-Hoch-Redirect- und -Internal-Redirect-Zyklus-Fehler

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.

ERR_TOO_MANY_REDIRECTSRewrite CycleHTTPSX-Forwarded-ProtoCloudflare
root@server:~SSH
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/
AnforderungsflussClient, NGINX und Backend-Verbindungsbrempunkt
KonfigurationValidierung der aktiven Server- und Location-Blöcke
Live-DiagnoseLog, Socket, Port- und Dienstkontrolle
Sichere AnwendungTest, kontrollierter Reload und Ergebnisvalidierung
01
Technische Beschreibung

Was bedeutet der NGINX-Redirect-Zyklus?

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.

02
Protokollmeldungen und ihre Bedeutung

Redirect-Loop- und internen Zyklus-Nachrichten

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.

8 Registrierung
01kritik

ERR_TOO_MANY_REDIRECTS

Bedeutung: Browser folgte einer großen Anzahl externer Umleitungen.

Mögliche Ursache: HTTP/HTTPS, www, Anwendung oder Proxy-Regeln konflikten.

Verwenden Sie curl -IL, um die Location-Kette zu extrahieren.
02kritik

rewrite or internal redirection cycle

Bedeutung: NGINX verarbeitet die gleiche URI wiederholt in internen Redirects.

Mögliche Ursache: Falsche rewrite last, try_files oder error_page-Ziel.

Im Log den Ziel-URI und die damit verbundenen Location-Blöcke untersuchen.
03Warnung

redirected you too many times

Bedeutung: Browser-Allgemein-Redirect-Schleifen-Nachricht.

Mögliche Ursache: Server, Anwendung, CDN- oder Cookie-basierte Umleitung.

Überprüfen Sie die serverseitige Kette mit cookie-losem curl.
04Warnung

301 Moved Permanently loop

Bedeutung: Dauerhafte Umleitung erzeugt zwei gegenseitige URLs.

Mögliche Ursache: www/non-www oder Slash-Politik-Konflikt.

Notieren Sie den Location-Wert für jeden Schritt.
05Warnung

HTTP to HTTPS redirect loop

Bedeutung: Origin und Proxy-Schema-Informationen passen nicht zusammen.

Mögliche Ursache: X-Forwarded-Proto fehlt oder Flexible SSL.

Bestätigen Sie die von Origin empfangenen Header und den CDN-SSL-Modus.
06bilgi

cycle while processing error page

Bedeutung: Die Fehlerseite reproduziert denselben Fehler selbst.

Mögliche Ursache: error_page-Ziel ist nicht verfügbar oder leitet auf dieselbe Location um.

Testen Sie die URI der Fehlerseite unabhängig.
07bilgi

WordPress too many redirects

Bedeutung: WordPress home/siteurl ist von NGINX-Kanonikum verschieden.

Mögliche Ursache: HTTP/HTTPS- oder www-Inkompatibilität.

Datenbank-URLs und Proxy-Header vergleichen.
08bilgi

Immer HTTPS aufgrund von HSTS

Bedeutung: Browser upgradet HTTP ohne Zugriff auf NGINX zu HTTPS.

Mögliche Ursache: Vorab gesendete HSTS-Politik.

Verwenden Sie curl und isolieren Sie die Serververhalten mit einem anderen Hostnamen.

Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.

03
Sichere erste Bewertung

SSH-Diagnosebefehle und auf welche Ausgabe ist zu achten?

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.

Routenverfolgungskette
curl -skIL --max-redirs 15 https://example.com/ | grep -Ei 'HTTP/|location:'

Zeigt jeden 3xx-Schritt und die Ziel-URL an.

Rewrite- und return-Regeln
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.

Origin/Proxy-Vergleich
curl -skI https://example.com/
curl -skI --resolve example.com:443:ORIGIN_IP https://example.com/

Trennt die CDN- oder Reverse-Proxy-Schicht.

Rewrite logu
grep -R 'rewrite or internal redirection cycle' /var/log/nginx 2>/dev/null | tail -n 50

Internes Zyklus findet Ziel und Anfrage.

WordPress-URL-Überprüfung
wp option get home --path=/var/www/example
wp option get siteurl --path=/var/www/example

Die Anwendung vergleicht die kanonische URL mit NGINX.

Test und reload
nginx -t && systemctl reload nginx
curl -skIL --max-redirs 10 https://example.com/

Nach der Korrektur wird die Beendigung der Kette bestätigt.

04
Durch Hosting-Umgebung

Ubuntu/Debian-, AlmaLinux/CloudLinux- und Plesk-Steuerelemente

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.

Ubuntu / Debian

NGINX Too Many Redirects-Lösung für Systemd, Paketpfad und Journald-Prüfunglen

  • Zuerst die aktive NGINX-Konfiguration und den Status des Dienstes überprüfen.
  • Vergleichen Sie das Domain-Fehler-Log mit dem systemd-Log im gleichen Zeitraum.
  • Führen Sie vor der Änderung nginx -t und anschließend ein unterbrechungsfreies Neuladen durch.
curl -skIL --max-redirs 15 https://example.com/ nginx -T | grep -nE 'return 30|rewrite |X-Forwarded-Proto'

AlmaLinux / CloudLinux

NGINX Too Many Redirects-Lösung für SELinux, PHP-FPM-Pool und RHEL-basierte Dienstkontrollen

  • Überprüfen Sie den aktiven Status von NGINX und den damit verbundenen Backend-Diensten.
  • Überprüfen Sie SELinux-ACV-Einträge und Sicherheitskontexte.
  • Starten Sie den Service nicht ohne die Konfigurationsprüfung durchzuführen.
curl -skIL --max-redirs 15 https://example.com/ nginx -T | grep -nE 'return 30|rewrite |X-Forwarded-Proto'

Plesk Obsidian

NGINX virtuelle Host-Dateien von Plesk generiert: Überprüfung von nginx-Weiterleitungen.

  • Überprüfen Sie die zusätzlichen Direktiven im Abschnitt Domains > Apache- und nginx-Einstellungen.
  • Manuell erstellte und von Plesk generierte Dateien voneinander trennen.
  • Wenn nötig, erstellen Sie die Web-Konfiguration für die relevante Domain nur neu.
grep -R 'return 30\|rewrite ' /var/www/vhosts/system/example.com/conf 2>/dev/null plesk repair web example.com -n
05
Sichere Lösungsreihenfolge

NGINX Redirect-Loop-Lösungssequenz

Unterscheiden Sie das Problem mit dem internen NGINX-Zyklus vom externen 3xx-Ketten und erstellen Sie eine einzelne kanonische URL und eine korrekte Proxy-Schaltung.

1

Entfernen Sie die Location-Kette.

Jede 301/302-URLs Quelle und Ziel-URL aufzeichnen.

curl -skIL --max-redirs 15 https://example.com/ | grep -Ei 'HTTP/|location:'
2

Trennen Sie die CDN/Proxy-Schicht

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/
3

Wählen Sie eine einzelne kanonische Struktur und einen Host aus.

Die HTTPS- und www-Voreinstellung soll nur in einem einzelnen offenen Serverblock angewendet werden.

nginx -T | grep -nE 'server_name|return 30'
4

Überprüfen Sie die forwarded Proto-Information.

Die Backend-Anwendung sollte das korrekte Client-Schema sehen.

nginx -T | grep -n 'X-Forwarded-Proto'
5

Internes Zyklusregel überprüfen.

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 20
6

Löschen Sie den Cache-Effekt und testen Sie erneut

Curl, 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/
06
Unterscheidung nach Symptom

Spezielle Szenarien und Entscheidungsbäume

Schleife zwischen HTTP und HTTPS

Origin-Schema und X-Forwarded-Proto passen nicht zusammen.

curl -sIL http://example.com/; curl -skIL https://example.com/
www- und non-www-Schleife

Die Anwendung kann mit NGINX einen anderen kanonischen Host auswählen.

curl -skI https://www.example.com/; curl -skI https://example.com/
Cloudflare Flexible SSL

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.
WordPress Anmelde-Schleife

home/siteurl, SSL Proxy-Header und Cookie-Domain werden überprüft.

wp option get home; wp option get siteurl
Internal redirection cycle

rewrite last, try_files oder error_page leiten den gleichen URI um.

grep 'redirection cycle' /var/log/nginx/error.log | tail
Schlitz-Additionsentfernung-Schleife

Die Anwendung kann mit der trailing-Slash-Politik von NGINX kollidieren.

curl -skIL https://example.com/yol; curl -skIL https://example.com/yol/

Auf keinen Fall

  • Bewährte 301 ohne Bestätigung nicht auf die Produktionsumgebung anwenden.
  • Ignorieren Sie die Ursprungs-HTTPS-Schleife nicht, wenn Cloudflare Flexible SSL verwendet wird.
  • Verwenden Sie die if-Direktiven nicht zufällig für komplexe Umleitungsketten.
  • Ermöglichen Sie es der Anwendung und NGINX nicht, denselben kanonischen Regel zweimal anzuwenden.
  • Löschen Sie Ihren Browser-Cache und stellen Sie die Ergebnisse nicht ohne Messung der Kette mit curl bereit.

Überprüfung nach der Lösung

  • HTTP/HTTPS und www-Präferenz gehen in einem Schritt zur kanonischen URL.
  • Die cURL-Kette erreicht in wenigen Schritten höchstens einen 2xx/3xx-Status.
  • Es gibt in der NGINX-Protokolldatei keine neue interne Umleitungszyklus.
  • Die Anwendung erkennt den realen Client-Schema korrekt.
  • Echte 404- und error_page-Ziele erzeugen keine Schleifen.
07
Offizielle technische Ressourcen

Offizielle Dokumentation von NGINX und zugehörigen Komponenten

08
Interner SEO-Inhaltssatz

Verwandte NGINX-Fehlerlösungen

09
Häufig gestellte Fragen

NGINX Too Many Redirects Kuriositäten über

NGINX ERR_TOO_MANY_REDIRECTS warum?

Dies tritt aufgrund der gegenseitig widersprüchlichen Richtlinien in verschiedenen Schichten auf.

Ist der Browser-Zyklus der gleiche wie der interne Umleitungszyklus?

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.

Warum verursacht Cloudflare einen Redirect-Loop?

Flexible SSL sieht Ursprung HTTP, während Ursprung auf HTTPS umleitet, Cloudflare verbindet sich erneut mit HTTP und eine Schleife kann auftreten.

Was tut X-Forwarded-Proto?

Reverse proxy, sendet dem Client das ursprüngliche HTTP/HTTPS-Schema an die Backend-Anwendung; andernfalls kann die Anwendung unnötige HTTPS-Redirects erzeugen.

Wie wird der 301-Cache getestet?

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.

Wie behebt man WordPress too many redirects?

home/siteurl, Proxy-SSL-Kopfzeile, www-Präferenz und NGINX-HTTPS-Weiterleitung sollten auf die gleiche kanonische URL abgestimmt werden.

wann macht der rewrite last-Schleife Halt?

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.

EKA SOFTWARE- UND INFORMATIONSSYSTEME

Lassen Sie uns den Fehler auf Ihrem Server dauerhaft beheben

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.

Holen Sie sich Server-Support WhatsApp
Top