So behebst du den Fehler 405 Method Not Allowed

Du klickst in einem Formular auf "Absenden". Die Seite wirft einen Fehler 405 Method Not Allowed aus. Kein Stack-Trace, kein nützlicher Hinweis, nur eine glatte Absage von deinem Server. Willkommen bei einem der nervigeren HTTP-Fehlercodes.

Der HTTP-Statuscode 405 sagt dir eines ganz genau: Der Server hat die Ressource gefunden, deine Anfrage verstanden und die von dir verwendete HTTP-Methode abgelehnt. Die Seite ist da. Der Server macht einfach nicht das, was du von ihm verlangst. Das hier ist kein 404. Die URL ist korrekt. Irgendetwas in der Serverkonfiguration, deinem Code oder einem frisch installierten Plugin hat entschieden, dass eine völlig valide POST- oder PUT-Anfrage wie ein unerwünschter Gast behandelt wird.

Hier kommt eine Übersicht über alle Ursachen, die mir bisher in der Produktion begegnet sind, plus 11 Lösungen – sortiert von "dauert 30 Sekunden" bis hin zu "alles aus dem Backup wiederherstellen". Egal ob du als Entwickler diesen Fehler bei einer API kriegst oder als Website-Besitzer vor einem kaputten Kontaktformular stehst, Die Lösung liegt fast immer an denselben paar Stellen.

Was den 405-Fehler verursacht

Der 405-Fehler tritt auf, wenn die HTTP-Request-Methode nicht mit dem übereinstimmt, was die Ressource akzeptiert. Das Konzept ist simpel; herauszufinden, auf welcher Ebene der Fehler liegt, ist der schwierige Teil.

Nicht unterstützte HTTP-Methode

Jede Web-Ressource ist darauf eingestellt, bestimmte HTTP-Methoden zu akzeptieren. GET ruft Daten ab. POST übermittelt Daten. PUT aktualisiert. DELETE entfernt. Du sendest einen DELETE-Request an eine statische HTML-Seite, die nur GET verarbeitet? Der Server gibt einen 405 zurück. Er hat die Seite gefunden. Er weigert sich einfach, diese spezielle Aktion auszuführen. Das ist die häufigste Ursache und bedeutet meistens, dass dein Code, deine Form-Action oder dein API-Call den falschen Endpunkt ansteuert.

Falsche Serverkonfiguration

Apache nutzt .htaccess-Dateien, NGINX nutzt die nginx.conf. Eine einzige falsch gesetzte Direktive in einer von beiden kann eine komplette HTTP-Methode im gesamten Verzeichnisbaum ohne jede Warnung blockieren. Ich habe mal einen 405 auf eine Limit-Direktive zurückverfolgt, die jemand ohne Plan aus einem Security-Blog kopiert hatte. Sie blockierte POST für jede HTML-Datei im Root-Verzeichnis. Kontaktformular, Checkout-Seite, Login-Screen: alles kaputt. Die Lösung war das Löschen von zwei Zeilen. Diese zwei Zeilen zu finden, hat mich fast einen ganzen Nachmittag gekostet, weil sich niemand mehr daran erinnern konnte, sie hinzugefügt zu haben.

API-Einschränkungen

APIs sind sehr streng, was die akzeptierten HTTP-Request-Methoden angeht. Ein Endpunkt, der für POST gebaut wurde, wird nicht auf PUT reagieren, nur weil dein Client-Code einen sendet. Wenn du 405-Fehler nur bei API-Calls siehst, schau in die API-Dokumentation und checke, ob du die richtige Methode für den jeweiligen Endpunkt nutzt. Das passiert oft bei Drittanbieter-APIs, die verschiedene Versionen nutzen und alte Methoden abschalten.

REST-APIs sind hier meistens die Verdächtigen. Ein GET-Request an einen Endpunkt, der nur POST unterstützt, wird jedes Mal einen 405 liefern. Dasselbe gilt für PATCH vs. PUT: Manche APIs behandeln sie gleich, andere nicht. Lies die Docs, checke den Allow-Header in der 405-Antwort (da steht drin, welche Methoden akzeptiert werden) und passe deinen Request an.

Regeln der Web Application Firewall

Eine Web Application Firewall kann deine Serverkonfiguration komplett überschreiben. WAF-Regeln blockieren oft aus Sicherheitsgründen HTTP-Methoden wie PUT, DELETE oder PATCH auf bestimmten Pfaden. Der Ärger geht los, wenn diese Regeln zu weit gefasst sind. Eine Regel, die DELETE für deine komplette Domain sperrt, klingt vernünftig – bis dein Admin-Dashboard plötzlich DELETE braucht, um Datensätze zu löschen.

