HTTP 301 Moved Permanently: Was es bedeutet

Was dieser Fehler bedeutet und wie du ihn erkennst

• Ein Browser, API-Client, Monitoring-Dienst oder HTTP-Checker meldet 301 Moved Permanently.
• Ein Browser folgt der Weiterleitung möglicherweise automatisch, zeigt eine andere URL an oder meldet eine Weiterleitungsschleife, wenn das Ziel zurück zur ursprünglichen URL führt.
• Die Antwort kann einen Location-Header enthalten, der das Weiterleitungsziel angibt.
• Das Verhalten kann nur bei einer bestimmten URL, einem Hostnamen, einer HTTP-Methode, einem Authentifizierungsstatus, einem User-Agent oder einem Netzwerkpfad auftreten.
• DNS kann erfolgreich aufgelöst werden und TLS kann erfolgreich abgeschlossen werden, weil der Endpunkt eine HTTP-Antwort zurückgegeben hat.
• API-Clients oder automatisierte Tools brechen möglicherweise bei der 301-Antwort ab, anstatt ihr zu folgen – abhängig von ihren Weiterleitungseinstellungen.

Hauptursachen nach Wahrscheinlichkeit

1. Beabsichtigte URL-Kanonisierung: Die Website leitet einen alternativen Hostnamen, Pfad, eine Variante mit oder ohne abschließenden Schrägstrich oder eine andere URL-Variante auf die bevorzugte Adresse weiter.
2. Protokoll- oder Hostnamenmigration: HTTP-Datenverkehr kann auf HTTPS weitergeleitet werden, oder ein alter Hostname kann auf einen Ersatz-Hostname verweisen.
3. Application Routing oder Framework-Routing: Die Anwendung kann eine Route nach einer Pfadänderung, einer Änderung des Login-Status oder der Verschiebung einer Ressource weiterleiten.
4. Regeln des Webservers, Reverse Proxys oder CDNs: Die Infrastrukturkonfiguration kann eine Weiterleitung anwenden, bevor die Anfrage die Anwendung erreicht.
5. Zwischengespeichertes Weiterleitungsverhalten: Ein Browser, ein zwischengeschalteter Cache oder ein CDN liefert möglicherweise weiterhin eine zuvor zwischengespeicherte Weiterleitung aus, während sich Konfigurationsänderungen verbreiten.
6. Methodenabhängiges Verhalten: Eine Weiterleitungsregel kann für die Navigation im Browser geeignet, für eine API-Anfrage oder eine Methode, deren Request-Semantik erhalten bleiben muss, jedoch ungeeignet sein.
7. Unerwartete oder widersprüchliche Regeln: Mehrere Ebenen können auf unterschiedliche Ziele weiterleiten und dadurch eine Kette oder Schleife erzeugen.

So behebst du den Fehler

Wenn Sie die Website besuchen

1. Prüfen Sie die genaue Adresse einschließlich Hostname, Pfad und Protokoll. Folgen Sie der Weiterleitung nur, wenn das Ziel vertraut und erwartet ist.
2. Wenn das Ziel ein Konto erfordert, melden Sie sich über die normale Benutzeroberfläche der Website an und versuchen Sie es erneut. Geben Sie keine Zugangsdaten an eine unbekannte weitergeleitete Domain weiter.
3. Wenn ein Browser die vorgesehene Seite erreicht, funktioniert die 301 möglicherweise wie vorgesehen. Wenn eine Schleife entsteht, die Weiterleitung beim falschen Host endet oder eine fehlende Seite angezeigt wird, notieren Sie die ursprüngliche URL und das Ziel.
4. Prüfen Sie bei einer API oder einem automatisierten Client, ob dieser Weiterleitungen folgt und ob die weitergeleitete URL für dieselbe Request-Methode und denselben Authentifizierungskontext gültig ist.
5. Melden Sie dem Website-Betreiber die ursprüngliche URL, das Ziel, den ungefähren Zeitpunkt, den Client-Typ und den beobachteten Status. Teilen Sie keine Passwörter, Cookies oder API-Secrets.

Wenn Sie die Website besitzen oder betreuen

1. Reproduzieren Sie die exakte Anfrage. Notieren Sie die HTTP-Methode, die vollständige URL, den Host, das Protokoll, den Authentifizierungsstatus (falls relevant), den finalen Status und jedes Weiterleitungsziel.
2. Prüfen Sie die Response-Header, insbesondere Location, Cache-bezogene Header, Authentifizierungs-Header sowie Header, die eine Proxy- oder Server-Ebene identifizieren.
3. Ermitteln Sie, welche Komponente den 301 erzeugt hat: Anwendung, Webserver, Reverse Proxy, CDN oder WAF. Prüfen Sie die zugehörigen Logs anhand des Zeitstempels und – falls verfügbar – einer Request-ID.
4. Vergleichen Sie das Verhalten mit dem vorgesehenen Routing-Design. Bestätigen Sie, ob die Weiterleitung eine Hostnamenänderung, eine HTTP-zu-HTTPS-Richtlinie, einen kanonischen Pfad, eine verschobene Ressource oder einen Anwendungsablauf behandeln soll.
5. Prüfen Sie Weiterleitungsketten, Schleifen, widersprüchliche Regeln und ein falsches Ziel. Überprüfen Sie kürzlich erfolgte Deployments sowie Änderungen am Routing, an der Authentifizierung, am Caching, an der Proxy- oder CDN-Konfiguration.
6. Nehmen Sie die kleinstmögliche autorisierte Korrektur auf der Ebene vor, die die Antwort erzeugt hat. Vermeiden Sie umfassende Änderungen an Berechtigungen, Sicherheit oder Weiterleitungsregeln, wenn nur eine Route oder Bedingung fehlerhaft ist.
7. Testen Sie dieselbe URL und Methode erneut mit einem geeigneten Client. Testen Sie anschließend das Ziel, wichtige zugehörige Routen sowie relevante authentifizierte und nicht authentifizierte Fälle.
8. Wenn ein zwischengespeicherter Redirect vermutet wird, befolgen Sie den freigegebenen Prozess zur Cache-Invalidierung und berücksichtigen Sie dessen betriebliche Auswirkungen, bevor Sie diese Änderung vornehmen.

Vorbeugung und Überprüfung der Lösung

• Definieren und dokumentieren Sie beabsichtigte Weiterleitungen einschließlich alter URLs, Ziele, betroffener Methoden und Zuständigkeiten.
• Halten Sie Regeln für Webserver, Anwendung, Reverse Proxy, CDN und WAF – sofern unterstützt – unter Versionskontrolle.
• Testen Sie nach Releases kanonische URLs, das Verhalten von HTTP zu HTTPS, Hostnamenänderungen, wichtige API-Methoden und authentifizierte Routen.
• Überwachen Sie Weiterleitungsraten, Ketten und Schleifen nach Route und Deployment, anstatt jeden 301 als Ausfall zu behandeln.
• Halten Sie Request- und Infrastruktur-Logs lange genug verfügbar, um unerwartete Weiterleitungen zu korrelieren.
• Prüfen Sie das Cache-Verhalten, wenn Sie Weiterleitungsregeln ändern, damit veraltete Antworten das Ergebnis einer Korrektur nicht verschleiern.

Häufig gestellte Fragen