How is 501 different from 405 Method Not Allowed?

Scope. A 405 means the server knows what your method is but won't allow it *for this particular resource* — `DELETE` on a read-only endpoint, say — and RFC 9110 requires it to send an `Allow` header listing what you can use instead. A 501 means the server doesn't implement that method for *any* resource: it doesn't recognize `PATCH`, `PROPFIND`, or your custom verb at all, so there's nothing to list. Rule of thumb: 405 is a locked door with a sign telling you which doors open; 501 is a door the building was never built to have. That's also why 405 is a 4xx (you asked for the wrong thing) and 501 is a 5xx (the server admits it can't do the thing).

The same request works against the origin but fails through the CDN or proxy. Why?

Because the method has to be implemented at every hop, and the weakest hop wins. Your origin may handle `PATCH` or `PURGE` perfectly, but a reverse proxy, load balancer, or CDN in front of it may not forward methods it doesn't understand — it returns 501 itself and the request never reaches the origin. Test the origin directly (bypass the proxy, or use the origin IP with the right Host header). If the origin answers and the public URL returns 501, the intermediary is the thing that doesn't implement your method.

Why does the 501 sometimes stick even after I fix the server?

Because 501 is cacheable by default. RFC 9110 lists it among the status codes a cache may store without explicit freshness headers, alongside 404, 405, and 410. So a proxy or CDN can hold onto a 501 and keep serving it after you've deployed the fix. If the error outlives the change, purge the cache for that path (or send `Cache-Control: no-store` on error responses) before you keep debugging a server that's already correct.

Views: 24

501 Not Implemented: Method Unknown, Not Blocked

501 Not Implemented means the server can't recognize the request method, not that it's blocked. Tell it from 405 and a proxy. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

You get 501 Not Implemented, and the natural reading — “something is broken on the server” — is only half right. 501 is a 5xx code, so yes, the server is owning the failure. But it’s a very specific admission, and the specificity is the fix. RFC 9110 §15.6.2 defines 501 as the response when the server does not support the functionality required to fulfill the request — and names the primary case: the server does not recognize the request method and cannot support it for any resource. Not “won’t.” Can’t. The method you sent is one the server has no code path for.

That one distinction rules out most of what people waste time on. A 501 is rarely a crash, a bug in your handler, or a bad payload — those give you 500. A 501 is the server saying the verb is foreign to it: you sent PATCH, PROPFIND, PURGE, or something more exotic, and either the server or something between you and it was never taught that method. So the question is never “why did my code fail?” It’s “who in this request’s path doesn’t implement this method?”

Symptoms

The response status line reads 501 Not Implemented; the body is often a generic server or proxy error page, not your application’s error format.
It appears for non-standard or less-common methods — PATCH, PUT, DELETE, WebDAV verbs, CDN PURGE — while plain GET/POST to the same host work fine.
A tool like Postman or curl reproduces it instantly; a browser rarely does, because browsers mostly send GET and POST.
The error may survive a deploy, because caches are allowed to store it.

Top 3 Causes

The server genuinely doesn’t implement the method - The honest case. You called PATCH on a stack that only wired up GET/POST, hit a WebDAV method (PROPFIND, MKCOL) on a server without WebDAV, or sent a typo’d or custom verb. IIS is explicit about this — it returns 501 for methods it doesn’t recognize — and most servers follow suit. The fix is to enable/implement the method, or to stop sending it.
A proxy, load balancer, or CDN in the path drops the method - The sneaky case, because your origin is fine. An intermediary that doesn’t understand a method can answer 501 on the origin’s behalf, so the request never lands. This is common with cache-control verbs (PURGE, BAN) and with older or minimally configured gateways. The tell: it works when you hit the origin directly and fails through the public hostname.
A gateway lost its upstream handler or is misrouting - A reverse proxy configured to hand certain methods to an application server that’s down, unmapped, or reconfigured can surface 501 rather than 502, especially when the method itself is what routing keys on. Here the method is implemented somewhere, but the path to that somewhere is broken.

Diagnose with DechoNet

HTTP Check shows the raw status and response headers for the URL. If a plain request returns 200 while your specific method returns 501, you’ve confirmed the site is up and the problem is method-scoped — now find which hop rejects the verb.
DNS Check reveals whether the hostname points at a proxy/CDN or straight at your origin. If it resolves to a CDN’s ranges, you have an intermediary that must implement the method too — the prime suspect when the origin works alone.

Resolution Checklist

Reproduce with the exact method: curl -X PATCH -i https://yourdomain.com/path. Confirm it’s the verb, not the path or body, by retrying the same URL with GET.
Test the origin directly, bypassing any proxy or CDN (use the origin IP with a correct Host header, or a staging URL). Origin works + public URL fails → the intermediary is your culprit.
If the server should support the method, enable it: turn on the WebDAV module, add the route/handler, or allow the method through the framework. If it legitimately shouldn’t, the caller needs to stop sending it — or you should return 405 with an Allow header so clients learn what is supported.
If a proxy/CDN drops the method, configure it to pass that verb upstream (many gateways whitelist methods explicitly). Confirm the request now reaches the origin logs.
Purge the path from any cache after fixing. 501 is cacheable by default, so a stale copy can keep serving the error over a server that’s already correct.

When to Escalate

If the origin implements the method, no proxy sits in front, and you still get 501, capture the full request and response headers. A 501 from software that clearly supports the verb points at a specific middlebox or WAF rule rewriting the request — find the box, not the bug.
If a managed platform or CDN returns 501 for a method you need (PURGE, PATCH), it’s their method allowlist, and the fix is a config setting or a support request on their side — not something you can patch at the origin.
If you meant to reject the method deliberately, don’t leave it as 501. 501 says “we can’t,” which invites clients to retry and cache to store the answer. Return 405 with a correct Allow header instead — it says “we can, just not this way,” and tells the client exactly what to do next.