Wenn du vor Kurzem deine WAF aktiviert oder aktualisiert hast und seitdem 405-Fehler auftauchen, schraub die Methoden-Blockier-Regeln zurück und teste es noch mal. Schau im Dashboard deines WAF-Anbieters in die Logs, um zu sehen, welche Regeln genau ausgelöst haben. Übertriebene Security schafft oft eigene Probleme. Ein 405-Fehler, der legitime Funktionen blockiert, ist schlimmer als der theoretische Angriff, den er eigentlich verhindern soll.

Plugin- und Theme-Konflikte

WordPress-Seiten sind dafür besonders anfällig. Du installierst ein neues Plugin, es registriert eigene Rewrite-Rules oder REST-API-Routen, und diese kollidieren dann mit der .htaccess. Schon wirft deine Seite bei Formular-Submissions 405-Fehler aus. Das Plugin an sich ist okay, aber das Zusammenspiel mit deiner Konfiguration verursacht den Crash. Das Gleiche gilt für Themes mit Sonderfunktionen oder mitgelieferten Plugins.

Verbliebene Datenbank-Änderungen

Manche Erweiterungen ändern bei der Installation Datenbanktabellen und räumen nach der Deinstallation nicht richtig auf. Verwaiste Einträge in Options-Tabellen oder Registrierungen von Custom Post Types können die Routing-Logik deiner App verwirren. Die App sendet dann eventuell Requests mit der falschen HTTP-Methode, weil ihr interner Status nicht mehr zum tatsächlichen Server-Setup passt.

So behebst du den 405-Fehler

Geh diese Punkte der Reihe nach durch. Die ersten Punkte sind schnelle Plausibilitätsprüfungen, die die meisten Fälle abfangen. Die späteren Schritte erfordern tieferes Grabben in den Server-Internals und im Code.

1. Überprüfe, ob die URL korrekt ist

Fang mit dem peinlich Offensichtlichen an. Tippfehler in der URL-Konfiguration verursachen öfter 405-Fehler, als man zugeben möchte.

• Falsch geschriebene Pfade (/usres statt /users)
• Groß- und Kleinschreibung (manche Server behandeln /Page und /page als unterschiedliche URLs)
• Schrägstriche am Ende, die stillschweigend zu einem anderen Handler umleiten
• Eine Route, die auf einen Handler zeigt, der die genutzte HTTP-Methode gar nicht unterstützt

Öffne die Entwicklertools deines Browsers, geh zum Tab Netzwerk und schau dir den fehlgeschlagenen Request an. Checke die Methode (GET, POST etc.) und die exakte URL, die aufgerufen wird. Vergleiche das mit dem, was deine Anwendung eigentlich erwartet. Wenn es nicht zusammenpasst, korrigiere die URL oder den Handler. Wenn alles stimmt, mach mit dem nächsten Punkt weiter.

2. Mach kürzliche Updates rückgängig

Wenn der 405 direkt nach einem Update auftauchte, verbring nicht eine Stunde mit Debuggen. Setz es erst mal zurück. Du kannst der Sache später auf den Grund gehen, während die Seite wieder läuft.

Mach ein Backup deiner Seite, bevor du den Rollback startest. Mach dann die letzte Änderung rückgängig. Bei WordPress erledigt ein Plugin wie "WP Rollback" das für den Core, Themes und Plugins. Auf anderen Plattformen nutzt du deine Deployment-Pipeline oder Versionskontrolle, um den alten Stand wiederherzustellen. Wenn der Fehler nach dem Revert weg ist, hast du das Problem isoliert. Warte entweder auf einen Patch vom Entwickler, schreib einen Bug-Report oder such dir eine Alternative.

Eine Gewohnheit, die solche Vorfälle verhindert: Teste jedes Update in einer Staging-Umgebung, bevor du es in die Produktion pushst.

3. Checke Datenbank-Änderungen

Erweiterungen schreiben manchmal bei der Installation in deine Datenbank und räumen beim Löschen nicht hinter sich auf. Diese verwaisten Einträge können die Routing-Logik stören, sodass HTTP-Requests mit der falschen Methode gesendet werden.

Öffne phpMyAdmin oder dein Datenbank-Tool, wähle die Datenbank aus, geh zum SQL-Tab und führe das aus:

SELECT UNIX_TIMESTAMP(MAX(UPDATE_TIME)) AS last_update

FROM information_schema.tables

