同一个接口，浏览器页面有时能用，有时却报 405；直接把地址贴进浏览器又能打开。这些操作可能根本没发送同一种请求。地址栏通常发出 GET，页面脚本可能发送 POST，跨域情况下还可能先发送 OPTIONS。
405 Method Not Allowed 表示响应方认识这个请求方法，但目标资源不支持它。排查应先确认失败的是哪个方法、哪个最终地址，以及由哪一层返回错误。只改跨域响应头，或者把所有请求都改成 GET，可能掩盖真正的路由问题。
本文面向维护网站接口与 Nginx 反向代理的管理员，命令使用占位地址，未对读者站点做实测。涉及提交订单、支付、发邮件和删除等写入请求，必须在测试环境或通过获批准的无副作用流程复现，避免重复业务操作。
先确定失败的是 OPTIONS 还是实际请求
在浏览器开发者工具的 Network 面板中，找到失败请求，记录 Request Method、状态码、完整路径、重定向链和响应头。查询参数、Cookie 与请求体可能包含敏感数据，保存诊断资料前应脱敏。
如果失败的是 OPTIONS，实际 POST 或 PUT 可能还没有发出去。浏览器在某些跨域请求前会发送预检，询问目标是否接受预期的方法与请求头。普通 curl 请求不执行浏览器的 CORS 校验，因此“curl 能调用”不能排除预检失败。
如果 POST 本身返回 405，就需要检查目标路由是否支持 POST、代理是否把请求送到静态页面，以及跳转后地址是否仍然正确。跨域报错有时只是浏览器对错误响应的外在表现，不能代替服务端状态码分析。
没有在 Network 中看到失败响应，也可能是请求被客户端扩展、网络策略或其他检查阻止。应先区分有没有真正收到 HTTP 响应。
看 Allow，但不要把它当作权限开关
按照 HTTP 语义，405 响应应带有 Allow 头，列出该目标允许的方法。如果只列出 GET、HEAD，而客户端发送 POST，这是核查路由的直接线索。
实际系统中，错误页可能被代理替换，应用也可能未完整实现规范。没有 Allow 不能单凭这一点断言错误来自哪一层，应结合日志和请求标识继续定位。
Allow 与 Access-Control-Allow-Methods 用途不同。前者描述资源支持的方法，后者参与浏览器跨域授权；添加其中一个不会自动让应用多出一个 POST 路由。
405 也不同于 401、403 或 501。鉴权失败与方法不支持应分别处理。WAF 或网关可以自定义状态码，所以某次 405 仍可能由策略返回，不能仅凭数字判断是应用拒绝。
用受控请求保留每一跳
先观察原请求的跳转，不要一开始就自动跟随重定向。下面仅演示无副作用的 GET 检查：
curl -sS --max-time 30 \
-D response.headers -o response.body \
'https://api.example.com/status'
这里的域名与路径是占位符，需替换为明确允许读取的测试入口。-I 会发送 HEAD，它与 GET 也可能走不同处理逻辑，因此不能把 HEAD 的结果直接当作原请求结果。
对 OPTIONS 预检，可在获准的测试接口上显式模拟预期来源和请求方法：
curl -sS --max-time 30 -D preflight.headers -o preflight.body \
-X OPTIONS 'https://api.example.com/test-resource' \
-H 'Origin: https://www.example.com' \
-H 'Access-Control-Request-Method: POST' \
-H 'Access-Control-Request-Headers: content-type'
这些头应与真实浏览器请求一致；如实际使用 Authorization，也应检查预检声明中的相应头名，但不要在共享诊断命令中填入真实令牌。
curl 只展示服务响应，不会替你判断所有浏览器 CORS 条件。预检是否成功，还需对照允许来源、方法、请求头以及凭据策略，在浏览器里复验。
模拟写入请求时，不能为了排查随意重放生产请求。即使第一次返回错误，也可能已经在后端产生部分业务效果。
重定向可能改变实际方法和目标
HTTP 跳 HTTPS、域名统一、尾部斜杠规范化或登录跳转，都可能出现在接口请求途中。最终的 405 可能来自跳转目标，而非最初接口。
303 通常引导客户端以 GET 获取后续资源；301、302 在常见客户端处理中也可能使 POST 变为 GET；307、308 用于保持方法和请求体。实际行为还受客户端选项影响，应以捕获到的请求为准。
不要盲目用 curl -L -X POST 验证原客户端行为。显式指定方法可能与工具自动处理重定向的行为叠加，得到和浏览器不同的结果。跨主机跳转还需要评估凭据与请求体的传递边界。
更稳妥的方式是逐跳查看 Location、方法与状态，再修正客户端使用的规范 API 地址。修改重定向状态前，应确认不会破坏现有客户端及安全策略。
代理可能把 API 请求送进了静态目录
Nginx 的 location 匹配、rewrite、try_files 和 proxy_pass 路径拼接，共同决定请求最终落点。某条 /api/ 请求如果被送到静态文件处理器，POST 就可能得到与预期后端完全不同的响应。
重点核对以下对象：原始路径、代理转发后的路径、命中的上游，以及后端接收到的方法。proxy_pass 是否包含 URI、前缀替换与 rewrite 的组合，应按实际配置和官方文档判断，不能通过随意增删斜杠来碰运气。
还应检查有没有显式配置 proxy_method 改写上游方法，以及应用是否存在方法覆盖中间件。不要直接删掉所有方法限制；限制可能承担重要的安全作用。
Nginx 的 limit_except 可以按方法配置访问限制，但它不保证一定返回 405。实际状态由限制方式和后续处理决定，仍应读日志与生效配置。
读取配置时可在管理员授权下使用 nginx -T，但输出可能包含内部地址、认证配置和其他秘密，应仅在本机受控检查。修改配置前备份对应文件，用实际服务使用的二进制与参数执行语法检查，再安排重载和回滚。
用状态与上游日志定位响应层
如果已有访问日志记录 $request_method、$uri、$status、$upstream_status 和 $upstream_addr，可以按时间与请求标识关联。不要为了排查开启请求体、Cookie 或 Authorization 的全量日志。
上游状态为 405，通常提示上游返回了该错误；没有上游状态，可能意味着请求未走上游，但也可能受日志格式、变量值和其他处理流程影响。两者都需要结合配置核实。
当 CDN、WAF、Nginx 和应用都有错误页时，Server 头或页面样式只能提供线索。自定义头也可能被覆盖，不能当成确定证据。通过受控源站诊断与各层日志对照更可靠，不要为此关闭源站保护或 TLS 校验。
偶发问题还应检查多节点是否版本一致。部分实例有新路由、部分仍是旧版本，或不同域名落入不同虚拟主机，都可能让同样请求表现不稳定。
预检处理要与真实接口能力一致
如果已经确认应用支持 POST，只是跨域 OPTIONS 没有被正确处理，可以在应用或统一网关中实现符合策略的预检响应。选定一层负责，避免代理和应用重复添加冲突响应头。
成功预检通常使用成功状态，例如 204，并按实际策略返回允许来源、方法和请求头。不能用“所有 OPTIONS 一律放行”替代接口能力和权限审查。
带凭据的跨域请求不能依靠通配来源 * 授权。动态返回来源时，应严格校验允许列表，并考虑 Vary: Origin 与共享缓存行为；不能原样反射任意来源。
即使预检成功，实际请求也仍需鉴权、权限校验和适当的跨域响应头。预检不是业务授权。修改后要验证非法来源、未登录和无权限请求依然被正确拒绝。
缓存也会让旧 405 看起来还在发生
405 属于 HTTP 规范允许进行启发式缓存的状态之一，但具体缓存资格仍受请求方法、响应指令和产品规则限制。这不表示所有 POST 错误都会被 CDN 缓存。
如果接口已修复，部分节点仍返回旧错误，应核实 Age、缓存状态字段和对应规则。确认存在旧条目后，定向处理相关缓存；不要直接全站清空或用随机参数代替原地址验收。
预检缓存与普通 HTTP 页面缓存也不同。浏览器可能缓存之前的预检授权结果，验证时需结合测试环境和实际浏览器行为，不要认为刷新页面必然让所有预检重新发生。
验收要覆盖方法、身份和入口
对目标路由列出预期支持与不支持的方法。使用测试数据检查浏览器真实调用、合法来源预检和不受支持方法的响应，并确认重定向前后没有意外改变调用语义。
同时验证匿名与登录态、CDN 与受控源站、多实例以及尾部斜杠等实际入口。测试请求应数量有限且可追踪，避免排查流量本身触发限流。
保留原规则、应用版本和回滚步骤。完成后记录哪层返回了 405、原方法被送到了哪里、具体修改了什么。这样下次出现同类症状时，就不必再从“给所有响应加跨域头”开始试错。
参考资料
核验日期：2026-11-04。以下为 MDN HTTP 文档与 Nginx 官方文档。客户端、框架和代理的实际行为需结合当前版本核对。