405 Method Not Allowed: causes and fixes

What 405 Method Not Allowed means

RFC 9110 requires a 405 response to include an Allow header listing the methods the resource actually supports. That header is the whole diagnosis in one line: if a request to /api/users returns 405 with Allow: GET, HEAD, the route exists and works fine for reading, it simply never had a handler wired up for whatever method you sent.

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

How the error appears

Browsers show a generic error page for a 405 returned to a normal navigation, since this is not a case they have special handling for. It is far more common to meet a 405 in a network tab, a failed AJAX call, or a CORS preflight failure in the console, because most 405s come from scripted requests rather than clicked links. From the command line, the method and the Allow header tell the whole story:

curl -i -X POST https://example.com/downloads/report.pdf
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

What causes a 405 Method Not Allowed

• POSTing to a static file. A request for an actual file on disk, such as a PDF or an image, served by a web server that only answers GET and HEAD for static content.
• Calling a route that only defines some methods. A framework route registered for GET alone returns 405 for every other verb, by design, rather than 404.
• A CORS preflight OPTIONS request rejected. Browsers send an automatic OPTIONS request before certain cross-origin calls, and a server or gateway that has no handler for OPTIONS on that path answers 405, which then surfaces in the browser as a blocked cross-origin request rather than a clear 405.
• nginx serving a location block meant for static files. A location block using try_files against the filesystem with no proxy_pass will 405 on POST, since static file serving in nginx only implements GET, HEAD, and by default a limited method set.
• WebDAV and IIS verb restrictions. IIS and some WebDAV-enabled servers explicitly allowlist verbs per path, and a method outside that list, including custom ones like PROPFIND, gets 405 even if the general route otherwise works.
• Framework route misconfiguration. A route intended to accept both GET and POST but only registered for one, often after a refactor that split a handler without updating the route declaration.
• A load balancer or API gateway method allowlist. Some gateways restrict allowed methods per route independently of the application, and the app never even sees the rejected request.

How to tell whose fault it is

A 405 is almost always a server-side configuration or code issue rather than something a visitor caused, since browsers and normal links do not send arbitrary methods on their own. If a page mostly works but one action, like a form submit or an API call from client-side JavaScript, fails with 405, check whether that specific request's method matches what the endpoint expects. If it does and the error is new, the fastest way to confirm a route or proxy configuration broke is to run an HTTP check that sends the exact method your application uses and compare the result across a recent deploy.

How to fix a 405 Method Not Allowed

If you are a visitor

1. Reload and retry the action, since a 405 from a form submit can sometimes follow a page that loaded an outdated cached version of the form pointing at the wrong endpoint.
2. Clear the browser cache for the site if the problem persists, in case a stale service worker or cached response is replaying an old, now-incompatible request.
3. Report it to the site, since this is a configuration issue on their end in nearly every case; there is no client-side fix for a server that genuinely does not accept the method.

If you run the site

1. Read the Allow header on your own 405 response to confirm exactly which methods the server thinks are valid for that path, then compare it against what the client is actually sending.
2. Add the missing method to the route. On most frameworks this is a one-line route declaration; the fix is rarely in application logic once you know which verb is missing.
3. Handle OPTIONS explicitly for CORS-enabled routes. Either let your framework's CORS middleware answer preflight requests automatically, or add a handler that returns the correct Allow and Access-Control-Allow-Methods headers.
4. Fix the nginx location block if a static-file block is catching a route that needs a backend. A minimal example that proxies POST through instead of serving it as a file:

   location /api/ {
       proxy_pass http://backend;
   }

5. Check gateway and load balancer method allowlists separately from the application, since a request can be rejected before it ever reaches your code, and application logs will show nothing for it.

How to prevent a silent 405 after a deploy

A route that loses a method during a refactor, or a proxy rule that starts intercepting a path it did not before, will not throw an exception anywhere, it will just answer a wrong-but-valid HTTP response. A scheduled HTTP check with an assertion on the status code, sent with the exact method your integration relies on, catches that regression right after the deploy that caused it rather than after users report broken forms. For API endpoints specifically, API monitoring that checks both the method and the response body confirms the route not only accepts the request but still behaves correctly.

Related errors

See 404 Not Found for a path that does not exist at all, as opposed to one that exists but rejects the method, the 4xx overview for the full family, and 401 Unauthorized and 422 Unprocessable Content elsewhere in this batch.

Frequently asked questions

What is the difference between 404 and 405?

404 means nothing exists at that path for any method. 405 means the path exists and works for at least one method, just not the one you used, and the Allow header confirms which methods are valid.

Why does a CORS request fail with what looks like a 405?

Browsers send an automatic OPTIONS preflight before many cross-origin requests. If the server has no handler for OPTIONS on that route, it answers 405, and the browser reports it as a CORS failure in the console rather than showing the raw status code directly.

Is 405 ever the correct response for an API to send on purpose?

Yes. If a resource genuinely only supports reading, returning 405 for a PUT or DELETE against it is correct REST behavior, and it is more informative to the caller than a generic 404 would be.

Can a firewall or WAF cause a 405?

It is less common than an application or proxy misconfiguration, but some WAF rulesets restrict allowed methods per path and will answer 405 or a similar block before the request reaches the origin at all.

Why does the Allow header sometimes list methods that still fail?

The Allow header reflects what the route is registered for, not necessarily what is fully implemented. A method can be declared and still return an error for other reasons, such as missing authorization, once it passes the method check.