网站调试里最容易误判的状态码之一就是 405：URL 是对的、文件也存在，只要换个请求方式就报错。很多人把它当 404 去查路径，或当 403 去查权限，方向一错就白折腾半天。本文按「先弄懂协议定义、再看 Allow 头、最后按服务器类型改配置」的顺序讲清 405 Method Not Allowed，所引页面均实测可访问。

一、405 的准确定义：服务器认得这个方法，但这个资源不接受

MDN 的 405 页面原文写得很明确：The 405 Method Not Allowed status code indicates that the server knows the request method, but the target resource doesn't support this method。中文页（zh-CN 同页）的概括是「状态码 405 Method Not Allowed 表明服务器禁止了使用当前 HTTP 方法的请求」。

关键在「服务器知道这是合法的 HTTP 方法」，只是这个资源不允许用它。这一点决定了它与相邻几个码的分界，RFC 9110（HTTP Semantics）第 9.1 节给出判据：

• 方法无法识别或未实现，应返回 501 Not Implemented。
• 方法已识别且已实现、但目标资源不允许，应返回 405 Method Not Allowed。

再和两个常被混淆的码区分：

• 404：资源根本不存在。把 POST 换成 GET 一样 404，说明与方法无关。
• 403：资源在、方法也支持，只是你的身份没资格。由 405 变 403，意味着要查权限而不是查路由。

MDN 还提醒了一个被忽略的成因：文件或目录的服务端权限设置不当，也可能造成 405 而不是 403，这在 Windows 与 IIS 站点上尤其常见。

二、第一现场：一定要看响应里的 Allow 头

RFC 9110 第 10.2.1 节对 Allow 有强制性要求：An origin server MUST generate an Allow header field in a 405 response。所以合规的 405 响应一定带 Allow，列出该资源此刻支持的方法。MDN 给的典型响应（服务器禁用 TRACE 的场景）如下：

TRACE / HTTP/1.1
Host: example.com
HTTP/1.1 405 Method Not Allowed
Content-Length: 0
Allow: GET, POST, HEAD

看到 Allow 值为 GET、POST、HEAD，结论立刻清晰：你想发的 PUT 这个资源压根没开。反过来，如果 Allow 里明明包含你要用的方法却仍 405，问题多半在中间的代理、CDN 或 WAF 改写了方法，而不是源站。RFC 还补了一句：Allow 值为空表示该资源不允许任何方法，通常出现在资源被配置临时禁用时。

抓响应头的命令，任选一条：

curl -v -X POST 你的域名/api/item（看完整头与状态行）
curl -s -o NUL -D - -X PUT 你的域名/api/item（只要响应头，Linux 下把 NUL 换成 /dev/null）
curl -s -X OPTIONS -i 你的域名/api/item（主动问资源支持哪些方法）

三、六种真实成因，逐条对号入座

成因 1：静态目录被显式限制了方法。Nginx 的 limit_except 指令用来只放行指定方法，写法是 location /uploads/ { limit_except GET HEAD { deny all; } }。配置之后，任何 POST、PUT、DELETE 到 uploads 目录的请求都会拿到 405。另外 dav_methods 没开启时，向该位置发 PUT 也是 405，而不是你以为的 404。

成因 2：IIS 的 WebDAV 模块劫持了 PUT 与 DELETE。这是 ASP.NET 站点上传文件报 405 的头号原因：WebDAV 抢先处理 PUT、DELETE、MKCOL 等动词，认证又没配对，最终回 405。若站点不用 WebDAV，在 web.config 的 system.webServer 下先在 modules 里 remove 名为 WebDAVModule 的模块，再在 handlers 里 remove 名为 WebDAV 的处理程序；若确实要用 WebDAV，则应改配它的作者规则与 verbs，而不是简单删模块。

成因 3：后端路由没注册这个动词。以 Spring MVC 为例（官方 RequestMapping 文档），@RequestMapping(value="/item/{id}", method=RequestMethod.PUT) 一旦限定了 method，其它方法请求同一 URL 就是 405，且 Allow 里会带 PUT。常见错法是只写了 @PostMapping，前端却用 GET 取详情，补一个 @GetMapping 或让前端改方法即可。

成因 4：表单或 fetch 的 method 没写。HTML 表单只支持 GET 与 POST，写成 delete 会被浏览器降级；接口只接受 POST 时，前端 fetch(url) 不带 method: "POST"（默认 GET）也会撞 405。

成因 5：TRACE 被安全策略关闭。MDN 原文指出服务器常因安全考虑禁用 TRACE，因为它可被用于跨站追踪 XST。用 curl -X TRACE 探测几乎必得 405，这是正常安全配置，不必修复。

成因 6：中间层改了方法。部分代理、CDN、负载均衡在缓存命中或协议降级时把 POST 变 GET，或拦截自定义动词。判据简单：直连源站正常、经代理 405，责任在中间层。

四、Apache 与 Nginx 的配置对照

Apache 侧对应指令是 core 模块的 Limit 与 LimitExcept，典型写法是在 Directory 块里写 LimitExcept GET HEAD 然后 Require all denied。两套服务器的语义方向容易搞反：Apache 的 LimitExcept 是「除这些方法外都拒绝」，Nginx 的 limit_except 是「在这些方法范围内施加规则」，迁移配置时最常写反。

PHP 内置服务器也有同类坑：用 php -S localhost:8000 本地联调时，它对非 GET、POST、HEAD 支持很弱，PUT 与 DELETE 常直接 405。这时应换 Nginx 加 PHP-FPM 复现，别怀疑自己的业务代码。

五、前端与 CORS：预检失败也长得像 405

浏览器发起跨域的 PUT 或 DELETE 前会先发 OPTIONS 预检。若服务器没处理 OPTIONS 而返回 405，控制台报的却是 CORS 错误，极易误判。正确做法是放行预检并返回这几个头：Access-Control-Allow-Origin、Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS、Access-Control-Allow-Headers: Content-Type, Authorization、Access-Control-Max-Age: 86400。

排查顺序建议先在 Network 面板确认失败的是 OPTIONS 还是真正的业务请求：失败的是 OPTIONS，说明是预检被拦，而不是业务方法不支持。

六、常见问题 FAQ

问：返回 405 但没有 Allow 头，正常吗？
答：不合规。RFC 9110 明确要求 405 必须带 Allow。确实没有时，不能靠 Allow 判断支持范围，要直接查服务器配置。

问：405 会不会影响 SEO？
答：会，但方式与 404 不同。搜索引擎默认以 GET 抓取，GET 正常一般不影响收录；若页面 GET 也 405（比如误配成只允许 POST），等于整站不可索引，必须尽快修正。

问：怎么快速判断是方法问题还是路径问题？
答：同一 URL 分别用 GET 和 POST 各请求一次。两种方法都 404 是路径问题；GET 正常、POST 报 405 是方法未被支持，查路由或服务器限制。

问：上传文件报 405，改前端有用吗？
答：通常没有。上传场景的 405 绝大多数来自 IIS WebDAV 模块或 Nginx 未开 dav 方法，应在服务端配置层解决。

七、总结

处理 405 的路径只有一条：先用 curl -v -X 读到 Allow 头，确认资源到底支持什么；再按类型定位配置，Nginx 查 limit_except 与 dav_methods，Apache 查 LimitExcept，IIS 查 WebDAV 模块与处理程序映射，框架层查路由的方法注解；最后确认中间代理有没有改写方法。记住协议分界：方法不认识是 501，方法认识但资源不允许是 405，资源不存在是 404，资源在方法也对但没权限是 403。

• IIS
• nginx
• 405
• HTTP状态码
• WebDAV