HTTP 405 Method Not Allowed: Bedeutung und Behebung

Was dieser Fehler bedeutet und wie du ihn erkennst

• Ein Browser, API-Client, Monitoring-Tool oder Checker erhält 405 Method Not Allowed.
• Eine HTTP-Methode schlägt fehl, während eine andere Methode für dieselbe Route möglicherweise funktioniert.
• Das Problem kann eine einzelne URL, ein Routenmuster, einen Client oder ein Deployment betreffen und nicht die gesamte Website.
• Die Response kann einen Allow-Header enthalten, der zulässige Methoden auflistet.
• Andere Header können Informationen zu Redirects, Caching, Authentifizierung, Proxy, CDN oder Server liefern.
• Da eine HTTP-Response empfangen wurde, können DNS-Auflösung und TLS-Aushandlung bereits erfolgreich gewesen sein. Das beweist jedoch nicht, dass die Anwendung oder Route korrekt konfiguriert ist.

Hauptursachen nach Wahrscheinlichkeit

Häufige Ursachen

1. Die Methode wird von der Route nicht unterstützt. Der Endpoint akzeptiert möglicherweise GET, lehnt aber POST ab – oder akzeptiert POST, lehnt jedoch eine Update-Methode wie PUT oder PATCH ab.
2. Routing- oder Webserver-Regeln lehnen die Methode ab. Eine Route, ein Virtual Host oder eine Serverrichtlinie leitet die Anfrage möglicherweise nicht an den vorgesehenen Handler weiter.
3. Ein Reverse Proxy, CDN oder WAF gibt die Response zuerst zurück. Ein Intermediär kann Methodenbeschränkungen anwenden oder die Anfrage anders weiterleiten als die Origin.
4. Die Anfrage entspricht nicht dem Anwendungskontrakt. Pfad, abschließender Schrägstrich, Content-Type, Host, Authentifizierungsstatus oder andere Request-Details können eine andere Route oder Validierungsregel auswählen.
5. Ein kürzlich erfolgtes Deployment oder eine Konfigurationsänderung hat eine Abweichung verursacht. Anwendungsrouten, Proxy-Regeln, zulässige Methoden und Caching-Verhalten stimmen möglicherweise nicht mehr überein.
6. Eine beabsichtigte Richtlinie oder das Endpoint-Design. Manche Ressourcen lehnen Methoden absichtlich ab, weil sie unsicher, nicht unterstützt oder nicht Teil ihrer dokumentierten Schnittstelle sind.

Der Statuscode allein kann nicht bestimmen, welche Schicht oder Regel die Response verursacht hat. Bestätigen Sie Methode, Header, Logs und kürzliche Änderungen, bevor Sie das System verändern.

So behebst du den Fehler

Wenn Sie Besucher oder API-Nutzer sind

1. Bestätigen Sie die genaue URL und ob der Client die beabsichtigte Methode sendet. Eine Anfrage über die Adressleiste eines Browsers verwendet normalerweise GET, während ein API-Client POST, PUT, PATCH, DELETE oder eine andere Methode verwenden kann.
2. Prüfen Sie die Response-Header auf einen Allow-Header sowie auf Informationen zu Redirects, Authentifizierung, Caching oder Proxy. Verwenden Sie eine andere Methode nur dann als Workaround, wenn die Website- oder API-Dokumentation diese unterstützt.
3. Wenn der Endpoint ein Konto erfordert, melden Sie sich über den normalen Prozess an und versuchen Sie es erneut, ohne Zugangsdaten in einer Support-Anfrage offenzulegen.
4. Vermeiden Sie wiederholte Versuche, wenn der Dienst gleichzeitig Rate-Limits, Timeouts oder Überlastungssymptome meldet.
5. Wenn das Problem bestehen bleibt, senden Sie dem Website-Betreiber URL, Methode, Zeitstempel, Statuscode und relevante bereinigte Header. Teilen Sie keine Passwörter, Cookies, Authorization-Tokens oder API-Secrets.