WHERE TABLE_SCHEMA = 'your_database_name'

GROUP BY TABLE_SCHEMA;

Wenn der Zeitstempel zum Start der 405-Fehler passt, untersuche die kürzlich geänderten Tabellen nach Einträgen, die dort nicht hingehören. Konzentriere dich auf Options-Tabellen, Routing-Tabellen und alles, was mit Plugins zu tun hat, die du neu installiert oder entfernt hast. Mach immer ein Backup deiner Datenbank, bevor du Änderungen vornimmst. Produktionsdaten ohne Sicherheitsnetz zu bearbeiten, führt meist zu größeren Problemen als denen, die du eigentlich lösen wolltest.

4. Entferne fehlerhafte Plugins oder Themes

Bei CMS-basierten Seiten sind neu installierte Plugins oder Themes die häufigsten Auslöser für 405-Fehler. Der neue Code registriert entweder kollidierende Routen, ändert die Serverkonfiguration oder beeinflusst, wie deine App HTTP-Requests verarbeitet.

Geh in WordPress zum Admin-Bereich, öffne die Plugins und deaktiviere alles, was du zuletzt installiert hast. Teste die Seite. Wenn der Fehler verschwindet, war dieses Plugin die Ursache. Wiederhole den Vorgang für die Themes unter Design, falls das Plugin nicht verantwortlich war.

Du kommst nicht ins Admin-Panel? Geh per SSH oder FTP auf deinen Server und benenne den Plugin-Ordner in wp-content/plugins/ um. WordPress deaktiviert automatisch jedes Plugin, das es nicht finden kann. Gleicher Ansatz für Themes in wp-content/themes/. Versuche eine andere Erweiterung mit ähnlichen Funktionen zu nutzen, sobald du bestätigt hast, dass die alte den Konflikt verursacht hat.

5. Analysiere serverseitige Protokolle (Logs)

Wenn schnelle Lösungen fehlschlagen, findest du in den Logs meistens die echte Antwort. Du musst zwei Typen überprüfen.

Server-Logs

Apache und NGINX führen Access-Logs (Zugriff) und Error-Logs (Fehler). Das Access-Log zeichnet jede Anfrage auf, inklusive HTTP-Methode, URL und dem Statuscode der Antwort. Das Error-Log erklärt, warum der Server die Anfrage abgelehnt hat. Zusammen erzählen diese beiden die ganze Geschichte.

Apache-Logs liegen in /var/log/apache2/ auf Debian/Ubuntu oder /var/log/httpd/ auf CentOS/RHEL. NGINX speichert sie in /var/log/nginx/.

Nutze tail -f /var/log/apache2/error.log, um das Error-Log in Echtzeit zu verfolgen. Triggere den 405-Fehler in deinem Browser und schau dir dann den neuesten Log-Eintrag an. Dort steht genau, welche Regel oder Direktive die Ablehnung verursacht hat.

Anwendungs-Logs

Deine Web-App führt eigene Protokolle, getrennt vom Server. Diese enthalten Debug-Ausgaben, Exception-Traces und Audit-Logs, die zeigen, wie die App den Request intern verarbeitet hat. Wenn die Server-Logs sauber aussehen, aber der 405 trotzdem auftritt, erzeugt die Anwendung den Fehler selbst durch ihre eigene Routing-Logik.

Überprüfe das Log-Verzeichnis im Root-Ordner deiner Anwendung. Aktiviere in WordPress WP_DEBUG und WP_DEBUG_LOG in der wp-config.php, um Fehler auf Anwendungsebene in der wp-content/debug.log zu speichern. Bei Laravel checkst du die storage/logs/laravel.log. Bei Django schaust du in den konfigurierten Logging-Handler. Das Anwendungs-Log könnte zeigen, dass ein Route-Mapping geändert wurde oder eine Middleware den Request abblockt, bevor er den Controller erreicht.

6. Überprüfe die Webserver-Konfiguration

Die hartnäckigsten 405-Fehler verstecken sich in den Konfigurationsdateien deines Webservers. Hier zahlt sich genaues Hinsehen aus.

Apache (.htaccess)

Zwei Dinge in der .htaccess verursachen die meisten Apache-bezogenen 405-Fehler:

• mod_rewrite-Regeln , die den Traffic umleiten, ohne alle HTTP-Methoden beizubehalten. Eine RewriteRule für GET, die POST ignoriert, zerschießt jede Formularübermittlung auf diesem Pfad.
• Limit-Direktiven , die einschränken, welche Methoden eine Ressource akzeptiert. Das sind Sicherheitsmaßnahmen, aber ein falsch konfiguriertes „Limit“ kann legitime POST- oder PUT-Anfragen für ganze Verzeichnisse blockieren.

