405 Method Not Allowed Checklist
405 Method Not Allowed? Read the Allow header to see valid methods, then tell a disabled route from a proxy or CORS block. Free instant check, no sign-up.
Check your domain for this issue now
Free, no sign-up. Runs the exact check this guide describes and shows what to fix.
Problem
The final response code for the request is 405 Method Not Allowed.
Symptoms
- HTTP Check shows a final status code of 405.
- A GET works but a POST, PUT, DELETE, or PATCH to the same URL fails.
- The failure shows up in API clients or CORS preflight while normal browsing looks fine.
What 405 Actually Means
RFC 9110 (§15.5.6) defines 405 as a method that “is known by the origin server but not supported by the target resource.” The server understands your verb perfectly — it just won’t accept it here. The spec then adds a hard requirement: the origin server MUST generate an Allow header listing the methods the resource does accept. So a correct 405 always tells you what to do instead. An empty Allow value is legal and means the resource currently accepts no methods.
This is what separates 405 from its neighbors. A 501 Not Implemented means the server doesn’t recognize the method at all (a server-wide gap, returned as 5xx). A 403 Forbidden means the method is fine but you’re not authorized. A 405 means: right verb, wrong door, and here’s the list of doors that open.
Top 3 Causes
- The route only serves some methods - The path is backed by a static file, a CDN, or a read-only handler that exposes GET/HEAD. Your write method isn’t wired up. Read the
Allowheader to see what is. - A proxy or WAF blocks the method at the edge - Reverse proxies and security rules sometimes forward only GET and POST and reject PUT, DELETE, or PATCH before the request reaches the origin. The application never sees the call.
- No OPTIONS handler, so CORS preflight breaks - The browser’s preflight OPTIONS request hits a route that doesn’t handle OPTIONS, and the server answers 405 instead of the CORS headers the browser needs.
Diagnose with DechoNet
- HTTP Check to confirm the final code is 405 and read the
Allowheader listing the methods the resource actually accepts. - DNS Lookup to confirm the request is reaching the intended origin and not a different host or environment that serves a narrower method set.
Resolution Checklist
- Read the
Allowheader in the 405 response — it lists the methods that will work. - Confirm you’re calling the right URL; a write method aimed at a static or read-only path is the usual culprit.
- If the method should be supported, enable it on the route (server or framework config), not just in the application code.
- Check whether a reverse proxy, CDN, or WAF is stripping or blocking the method before the origin sees it.
- For CORS failures, add an OPTIONS handler to the route or terminate preflight at the edge.
- Re-run HTTP Check and confirm the response is no longer 405.
When to Escalate
- Escalate to whoever owns the reverse proxy, CDN, or WAF if the method is blocked at the edge and you can’t change the rules.
- If the route genuinely should accept the method but the framework keeps returning 405, take the route config and the
Allowheader to the application owner.
Related Tools
Related Guides
Share this guide