HTTP 405 method not allowed

What 405 means

405 Method Not Allowed tells the client: the resource exists, but that verb is not allowed on it. The server knows the URL and publicly it is there; it is refusing the specific method, usually POST, PUT or DELETE. It is a deliberately different statement from 404 (resource unknown), 403 (the server refuses the request outright), or 400 (the request itself is malformed). A 405 says: the URL is fine, the request method is the mismatch.

Where the method is decided

The server stack checks the method at several layers, and any one can be the one returning 405:

• The web server (nginx limits POST to a location with limit_except, Apache with <Limit>/<LimitExcept>).
• The application router (WordPress only registers certain routes; a framework Route::post blocks a GET).
• A firewall or WAF policy (a rule that blocks content-type or method for a path).
• The origin behind a CDN or reverse proxy, which forwards the method only if its own config allows it.

The error surface usually looks like this: a form that was GET is rewritten to POST, or a plugin or deployment config sends PUT to a URL that only accepts POST.

Test to find the blocker

Send the failing method and watch which layer answers:

curl -i -X POST https://example.com/contact/
# 405 Method Not Allowed
curl -i -X GET  https://example.com/contact/
# 200 OK  (server: nginx, the page exists)

• If GET works and POST is 405, test again with the exact form and the Content-Type the form sends (-H "Content-Type: application/x-www-form-urlencoded"). Some WAF rules only block on content type.
• If POST works to the bare domain but 405s on a path, the rule is scoped to that path.
• Look at the Allow header the server emits; compliant servers advertise the permitted methods and the header is the fastest fingerprint of which layer wrote the block. If Allow is absent, a proxy or WAF is the likely author.

The reliable fix order

1. Find what changed. A 405 that appeared overnight is a config change or a plugin update, not a spontaneous server mood. Check the API-level release notes.
2. Match the method to the route. A form posts where the app previously expected GET, or the action= URL no longer matches the registered route. Change the form or the route, not the server.
3. Whitelist the exact method at the real blocker. In nginx:

location /api/ {
    limit_except GET POST { deny all; }
}

In a framework, register the verb your handler actually accepts. Remove accidental Allow restrictions that were part of a copy-pasted security snippet.

1. Retest across the stack. A web host's .htaccess or ModSecurity rule can 405 a method for specific paths. After the config change, curl the same request from a clean browser and confirm the Allow header is right.

When it is not a bug

A deliberate lock-down of unused methods is good hygiene: an API that only serves GET and POST should return 405 for DELETE. The HTTP basic errors article keeps the whole family in one helpful table, and the forbidden and unauthorized counterparts are covered in 403 and 401.