Kommentiere verdächtige Direktiven mit # aus und starte Apache neu zum Testen. Aktiviere sie nacheinander wieder, um das Problem zu isolieren.

NGINX (nginx.conf)

Checke in NGINX folgende Punkte:

• Location-Blöcke , die bestimmte HTTP-Methoden implizit ausschließen. Wenn ein Location-Block nur GET verarbeitet, schlagen alle POST-Anfragen an diesen Pfad fehl.
• error_page-Direktiven , die 405-Fehler auf eine statische Seite umleiten, welche selbst die ursprüngliche Methode nicht akzeptiert – das erzeugt eine Endlos-Schleife.

Validiere deine Konfiguration nach dem Bearbeiten mit nginx -t, bevor du neu lädst. Ein Syntaxfehler in der nginx.conf kann deine komplette Seite offline nehmen.

7. Debugge deinen Code und deine Skripte

Manchmal liegt das Problem nicht in der Server-Konfiguration. Es liegt in deinem Anwendungscode.

Häufige Übeltäter:

• Das Action-Attribut eines Formulars verweist auf einen Endpunkt, der nur GET akzeptiert, aber das Formular nutzt method="POST"
• Ein JavaScript fetch() oder XMLHttpRequest-Aufruf sendet die falsche HTTP-Methode für den Ziel-API-Endpunkt
• Framework-Middleware fängt bestimmte Methoden heimlich ab und lehnt sie ab, bevor dein Route-Handler sie überhaupt sieht

Klone deine Seite in eine lokale Entwicklungsumgebung und reproduziere den Fehler dort. Deaktiviere in WordPress alle Plugins und wechsle zu einem Standard-Theme (wie Twenty Twenty-Four), um das Problem zu isolieren. Wenn der 405 verschwindet, aktiviere die Plugins nacheinander wieder. Nutze den Netzwerk-Tab deines Browsers, um den genauen Request zu inspizieren: Methode, URL, Header und den Statuscode der Antwort.

Schreibe Unit-Tests, die jeden Endpunkt mit jeder HTTP-Methode testen, die er akzeptieren sollte. Automatisierte Tests finden solche Unstimmigkeiten schon während der Entwicklung und nicht erst in der Produktion.

8. Stelle deine Website aus einem Backup wieder her

Wenn du alles andere probiert hast, stelle die komplette Seite aus einem Backup wieder her. Das ist die nukleare Option – sie funktioniert, weil sie alle Variablen auf einmal eliminiert.

Wähle das aktuellste Backup von einem Zeitpunkt aus, bevor der 405-Fehler das erste Mal auftrat. Das setzt deine Dateien, Datenbank und Konfiguration auf einen bekannten, funktionierenden Stand zurück. Du verlierst allerdings alle Änderungen, die nach diesem Backup-Zeitpunkt gemacht wurden. Das ist der Preis dafür. Falls du keine aktuellen Backups hast, ist das die Lektion, die dich hoffentlich davon überzeugt, sie ab jetzt zu automatisieren.

Die meisten Hosting-Panels haben eine One-Click-Wiederherstellungsfunktion. Falls nicht, lade dein Datei-Backup manuell per FTP hoch und importiere die Datenbank über phpMyAdmin. Teste nach dem Restore sofort die Seiten, die den 405 ausgegeben haben, um sicherzugehen, dass der Fehler weg ist. Finde dann heraus, was den Fehler verursacht hat, bevor du die Änderungen, die alles zerschossen haben, erneut anwendest. Blindes Wiederherstellen und anschließendes Wiederholen derselben Änderungen bringt dich nur wieder in denselben defekten Zustand zurück.

9. Korrigiere .htaccess Rewrite-Regeln

Die .htaccess Rewrite-Regeln von Apache verdienen einen eigenen Abschnitt, da sie unverhältnismäßig viele 405-Fehler verursachen.

Öffne die .htaccess per Dateimanager oder FTP. Suche nach Zeilen, die „R=405“ enthalten. Das ist eine Rewrite-Regel, die explizit einen 405-Statuscode zurückgibt. Kommentiere sie mit einem # am Zeilenanfang aus, speichere die Datei und leere deinen Browser-Cache.

