Erriscope
EN
English Español Português (Brasil) Deutsch Français 日本語 한국어

HTTP 405 Method Not Allowed: What It Means and How to Fix It

DIRECT ANSWER

HTTP 405 Method Not Allowed means the server understood the HTTP method, such as GET, POST, PUT or DELETE, but that method is not supported for the requested resource. The URL or host may still be reachable; the problem is usually specific to the request method, route, application, server, proxy or CDN rule. Confirm the exact method and URL, inspect the response headers—especially any `Allow` header—and use logs to identify the component that returned the response.

Key takeaways

  • HTTP 405 concerns the method used for a specific resource, not necessarily the availability of the whole website.
  • Confirm the exact URL, HTTP method, status and response headers before changing configuration.
  • An Allow response header may identify methods the resource accepts, although its absence does not by itself identify the cause.
  • The response can come from the application, web server, reverse proxy, CDN or WAF rather than the origin application.
  • Use matching logs and a minimal reproduction to distinguish an intentional rule from a routing or deployment mistake.
  • Make the narrowest authorized change and retest the same request without weakening unrelated security controls.
Reviewed 2026-09-25 HTTP & Server Errors
SA

Site Administrator

Last reviewed: September 25, 2026

What this error means & how to recognize it

  • A browser, API client, monitoring tool or checker receives 405 Method Not Allowed.
  • One HTTP method fails while another method for the same route may work.
  • The issue may affect one URL, route pattern, client or deployment rather than the entire site.
  • The response may include an Allow header listing permitted methods.
  • Other headers may reveal redirects, caching, authentication, proxy, CDN or server context.
  • Because an HTTP response was received, DNS resolution and TLS negotiation may already have succeeded, but that does not prove the application or route is correctly configured.

Root causes, ordered by likelihood

Common causes

  1. The method is not supported by the route. The endpoint may accept GET but reject POST, or accept POST but reject an update method such as PUT or PATCH.
  2. Routing or web-server rules reject the method. A route, virtual host or server policy may not pass the request to the intended handler.
  3. A reverse proxy, CDN or WAF returns the response first. An intermediary can apply method restrictions or route the request differently from the origin.
  4. The request does not match the application contract. The path, trailing slash, content type, host, authentication state or other request details may select a different route or validation rule.
  5. A recent deployment or configuration change introduced a mismatch. Application routes, proxy rules, allowed methods and caching behavior may no longer agree.
  6. An intentional policy or endpoint design. Some resources deliberately reject methods that are unsafe, unsupported or outside their documented interface.

The status code alone cannot identify which layer or rule caused the response. Confirm the method, headers, logs and recent changes before modifying the system.

How to fix it

1Is the final response actually HTTP 405? If not,investigate the final status code instead.2Is the method expected for this resource? If no, use thedocumented method or contact the endpoint owner; do notchange server policy.3Does the response include Allow or proxy-relatedheaders? Use them as clues, not as proof of theresponsible layer.4Did the request reach the origin? Match the timestamp,method, path and request ID across proxy, server andapplication logs.5Did a recent route, deployment or security-policy changeprecede the issue? Compare the current configurationwith the last known-good state.6Can the cause be corrected narrowly and tested safely?If not, escalate before changing productionconfiguration.
Diagnostic flow at a glance — full detail in the steps below.

If you are a visitor or API consumer

  1. Confirm the exact URL and whether the client is sending the intended method. A browser address-bar request normally uses GET, while an API client may use POST, PUT, PATCH, DELETE or another method.
  2. Check the response headers for an Allow header and for redirect, authentication, caching or proxy information. Do not treat a different method as a valid workaround unless the site or API documentation says it is supported.
  3. If the endpoint requires an account, sign in through the normal process and retry without exposing credentials in a support request.
  4. Avoid repeated retries when the service is also reporting rate limits, timeouts or overload symptoms.
  5. If the problem persists, send the site owner the URL, method, timestamp, status code and relevant sanitized headers. Do not share passwords, cookies, authorization tokens or API secrets.

If you own or maintain the site

  1. Capture a minimal reproduction. Record the exact method, URL, host, request path, status and relevant response headers. Preserve the request body only if it contains no secrets or personal data.
  2. Check whether the response is intentional. Compare the request with the route or API contract. Determine whether the resource is supposed to support that method and whether an Allow header identifies accepted methods.
  3. Identify the responding layer. Use response headers, request IDs and timestamps to determine whether the response came from the application, web server, reverse proxy, CDN or WAF. A proxy-generated response may never reach the origin.
  4. Inspect matching logs. Search the identified layer and, where available, the upstream layer for the same timestamp, path, method and request ID. Look for route mismatches, method filters, rejected upstream requests and recent policy changes.
  5. Compare recent changes. Review deployments, route definitions, web-server rules, proxy or CDN behavior, authentication configuration and WAF policies. Compare a failing method with a known-supported method for the same route.
  6. Apply the narrowest authorized correction. Update only the route or rule that should support the method. Do not broadly disable authentication, WAF protections or method restrictions to make the error disappear.
  7. Retest safely. Repeat the same request in a non-production environment when possible, then test the affected production route under the approved change process. Confirm that unsupported methods remain rejected and that related routes still return their intended status codes.
  8. Check caches and intermediaries. If behavior differs between clients or locations, verify whether a proxy or CDN cached the response or is applying a separate rule. Purge or change cached behavior only under the service’s normal operational procedure.

Prevention & how to verify the fix

  • Define and document the supported methods for important web routes and API endpoints.
  • Test representative methods for critical routes after application, server, proxy, CDN and WAF changes.
  • Monitor status-code rates by route and method rather than treating all 4xx responses as one group.
  • Keep routing, method restrictions, authentication and proxy configuration version controlled.
  • Preserve request IDs and logs across intermediary and origin layers long enough to correlate failures.
  • Document intentional 405 responses so support and monitoring teams can distinguish expected behavior from regressions.
  • Avoid broad method allowances; permit only the methods required by each resource and application contract.

When to get outside help

Escalate to the site owner, hosting provider or platform team when a 405 appears unexpectedly on an important public route, affects many users, began after a deployment, or differs between clients or locations. Get specialist review before changing authentication, WAF, CDN, reverse-proxy or server rules if you cannot validate the security and routing impact. Provide sanitized methods, paths, timestamps, response headers, request IDs and relevant logs; never include passwords, cookies, authorization tokens or API secrets.

Run a website check

Frequently asked questions

Does HTTP 405 mean the whole website is down?

No. HTTP 405 describes one request to one resource. Other pages, routes or methods may continue to work normally.

What is the difference between HTTP 405 and HTTP 404?

A 404 indicates that the requested resource was not found at the relevant endpoint. A 405 indicates that the server recognized the method but does not allow that method for the identified resource. Routing and intermediary behavior should still be checked when the result is unexpected.

What does the Allow header mean in a 405 response?

When present, Allow lists methods that the resource supports, such as GET or POST. It is useful evidence when diagnosing the request, but the response headers and logs should be considered together because a proxy or other intermediary may have produced the response.

Can DNS and TLS still be working when HTTP 405 appears?

Yes. Receiving an HTTP response generally means the request reached an HTTP-speaking endpoint after the relevant connection steps. DNS and TLS are separate checks, so a 405 does not by itself confirm that the intended application route is healthy.

Should I change the request from POST to GET?

Only if the endpoint documentation or owner says the resource supports GET for that operation. Changing methods blindly can produce the wrong result or expose an unsafe request pattern.

What should a site owner check first?

Start with the exact method, URL, response headers and timestamp. Then determine which component generated the response and inspect its matching logs before changing routing or security configuration.

Further documentation