405 Method Not Allowed: Bedeutung und so behebst du den Fehler

Was ist der Fehler 405 Method Not Allowed?

405 Method Not Allowed ist ein HTTP-Statuscode und bedeutet, dass der Server die angefragte Adresse kennt, aber die Methode nicht zulässt, die deine Anfrage verwendet hat. RFC 9110 (Abschnitt 15.5.6) definiert ihn so, dass die Methode „dem Origin-Server bekannt ist, von der Zielressource aber nicht unterstützt wird“.

Jede HTTP-Anfrage hat eine Methode: GET, um eine Seite zu lesen, POST, um ein Formular abzuschicken oder etwas anzulegen, PUT und PATCH zum Aktualisieren, DELETE zum Löschen und OPTIONS, um zu fragen, was erlaubt ist. Ein 405 bedeutet: Die URL existiert, aber nicht für dieses Verb. Gäbe es die URL gar nicht, bekämst du stattdessen einen 404.

Weil es darum geht, wie eine Anfrage gestellt wurde, und nicht um eine fehlende Seite, muss ein 405 fast immer der Entwickler der Website beheben. Besucher stoßen meist darauf, nachdem sie ein Formular abgeschickt haben oder einem veralteten Link gefolgt sind.

So sieht ein 405-Fehler aus

Schritt 1: Lies den Allow-Header

Frag den Server, welche Methoden er für diese URL akzeptiert. Sende entweder eine OPTIONS-Anfrage oder wiederhole die fehlgeschlagene Anfrage mit angezeigten Headern:

# Welche Methoden akzeptiert diese URL?
curl -i -X OPTIONS https://example.com/api/contact

# Fehlgeschlagene Anfrage wiederholen und auf Status und Allow-Header achten
curl -i -X POST https://example.com/api/contact -d 'name=test'
# HTTP/2 405
# allow: GET, HEAD

Das Tool HTTP-Headers von DNS Robot zeigt den Statuscode und die Header, die eine URL auf eine normale GET-Anfrage zurückgibt. Das hilft, wenn du eine Seite im Browser prüfst und nicht eine API.

Nicht jeder Server hält sich an die Regel. Die eingebaute 405-Seite von nginx wird zum Beispiel ohne Allow-Header gesendet. Unter nginx musst du deshalb stattdessen prüfen, welcher location-Block die URL verarbeitet (Lösung 2).

Wenn du Besucher bist

• Geh zurück und lade die Seite neu, dann schick das Formular noch einmal ab. Ein Formular aus einer alten, zwischengespeicherten Kopie kann an eine Adresse senden, die sich inzwischen geändert hat.

• Nach dem Abschicken nicht neu laden. Lädst du eine Seite neu, die das Ergebnis eines Formulars ist, kann das einen POST erneut an eine URL senden, die nur GET akzeptiert.

• Prüfe die Adresse auf Tippfehler oder öffne die Startseite der Website und navigiere erneut.

• Melde es. Scheitert ein Formular auf der Seite immer, muss der Betreiber das beheben – schick ihm die Adresse der Seite.

Lösung 1: Die richtige Methode an die richtige URL senden

Die häufigste Ursache im Code ist schlicht ein Missverhältnis: Ein Formular oder ein fetch()-Aufruf nutzt POST, während der Endpunkt nur GET akzeptiert, oder die Anfrage geht an die Seiten-URL statt an die API-URL. Vergleiche die Methode in deinem Code mit dem Allow-Header und der Dokumentation der API.

// Der Endpunkt erlaubt nur POST, ein GET (Standard bei fetch) liefert also 405
const res = await fetch("/api/contact", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ name: "Ana" }),
})
if (res.status === 405) console.log("Allowed:", res.headers.get("allow"))

Lösung 2: nginx liefert 405 bei POST an statische Dateien

Der Handler für statische Dateien in nginx bedient nur GET und HEAD. Ein POST an eine .html-Datei oder an eine location, die Dateien ausliefert, statt die Anfrage an deine Anwendung weiterzugeben, bekommt 405 Not Allowed. Das passiert oft, wenn die action eines Formulars auf eine statische Seite zeigt oder ein location-Block für deine App nicht greift.

Die eigentliche Lösung: Leite den POST mit proxy_pass oder fastcgi_pass im richtigen location-Block an eine Anwendung (PHP, Node, Python) weiter. Prüfe, welcher Block die URL verarbeitet:

# Formular-POSTs müssen die App erreichen, nicht den Handler für statische Dateien
location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

# Nach Änderungen testen und neu laden
# sudo nginx -t && sudo systemctl reload nginx

Lösung 3: IIS blockiert PUT und DELETE (WebDAV)

Auf Windows-Servern mit IIS beansprucht das WebDAV-Modul die Verben PUT und DELETE, sodass REST-APIs (ASP.NET Web API und andere) darauf mit HTTP Error 405.0 antworten. Nutzt du WebDAV nicht, entferne es für deine Website in der web.config:

<system.webServer>
  <modules>
    <remove name="WebDAVModule" />
  </modules>
  <handlers>
    <remove name="WebDAV" />
  </handlers>
</system.webServer>

Prüfe im IIS-Manager außerdem die Einstellungen der Website unter Anforderungsfilterung (Request Filtering), Registerkarte HTTP-Verben (HTTP Verbs). Dort lassen sich einzelne Methoden direkt verbieten (IIS meldet das als 404.6, nicht als 405).

Lösung 4: Die Methode zu deinem Route-Handler hinzufügen

Frameworks liefern 405, wenn eine Route existiert, aber keinen Handler für die verwendete Methode hat:

• Next.js (App Router): Eine route.ts beantwortet nur die Methoden, die sie exportiert. Exportiert sie GET, aber nicht POST, liefert ein POST 405. Füge export async function POST(request: Request) { … } hinzu.

• Flask: Routen akzeptieren standardmäßig nur GET. Verwende @app.route("/contact", methods=["GET", "POST"]).

• Django: Klassenbasierte Views liefern 405 für Methoden ohne passenden Handler (füge eine post()-Methode hinzu), und der Decorator require_http_methods macht dasselbe.

• Express: Standardmäßig fällt eine nicht passende Methode auf 404 durch, nicht auf 405. Soll deine API 405 liefern, ergänze einen Catch-all-Handler, der den Allow-Header setzt.

Lösung 5: CORS-Preflight-Anfragen (OPTIONS) behandeln

Ruft eine Webseite eine API auf einer anderen Domain mit JSON oder eigenen Headern auf, sendet der Browser zuerst eine OPTIONS-Preflight-Anfrage. Beantwortet die API diese OPTIONS-Anfrage mit 405, meldet der Browser einen CORS-Fehler und sendet die eigentliche Anfrage nie – obwohl der eigentliche Endpunkt funktioniert hätte.

Sorge dafür, dass die API OPTIONS für diese Routen mit 204 oder 200 und den passenden Headern Access-Control-Allow-Methods und Access-Control-Allow-Headers beantwortet. Die meisten Frameworks haben CORS-Middleware, die das für dich erledigt. Die DNS-Lookup-API von DNS Robot beantwortet den Preflight zum Beispiel mit 204 und den CORS-Headern, sodass Browser sie von jeder Website aus aufrufen können.

405 vs. 400, 403, 404 und 501

Verwandte Anleitungen: 400 Bad Request, 403 Forbidden und 401 Unauthorized.