Wenn der 405 aufhört, hast du die Regel identifiziert. Bevor du sie endgültig löschst, finde heraus, warum sie überhaupt hinzugefügt wurde. Vielleicht hat sie jemand absichtlich aus Sicherheitsgründen dort platziert. Wenn sie eine Methode blockiert hat, die deine App braucht, entferne sie. Wenn sie gegen einen echten Angriffsvektor schützen sollte, finde einen gezielteren Weg für diese Einschränkung.

10. Korrigiere die Dateiberechtigungen

Falsche Dateiberechtigungen können auf unerwartete Weise 405-Fehler verursachen. Wenn der Webserver-Prozess nicht der rechtmäßige Besitzer deiner Dateien ist, kann er Skripte eventuell nicht ausführen – und der daraus resultierende Fehler zeigt sich manchmal als 405 statt des erwarteten 403 Forbidden. Ich habe das oft nach Server-Migrationen erlebt, bei denen Dateien mit dem falschen Besitzer übertragen wurden, oder nachdem jemand einen Bulk-chmod-Befehl über das komplette Document-Root laufen lassen hat.

Standardberechtigungen für die meisten Webserver:

• Verzeichnisse: 755
• Dateien: 644
• Besitzer: Der Webserver-Benutzer (www-data auf Debian/Ubuntu, apache auf CentOS)

Besitzrechte rekursiv korrigieren: chown -R www-data:www-data /var/www/yoursite

Verzeichnisberechtigungen korrigieren: find /var/www/yoursite -type d -exec chmod 755 {} \;

Dateiberechtigungen korrigieren: find /var/www/yoursite -type f -exec chmod 644 {} \;

11. Überprüfe die DNS A-Records

Diese Ursache ist selten, aber wenn sonst nichts geholfen hat, checke dein DNS. Falsche A-Records können den Traffic an einen komplett falschen Server leiten – und dieser akzeptiert vielleicht die HTTP-Methoden deiner App nicht.

Logge dich bei deinem Domain-Registrar oder im DNS-Panel ein und bestätige deine A-Records:

• Typ: Muss A sein
• Name: @ für die Root-Domain oder der Name der Subdomain
• Zeigt auf: Die korrekte IP-Adresse deines eigentlichen Hosting-Servers
• TTL: Typischerweise 14400 Sekunden (4 Stunden)

Das ist besonders wichtig, wenn du kürzlich den Server oder Hosting-Anbieter gewechselt oder DNS-Einstellungen aktualisiert hast. Die DNS-Propagation kann bis zu 48 Stunden dauern. Selbst korrekte Änderungen sind also vielleicht noch nicht überall auf der Welt angekommen. Nutze ein Tool wie dig oder einen Online-DNS-Checker, um zu prüfen, was die Resolver gerade sehen.

Best Practices für die Website-Wartung

Den 405-Fehler einmal zu beheben, reicht nicht. Die eigentliche Aufgabe ist es, dafür zu sorgen, dass er nicht wiederkommt. Die meisten dieser Fehler entstehen durch Änderungen: Updates, neue Plugins, Config-Edits oder Datenbank-Anpassungen. Ein paar Gewohnheiten helfen dir massiv dabei, deine Seite stabil zu halten.

Checke deine Server-Logs wöchentlich. Nicht erst, wenn etwas kaputtgeht. Wöchentlich. So bemerkst du Warnzeichen, ungewöhnliche 4xx-Spitzen, Warnungen zu veralteten Methoden oder fehlgeschlagene Requests, bevor sie zu sichtbaren Fehlern werden, die deine Besucher vergraulen.

Update niemals die Produktion, ohne vorher im Staging zu testen. Diese eine simple Methode zur Fehlersuche verhindert die Mehrheit der 405-Fehler, die mir in der Praxis begegnet sind. Es dauert fünf Minuten, eine Staging-Seite aufzusetzen, spart dir aber Stunden an Notfall-Fehlersuche am Samstagmorgen um 2 Uhr.

Automatisiere deine Backups und teste sie, indem du regelmäßig eines wirklich wiederherstellst. Ein Backup, das du nie verifiziert hast, ist nur eine Datei, die vielleicht funktioniert. "Might" reicht nicht aus, wenn deine Checkout-Seite am Launch-Tag 405-Fehler wirft.

Dokumentiere deine Änderungen an der Server-Konfiguration. Führe ein Changelog für .htaccess, nginx.conf und alle WAF-Regeln. Wenn drei Monate später ein 405 auftaucht, weil jemand an einer Limit-Direktive geschraubt hat, weißt du genau, was wann geändert wurde. Dein zukünftiges Ich wird dir dankbar sein.

FAQ: 405 Method Not Allowed Fehler