Weiterleitungsfehler

Über diese Fehlerkategorie

# Weiterleitungsfehler

Weiterleitungsfehler treten auf, wenn eine Anfrage von einer URL an eine andere gesendet wird, aber nie eine endgültige Seite erreicht, oder wenn sie mehr Weiterleitungen durchläuft als nötig. Typische Symptome sind ERR_TOO_MANY_REDIRECTS, wiederholte Änderungen in der Adressleiste, ein Wechsel zwischen HTTP- und HTTPS-URLs oder eine Seite, die nach mehreren Weiterleitungen nicht geladen wird.

Weiterleitungen werden normalerweise für legitime Zwecke verwendet: zur Erzwingung von HTTPS, zur Auswahl eines bevorzugten Hostnamens, zum Verschieben einer alten URL oder zur Weiterleitung einer Anfrage an einen neuen Pfad. Ein Fehler tritt meist auf, wenn Weiterleitungsentscheidungen zwischen verschiedenen Ebenen widersprüchlich sind oder wenn ein zwischengespeicherter Zustand den Browser dazu bringt, ein veraltetes Ergebnis zu wiederholen.

Die wichtigsten Arten von Weiterleitungsfehlern

Weiterleitungsschleifen

Eine Weiterleitungsschleife entsteht, wenn die Abfolge schließlich zu einer URL zurückkehrt, die bereits angefordert wurde. Beispielsweise kann eine Regel HTTP zu HTTPS weiterleiten, während eine andere die HTTPS-Anfrage als unsicher behandelt und zurück zu HTTP sendet. Der Browser folgt diesem Zyklus, bis er abbricht und zu viele Weiterleitungen meldet.

Schleifen können auch zwischen Hostnamen, Varianten mit oder ohne abschließenden Schrägstrich, Pfaden oder einer Anwendungs-URL und einer Proxy-URL wechseln. In WordPress kann eine Schleife nach der Umstellung auf HTTPS beginnen, wenn WordPress Address, Site Address, die Force-SSL-Einstellung, die Proxy-Verarbeitung und die Serverweiterleitung nicht dieselbe öffentliche URL beschreiben. Weitere Informationen zu diesem speziellen Fall finden Sie unter [Too Many Redirects After Moving WordPress to HTTPS](/wordpress-too-many-redirects-https).

Lange Weiterleitungsketten

Eine Weiterleitungskette enthält mehrere aufeinanderfolgende Weiterleitungen, bevor die Anfrage ihr endgültiges Ziel erreicht. Eine alte URL kann zunächst zu einem geänderten Pfad, anschließend zu einem bevorzugten Hostnamen und schließlich zu HTTPS weiterleiten. Solche Ketten können durch mehrere Migrationen oder überlappende Regeln zurückbleiben.

Eine Kette unterscheidet sich von einer Schleife dadurch, dass sie schließlich eine endgültige Antwort erreicht. Sie kann die Navigation jedoch verlangsamen und verschleiern, welche Regel für das endgültige Ziel verantwortlich ist. Die entscheidende Diagnosefrage lautet, ob jede zwischenzeitliche Weiterleitung noch erforderlich ist.

Widersprüchliche Weiterleitungsregeln

Das Weiterleitungsverhalten kann durch einen Reverse Proxy oder ein CDN, eine Hosting-Plattform, einen Webserver, ein Content-Management-System, Anwendungscode oder ein Plugin gesteuert werden. Diese Ebenen können sich in folgenden Punkten widersprechen:

• Ob die ursprüngliche Anfrage HTTP oder HTTPS verwendet hat
• Welcher Hostname der kanonische ist
• Ob ein Pfad einen abschließenden Schrägstrich enthalten soll
• Ob ein alter Pfad umgeschrieben oder weitergeleitet werden soll
• Welche URL als endgültige Anwendungsadresse gelten soll

Ein Proxy kann vom Besucher HTTPS empfangen und eine Verbindung mit einem anderen Schema an den Origin-Server weiterleiten. Wenn die Anwendung das weitergeleitete Schema nicht korrekt interpretiert, kann sie eine weitere HTTPS-Weiterleitung ausgeben, obwohl der Besucher bereits HTTPS verwendet.

Verhalten durch zwischengespeicherte Weiterleitungen oder Cookies

Ein Test im privaten Browsermodus kann dabei helfen, browserspezifischen Zustand von einem gemeinsam genutzten Konfigurationsproblem zu unterscheiden. Cookies, zwischengespeicherte Antworten oder der Sitzungszustand der Anwendung können eine ältere Domain, einen alten Anmeldeablauf oder eine veraltete Protokollentscheidung beibehalten. Dies beweist nicht, dass die Serverkonfiguration korrekt ist; es zeigt lediglich, dass das Ergebnis vom gespeicherten Clientzustand abhängen kann.

Wenn dieselbe URL in mehreren Browsern und auf verschiedenen Geräten eine Schleife verursacht, sollten Sie die Weiterleitungsantworten und die gemeinsam genutzte Konfiguration priorisieren, anstatt wiederholt lokale Daten zu löschen.

So diagnostizieren Sie einen Weiterleitungsfehler

