501 一出现就想重启

看到监控里冒出 501，我第一反应是服务挂了，登录重启了一遍，状态码照旧。后来才发现，请求根本没打到应用，是前面的网关不认这个请求方法。

501 不是「坏了」，是「不支持」。这个区别决定了你要动的是哪一层。

501 和 405 差在哪

405：这个地址存在，但不接受你用的方法。服务器知道你想干什么，只是不允许。

501：服务器不认识这个功能或者方法，压根没能力处理。它不是权限问题，是能力问题。

现实里两者经常被中间的代理混用。所以光看状态码不够，还得看是谁回的。

宝塔拨测控制台：定时拨测任务、节点与告警配置

宝塔拨测控制台：定时拨测任务、节点与告警配置

谁在返回 501

最常见的是网关和防护层。WAF、CDN、负载均衡通常有一份允许的方法白名单，白名单外的请求直接 501，根本不会往后传。

有些后端框架对不认识的 HTTP 方法也返回 501，尤其是老版本或者自定义路由。

还有一种：客户端发了非标准方法，或者 HTTP/2 配置有问题，中间层解析不了，就回 501。

TRACE、TRACK 这类方法在多数环境里本来就被禁用，监控如果用了不常见的方法，501 属于预期结果，改监控配置就行，不用动服务端。

响应内容能指认来源

看响应头里的 Server、网关标识，看错误页的样式，看有没有请求 ID。这些能区分是 Nginx 自己回的、CDN 回的，还是应用回的。

错误页带的是中间件默认模板，基本可以确定没到应用。错误页里有框架的调试信息，就该去查应用路由。

用拨测把范围切开

在宝塔拨测的控制台配 HTTP 监控，同一域名下测两个路径：一个静态文件，一个接口。

静态文件也 501，问题在网关或防护层；只有接口 501，问题可能在应用，或者那条转发规则。

多地区多运营商节点一起跑，看是所有节点一致，还是只有局部。全部 501 是统一策略，局部 501 更像某个边缘节点的配置没同步。

响应时间的分布也能帮忙：TTFB 极短就返回 501，说明是快速拒绝，不是后端处理超时。

复测和判断边界

改完方法白名单或路由配置，用同一批节点复测，确认原来 501 的路径恢复正常，同时别的路径没有被打坏。

连续测两三次，排除缓存和灰度造成的假象。

该警惕的是：GET 请求也 501，说明网关层配置出了问题；501 和 502 交替出现，可能是上游不稳；监控里突然大面积 501，先看最近有没有人改过 WAF 或 CDN 规则。

501 这个码，更多时候是在提醒你「请求没走通」，而不是「服务器坏了」。