Wenn Sie die Website betreiben oder verwalten

1. Erstellen Sie eine minimale Reproduktion. Erfassen Sie die genaue Methode, URL, den Host, Request-Pfad, Status und relevante Response-Header. Bewahren Sie den Request-Body nur auf, wenn er keine Secrets oder personenbezogenen Daten enthält.
2. Prüfen Sie, ob die Response beabsichtigt ist. Vergleichen Sie die Anfrage mit dem Routen- oder API-Kontrakt. Ermitteln Sie, ob die Ressource diese Methode unterstützen soll und ob ein Allow-Header akzeptierte Methoden nennt.
3. Ermitteln Sie die antwortende Schicht. Verwenden Sie Response-Header, Request-IDs und Zeitstempel, um festzustellen, ob die Response von der Anwendung, dem Webserver, Reverse Proxy, CDN oder WAF stammt. Eine von einem Proxy erzeugte Response erreicht die Origin möglicherweise nie.
4. Prüfen Sie passende Logs. Suchen Sie in der ermittelten Schicht und, sofern verfügbar, in der Upstream-Schicht nach demselben Zeitstempel, Pfad, derselben Methode und Request-ID. Achten Sie auf Routenabweichungen, Methodenfilter, abgelehnte Upstream-Anfragen und kürzliche Richtlinienänderungen.
5. Vergleichen Sie kürzliche Änderungen. Prüfen Sie Deployments, Routendefinitionen, Webserver-Regeln, das Verhalten von Proxy oder CDN, die Authentifizierungskonfiguration und WAF-Richtlinien. Vergleichen Sie eine fehlschlagende Methode mit einer bekanntermaßen unterstützten Methode für dieselbe Route.
6. Nehmen Sie die kleinste autorisierte Korrektur vor. Aktualisieren Sie nur die Route oder Regel, die die Methode unterstützen soll. Deaktivieren Sie nicht pauschal Authentifizierung, WAF-Schutz oder Methodenbeschränkungen, nur damit der Fehler verschwindet.
7. Testen Sie sicher erneut. Wiederholen Sie dieselbe Anfrage möglichst in einer Nicht-Produktionsumgebung und testen Sie anschließend die betroffene Produktionsroute im Rahmen des genehmigten Änderungsprozesses. Bestätigen Sie, dass nicht unterstützte Methoden weiterhin abgelehnt werden und verbundene Routen weiterhin ihre vorgesehenen Statuscodes zurückgeben.
8. Prüfen Sie Caches und Intermediäre. Wenn sich das Verhalten zwischen Clients oder Standorten unterscheidet, prüfen Sie, ob ein Proxy oder CDN die Response zwischengespeichert oder eine separate Regel anwendet. Leeren oder ändern Sie das Cache-Verhalten nur gemäß dem normalen Betriebsverfahren des Dienstes.

Vorbeugung und Überprüfung der Lösung

• Definieren und dokumentieren Sie die unterstützten Methoden für wichtige Webrouten und API-Endpoints.
• Testen Sie repräsentative Methoden für kritische Routen nach Änderungen an Anwendung, Server, Proxy, CDN oder WAF.
• Überwachen Sie Statuscode-Raten nach Route und Methode, statt alle 4xx-Responses als eine Gruppe zu behandeln.
• Halten Sie Routing, Methodenbeschränkungen, Authentifizierung und Proxy-Konfiguration unter Versionskontrolle.
• Bewahren Sie Request-IDs und Logs über Intermediär- und Origin-Schichten hinweg lange genug auf, um Fehler zu korrelieren.
• Dokumentieren Sie beabsichtigte 405-Responses, damit Support- und Monitoring-Teams erwartetes Verhalten von Regressionen unterscheiden können.
• Vermeiden Sie weitreichende Methodenfreigaben. Erlauben Sie nur die Methoden, die von der jeweiligen Ressource und dem Anwendungskontrakt benötigt werden.

Häufig gestellte Fragen