405 Error: Method Not Allowed — Meaning, Causes & Full Fix Guide (2026)
HTTP 405 — Method Not Allowed
⚡ Key Takeaways
- HTTP 405 means the server received your request, recognised the URL, but refuses the specific HTTP method (GET, POST, PUT, DELETE, etc.) you used on that endpoint.
- Unlike 404 (resource not found), 405 confirms the resource exists — the method is the problem, not the URL.
- Per RFC 9110, the server must include an
Allowheader listing permitted methods — always read it before debugging. - For developers, 405 is almost always caused by a wrong method in client code, a misconfigured route, or a WAF/firewall blocking a valid method.
- For web scrapers, 405 can be a genuine method error or a deliberate anti-bot response masquerading as a method rejection — the two require different fixes.
HTTP 405 is one of the most actionable error codes a server can return. Unlike the vague 500 or the frustrating 403, a 405 comes with a built-in diagnostic: the server is required by the HTTP specification to tell you exactly which methods it does accept on that resource. That means when you see a 405, the information you need to fix it is almost always in the same response.
This guide explains the precise meaning of 405, walks through every HTTP method so you understand the method landscape, covers the seven most common causes, and provides a complete fix checklist organised by audience — end users, developers, server administrators, and web scrapers.
What HTTP 405 Means — Precisely
The HTTP 405 status code means: "Method Not Allowed." As defined in MDN Web Docs: "The server knows the request method, but the target resource doesn't support this method."
Three things are simultaneously true when you receive a 405:
- The URL is valid. The resource exists — if it didn't, you would get 404.
- Your request was syntactically correct. If it were malformed, you would get 400.
- Authentication is not the issue. An auth failure would return 401 or 403.
The problem is specifically and only the HTTP method. The server understands every other part of your request and rejects exclusively the method verb. The practical implication: the fix does not involve URLs, authentication tokens, or request bodies — it involves changing which HTTP method you use, or configuring the server to accept the method you need.
Per RFC 9110 Section 15.5.6, the server must generate an Allow header in every 405 response listing the methods that resource currently supports. This is not optional — it is a protocol requirement. Always check the Allow header before doing anything else.
HTTP/1.1 405 Method Not Allowed
Allow: GET, POST, HEAD
Content-Type: application/json
Content-Length: 78
{"error": "Method Not Allowed", "allowed_methods": ["GET", "POST", "HEAD"]}
HTTP Methods: The Complete Reference
Understanding why 405 occurs requires knowing what each HTTP method is designed for. Mismatching a method to an endpoint's purpose is the single most common cause of 405 errors.
GET
Retrieve a resource. Read-only — must not modify server state. The default for browser navigation. Safe and idempotent.
POST
Submit data to create a new resource or trigger processing. Form submissions, API creation endpoints. Not idempotent.
PUT
Replace a resource entirely with the provided payload. Idempotent — repeated calls produce the same result.
DELETE
Remove a resource. Idempotent. Often restricted to authenticated admin endpoints for security.
PATCH
Apply partial modifications to a resource. Unlike PUT, does not require a complete replacement payload.
405 vs. Similar 4xx Error Codes
| Code | Name | Meaning | Key Difference from 405 |
|---|---|---|---|
| 400 | Bad Request | Malformed syntax — server can't parse the request | 400 = request format wrong. 405 = request format correct, method rejected. |
| 401 | Unauthorized | Authentication required — valid credentials not provided | 401 = auth issue. 405 = method issue, regardless of credentials. |
| 403 | Forbidden | Server refuses the request — auth or permissions failure | 403 = access denied to the resource. 405 = access to resource possible, method rejected. |
| 404 | Not Found | Resource does not exist at this URL | 404 = resource doesn't exist. 405 = resource exists, method not supported. |
| 406 | Not Acceptable | Server cannot produce a response matching Accept headers |
406 = content type mismatch. 405 = HTTP method mismatch. |
| 501 | Not Implemented | Server doesn't recognise or support the HTTP method at all | 501 = server has never heard of this method. 405 = server knows the method but won't allow it on this resource. |
Status code definitions per MDN Web Docs HTTP 405; RFC 9110 comparison from Axentix HTTP 405 guide.
7 Root Causes of HTTP 405
❌ Wrong HTTP Method in Client Code
Using GET where POST is required, or DELETE where only GET/POST are allowed. The most common cause by a large margin. Check the API documentation or the Allow header in the response before changing anything else.
🔧 Misconfigured Route Definition
In Express.js, Flask, Django, or similar frameworks, routes are defined per method. An endpoint defined only for GET returns 405 if called with POST. The framework is working correctly — the route registration is incomplete.
🌐 Wrong URL for the Intended Action
Sending a POST to /users/123 instead of /users, or hitting a read endpoint with a write method. REST API design commonly assigns different methods to different paths — pluralisation, versioning, and trailing slashes are frequent sources of these mismatches.
🛡️ WAF or Firewall Blocking the Method
Web Application Firewalls (WAF) and server-level security rules block specific HTTP methods for specific paths. TRACE is almost always blocked. DELETE and PUT are often restricted on shared hosting. ModSecurity rules can be overly aggressive.
⚙️ NGINX limit_except Misconfiguration
NGINX's limit_except directive restricts which methods a location block accepts. An incorrectly configured block that only permits GET will return 405 on any POST, PUT, or DELETE to that path.
📝 Apache .htaccess Method Restriction
LimitExcept directives in .htaccess or the main Apache config can restrict valid methods. A stray rule from a plugin or template can silently disable POST or PUT site-wide.
🤖 Anti-Bot Method Spoofing
Some websites deliberately return 405 in response to bot-like request patterns — even for valid methods — to confuse automated systems. As Scrapfly's 2026 guide documents: "Websites sometimes misconfigure their responses or misuse status codes to confuse bots." If you receive 405 from a protected target using a method that is demonstrably correct, this may be the cause.
3 Real-World Scenarios
REST API: Wrong Method for the Endpoint
A developer calls DELETE /api/users to remove all users in a test environment. The API only allows DELETE on /api/users/{id} — not on the collection endpoint. The server returns 405 with Allow: GET, POST. Fix: change the URL to /api/users/123 and retry with DELETE. The Allow header on the collection endpoint confirms GET and POST are the only valid methods there.
WordPress Site: Plugin Causing POST Block
A contact form stops working after a security plugin update. Every POST submission returns 405. The plugin added a LimitExcept GET HEAD rule to .htaccess that blocked all POST requests site-wide. Fix: remove or narrow the LimitExcept directive in .htaccess, or adjust the plugin's "restrict HTTP methods" setting.
Web Scraper: Anti-Bot 405 Masquerading as Real Error
A scraper sending GET requests to a product catalogue receives 405 Method Not Allowed, but the same URL loads normally in a browser. The Allow header in the response lists GET — confirming the method is technically permitted. The 405 is a deliberate anti-bot response triggered by the scraper's non-browser TLS fingerprint or request headers. Fix: rotate residential IPs, add realistic browser headers (User-Agent, Accept-Language, Accept), and use a browser automation tool that produces genuine browser TLS fingerprints.
How to Fix a 405 Error: Complete Checklist
Step 0: Read the Allow Header First
Before anything else, inspect the 405 response. The Allow header tells you exactly which methods the server accepts on that resource. With cURL:
curl -i -X GET https://api.example.com/endpoint # Or send an OPTIONS request to discover allowed methods without # triggering a full request: curl -i -X OPTIONS https://api.example.com/endpoint
If the method you need is listed in Allow, the problem is not the method itself — it is a WAF, an authentication requirement, or an anti-bot block. If your method is absent from Allow, you need to either use a different method or configure the server to permit yours.
For End Users
1. Refresh the Page and Retry
A cached browser state or expired session can cause a form to submit using an outdated URL or method. Hard-refresh (Ctrl+Shift+R / Cmd+Shift+R), clear cookies for the site, and retry the action.
2. Contact the Site Administrator
If the 405 appears on a form or interactive element, the problem is almost always a server-side configuration issue — not something a browser user can resolve. Report the error with the exact URL and action you were taking. Include any error ID displayed on the page.
For Developers
3. Verify the Method Against API Documentation
Check the official API documentation for the endpoint. Confirm which HTTP method it expects and match your client code accordingly. REST APIs follow a consistent pattern: GET for reads, POST for creates, PUT/PATCH for updates, DELETE for removals — but individual APIs deviate from these conventions.
4. Check Route Definitions in Your Framework
In Express.js, verify that the route registers the method you intend to use:
// Wrong — only GET registered:
app.get('/api/data', handler);
// Fix — add POST handler:
app.post('/api/data', handler);
// Or use router.all() to accept all methods (test environments only):
app.all('/api/data', handler);
In Flask, check the methods parameter: @app.route('/api/data', methods=['GET', 'POST']). In Django, ensure the view class or function handles the method being sent.
5. Fix CORS Preflight Handling
When a browser makes a cross-origin request with a non-simple method (PUT, DELETE, PATCH) or custom headers, it sends an OPTIONS preflight request first. If your server does not handle OPTIONS correctly — returning the proper Access-Control-Allow-Methods header — the browser never sends the actual request, and you receive a 405 in the console. Ensure your framework or middleware handles OPTIONS requests and returns the correct CORS headers.
6. Verify URL Structure
Double-check for trailing slashes (/users/ vs /users), version prefixes (/v1/ vs /v2/), and pluralisation (/user/ vs /users/). A correct method sent to the wrong URL variant hits a different route — one that may not support that method.
For Server Administrators
7. Fix NGINX limit_except Configuration
Review your NGINX config for limit_except directives that may be blocking valid methods:
# Overly restrictive — blocks POST, PUT, DELETE:
location /api/ {
limit_except GET HEAD {
deny all;
}
}
# Fix — allow required methods:
location /api/ {
limit_except GET HEAD POST PUT DELETE OPTIONS {
deny all;
}
}
8. Fix Apache .htaccess or httpd.conf
Check for LimitExcept directives that restrict valid methods. In .htaccess:
# Remove or update restrictive LimitExcept blocks:
<LimitExcept GET HEAD POST>
Require all denied
</LimitExcept>
# Ensure required methods (PUT, DELETE) are not in the deny list
Also verify that mod_allowmethods (Apache 2.4+) is not configured to block your required method.
9. Review WAF Rules
Check your Web Application Firewall for rules that block HTTP methods for specific paths. In Cloudflare, go to Security → WAF → Custom Rules and look for method-based blocking rules. In ModSecurity, review the SecRule directives that reference REQUEST_METHOD. Temporarily bypass WAF rules in test mode to confirm whether the WAF is the cause.
405 in Web Scraping: The Anti-Bot Angle
For developers running web scraping pipelines, 405 errors fall into two categories with different root causes and fixes:
- Genuine method errors — your scraper is using the wrong HTTP method. Check the
Allowheader, verify the correct method against the target's API documentation, and update your code. - Anti-bot method rejection — the server returns 405 even for valid methods when it detects automated traffic patterns. The
Allowheader lists your method as valid, but the 405 still occurs.
Identifying the second type: open the same URL in a real browser while using DevTools to inspect the request. If the browser gets a 200 using the same method your scraper sent, the rejection is based on the request's bot signals — not the method itself.
Fixing anti-bot 405 responses requires addressing the signals that triggered detection: browser-like request headers (User-Agent, Accept, Accept-Language, Accept-Encoding), realistic TLS fingerprints, and clean residential IP addresses that carry user-level trust scores. Nstproxy's residential proxy network provides IPs that pass the IP-layer checks, while scraping frameworks like Playwright or Puppeteer handle the browser-level fingerprint layer. See Nstproxy's high-anonymity proxy guide for request configuration details.
If you consistently receive 405 from protected targets despite correct methods, the proxy-based scraping guide covers the full stack approach for bypassing method-based anti-bot responses.
Bypass Anti-Bot 405 Responses with Clean Residential IPs
Nstproxy's 110M+ residential proxies provide the IP-layer trust signals that prevent method-based anti-bot rejections — combined with browser-realistic headers, most 405 anti-bot blocks resolve immediately.
Conclusion
HTTP 405 is precise and actionable. It tells you the resource exists, your request syntax is valid, and authentication is not the issue — the only problem is the HTTP method. The Allow header in the 405 response tells you exactly what to use instead. Read it before doing anything else.
For developers, the fix is almost always in client code (wrong method) or route definitions (missing method handler). For server administrators, NGINX limit_except directives and Apache LimitExcept blocks are the most common misconfiguration sources. For web scrapers, the distinction between a genuine method error and an anti-bot 405 determines the entire fix strategy — one requires changing your request, the other requires changing your proxy and headers.
Frequently Asked Questions
HTTP 405 means "Method Not Allowed." The server received your request, found the resource at the URL you specified, but rejected the HTTP method you used (GET, POST, PUT, DELETE, etc.) because that method is not supported for that specific resource. Per RFC 9110, the server must include an Allow header listing which methods are permitted — always check that header for the correct method to use.
A 404 means the server could not find the resource at the URL you requested — the resource does not exist. A 405 means the resource exists at that URL, but the HTTP method you used is not supported for it. If you receive 405, the URL is correct; if you receive 404, the URL itself is the problem.
Two ways: (1) read the Allow header in the 405 response — the server is required by RFC 9110 to include it; (2) send an OPTIONS request to the URL (curl -X OPTIONS https://example.com/endpoint -i), which returns the Allow header without triggering the actual action. The listed methods are the valid ones for that resource.
Some websites deliberately return 405 responses to automated traffic as an anti-bot measure — even when the request uses the correct HTTP method. This is confirmed when the same URL loads normally in a browser using the same method. In these cases, the rejection is triggered by bot-detection signals: non-browser TLS fingerprints, suspicious User-Agent strings, missing Accept headers, or datacenter IP addresses. The fix involves using browser-like request headers and routing scraping traffic through residential proxies with clean IP reputation.
It is classified as a client error (4xx range) because the client is using a method the server cannot process for that resource. However, the underlying cause is often a server-side configuration problem — a misconfigured route, a WAF rule, or an .htaccess directive that incorrectly blocks valid methods. The classification means the client request is technically the proximate cause (wrong method sent), but the fix often lies on the server side (configuration needs to be updated to permit the required method).

