405 Method Not Allowed: What It Means & How to Fix It

What Is a 405 Method Not Allowed Error?

405 Method Not Allowed is an HTTP status code meaning the server knows the address you requested, but doesn't allow the method your request used. RFC 9110 defines it as the method being "known by the origin server but not supported by the target resource" (RFC 9110 §15.5.6).

Every HTTP request has a method: GET to read a page, POST to submit a form or create something, PUT and PATCH to update, DELETE to remove, OPTIONS to ask what's allowed. A 405 means the URL exists, but not for that verb. If the URL didn't exist at all, you'd get 404 instead.

Because it's about how a request was made rather than about a missing page, a 405 is almost always something for the site's developer to fix. Visitors usually hit it after submitting a form or following an outdated link.

What a 405 Error Looks Like

Step 1: Read the Allow Header

Ask the server which methods it accepts for that URL. Either send an OPTIONS request, or repeat the failing request with headers shown:

# Which methods does this URL accept?
curl -i -X OPTIONS https://example.com/api/contact

# Repeat the failing request and look at the status and Allow header
curl -i -X POST https://example.com/api/contact -d 'name=test'
# HTTP/2 405
# allow: GET, HEAD

DNS Robot's HTTP Header Checker shows the status code and headers a URL returns to a normal GET request, which helps when you're checking a page in the browser rather than an API.

Not every server follows the rule. nginx's built-in 405 page, for example, is sent without an Allow header (a POST to nginx.org's own static pages shows it), and so is the empty 405 a Next.js route handler returns; Apache includes one. On Next.js, curl -i -X OPTIONS still lists the methods, because Next.js answers OPTIONS itself. On nginx you'll need to check which location block handles the URL instead (Fix 2).

If You're a Visitor

• Go back and reload the page, then submit the form again. A form loaded from an old cached copy can post to an address that has since changed.
• Don't resubmit by refreshing. If the error appeared right after you sent a form, refreshing only repeats the same rejected request; go back, reload the form page and submit from there.
• Check the address for a typo, or open the site's homepage and navigate again.
• Report it. If a form on the site always fails, the site owner needs to fix it, so send them the page address.

Fix 1: Send the Right Method to the Right URL

A common cause in code is simply a mismatch: a form or fetch() call uses POST while the endpoint only accepts GET, or the request goes to the page URL instead of the API URL. Compare the method in your code with the Allow header and the API's documentation.

// The endpoint only allows POST, so a GET (the default for fetch) returns 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"))

Fix 2: nginx Returns 405 for POST to Static Files

nginx's static file handler only serves GET and HEAD. A POST to an .html file, or to a location that serves files instead of passing the request to your application, gets 405 Not Allowed. This often happens when a form's action points at a static page, or when a location block meant for your app doesn't match.

The real fix is to send the POST to an application (PHP, Node, Python) with proxy_pass or fastcgi_pass in the right location block, for example:

# Form posts must reach the app, not the static file handler
location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

# Test and reload after changes
# sudo nginx -t && sudo systemctl reload nginx

Fix 3: IIS Blocks PUT and DELETE (WebDAV)

On Windows servers running IIS, the WebDAV module claims the PUT and DELETE verbs, so REST APIs (ASP.NET Web API and others) answer HTTP Error 405.0 for them. If you don't use WebDAV, remove it for your site in web.config:

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

Also check the site's Request Filtering settings in IIS Manager (HTTP Verbs tab), which can deny specific methods outright (IIS reports those as 404.6, not 405).

Fix 4: Add the Method to Your Route Handler

Frameworks return 405 when a route exists but has no handler for the method used:

• Next.js (App Router): a route.ts answers only the methods it exports (plus HEAD and OPTIONS, which Next.js adds itself). If it exports GET but not POST, a POST returns 405. Add export async function POST(request: Request) { … }.
• Flask: routes accept only GET by default. Use @app.route("/contact", methods=["GET", "POST"]).
• Django: class-based views return 405 for methods without a matching handler (add a post() method), and the require_http_methods decorator does the same.
• Express: by default an unmatched method falls through to 404, not 405. If your API should return 405, add a catch-all handler that sets the Allow header.

Fix 5: Handle CORS Preflight (OPTIONS) Requests

When a web page calls an API on another domain with JSON or custom headers, the browser first sends an OPTIONS preflight request. If the API answers that OPTIONS request with 405, the browser reports a CORS error and never sends the real request, even though the real endpoint would have worked.

Make the API answer OPTIONS for those routes with a 204 or 200 and the right Access-Control-Allow-Methods and Access-Control-Allow-Headers headers. Most frameworks have CORS middleware that does this for you. DNS Robot's own public API, for example, answers the preflight through its CORS middleware and any other method it doesn't support with 405 and Allow: GET, OPTIONS.

405 vs 400, 403, 404 and 501

Related guides: 400 Bad Request, 403 Forbidden and 401 Unauthorized.