1. Start-URL und genaues Symptom dokumentieren. Notieren Sie Schema, Hostname, Pfad, abschließenden Schrägstrich, Browsermeldung und ob sich die Adresse wiederholt ändert.
2. Eine neue Browsersitzung testen. Verwenden Sie ein privates Fenster oder löschen Sie Cookies und zwischengespeicherte Daten der betroffenen Website. Vergleichen Sie das Ergebnis nach Möglichkeit mit einem anderen Browser oder Gerät.
3. Weiterleitungsverlauf verfolgen. Die Entwickler-Tools des Browsers oder ein Tool zur Untersuchung von HTTP-Headern können jede Antwort und ihr Location-Ziel anzeigen. Ermitteln Sie den bei jedem Schritt zurückgegebenen Status und achten Sie auf eine wiederholte URL, ein wechselndes Schema, einen wechselnden Hostnamen oder eine unnötige Zwischenadresse.
4. Muster klassifizieren. Eine wiederholte Adresse weist auf eine Schleife hin. Eine Abfolge, die mit einer Seite endet, ist eine Kette. Ein Wechsel zwischen HTTP und HTTPS deutet auf die Protokollverarbeitung hin; ein Wechsel zwischen Hostnamen oder Pfaden auf Regeln zur Kanonisierung oder Migration.
5. Einstellungen für die öffentliche URL prüfen. Stellen Sie sicher, dass die konfigurierte Site-URL der Anwendung mit dem Schema und Hostnamen übereinstimmt, den Besucher verwenden sollen. Vergleichen Sie in WordPress WordPress Address und Site Address, anstatt nur einen Wert zu ändern.
6. Weiterleitungsebenen von außen nach innen prüfen. Kontrollieren Sie CDN oder Reverse Proxy, Hosting-Einstellungen, Webserver-Regeln, Anwendungskonfiguration sowie Weiterleitungs- und SSL-Plugins. Prüfen Sie zuerst die Ebene, die die unerwartete Location-Antwort erzeugt hat.
7. Kürzlich vorgenommene Änderungen sorgfältig isolieren. Wenn das Problem nach der Aktivierung von HTTPS, einer Domainänderung, der Migration einer Website, der Bearbeitung von Permalinks oder der Installation eines Plugins begonnen hat, vergleichen Sie diese Änderungen mit der Weiterleitungsabfolge. Deaktivieren oder ändern Sie eine Regel nur, wenn Sie dazu berechtigt sind und die vorherige Konfiguration wiederherstellen können.
8. Ursprüngliche und endgültige URLs erneut testen. Verwenden Sie nach jeder kontrollierten Änderung eine neue Sitzung. Bestätigen Sie, dass die ursprüngliche URL das gewünschte Ziel erreicht und die endgültige URL nicht mehr unnötig weiterleitet.

Was Sie zuerst prüfen sollten

Der Fehler begann nach der Aktivierung von HTTPS

Beginnen Sie mit der Protokollverarbeitung. Prüfen Sie, wo HTTPS beendet wird, ob die Anwendung die erwarteten Informationen zur sicheren Anfrage erhält und ob mehr als eine Ebene HTTPS erzwingt. Suchen Sie nach einer Regel, die eine bereits sichere Anfrage zurück zu HTTP leitet oder die Anwendung dazu bringt, eine zweite HTTPS-Weiterleitung auszugeben.

Der Fehler begann nach einer Domain- oder Migrationsänderung

Vergleichen Sie alte und neue Hostnamen, das Schema, den Pfad sowie das Verhalten mit und ohne abschließenden Schrägstrich. Prüfen Sie Migrationsweiterleitungen und die URL-Einstellungen der Anwendung gemeinsam. Ein teilweise aktualisierter Hostname oder eine Weiterleitung, die weiterhin auf die alte Domain verweist, kann eine Schleife oder eine lange Kette erzeugen.

Nur ein Browser oder Benutzer ist betroffen

Testen Sie ohne Cookies und zwischengespeicherte Daten der betroffenen Website. Wenn das Problem verschwindet, untersuchen Sie den gespeicherten Sitzungs- oder Weiterleitungszustand, bevor Sie gemeinsam genutzte Serverregeln ändern. Wenn es in mehreren Browsern und auf verschiedenen Geräten bestehen bleibt, konzentrieren Sie sich auf die Antwort-Header und die gemeinsame Proxy-, Server- oder Anwendungskonfiguration.

Die Weiterleitungskette erreicht die Seite, ist aber ungewöhnlich lang

Listen Sie jede Zwischen-URL auf und ermitteln Sie, welche Regel sie eingeführt hat. Konsolidieren Sie veraltete Migrationsregeln, sofern dies sinnvoll ist. Bewahren Sie dabei beabsichtigte Weiterleitungen und prüfen Sie, dass alte URLs weiterhin das richtige endgültige Ziel erreichen.

Zu konsultierende Dokumentation der Anbieter

Für implementierungsspezifische Details sollten Sie die Dokumentation des beteiligten Webservers, Reverse Proxys oder CDNs, der Hosting-Plattform, des Content-Management-Systems sowie des Weiterleitungs- oder SSL-Plugins konsultieren. Suchen Sie dort nach HTTPS-Terminierung, weitergeleiteten Protokoll-Headern, Weiterleitungen zum kanonischen Host, der Priorität von Weiterleitungen und der Cache-Invalidierung. Die richtige Einstellung hängt davon ab, welche Ebene die ursprüngliche Anfrage empfängt und welche Ebene die einzelnen Weiterleitungen erzeugt.