502 一来就重启 PHP

早期遇到 502，我的第一反应是重启 PHP-FPM。有时候真好了，于是当成经验。后来才发现，多数时候只是碰巧赶上了恢复，问题还在，过一阵又冒出来。

502 的意思是网关联系上游失败，或者上游给了它看不懂的响应。网关本身是活的——它能返回 502，说明它还在工作。

三种码，三条路

502：上游连不上、连接被重置、响应格式不对。常见于后端进程挂了、端口配错、请求头过大被拒。

503：网关在，但没有可用的上游，或者主动维护、限流。多见于后端实例全部不健康、并发打满。

504：网关等上游超时。上游可能还活着，只是处理太慢，也可能是到后端这一段网络不通。

看着都是 5xx，动作完全不一样：502 查后端进程和端口，503 查实例健康和限流，504 查慢查询和后端超时设置。

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

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

响应内容也在提供线索

错误页是网关默认页，说明请求到了网关、但上游没给正常响应。错误页是应用自己渲染的，说明请求已经打到应用，问题在应用内部。

响应头里的 Server、缓存标识也值得看。很多 502 其实来自 CDN 节点，源站根本没事，这时候去重启后端纯属白费。

用节点分布划范围

在宝塔拨测的控制台做 HTTP 监控，从多个地区、多个运营商的节点访问目标地址，记录状态码、响应时间和返回内容。

所有节点一起 5xx，是源站或网关的全局问题。只有部分节点 5xx，可能是某个 CDN 边缘节点、某条线路，或者灰度发布的区域。

平均、最快、最慢放在一起看，如果只有最慢的节点报 504，那是超时类问题，不是全站崩溃。

分段耗时帮忙分型

TTFB 很长然后 504，说明网关一直等到超时，问题在上游处理时间。

TCP 连接阶段就失败，说明端口或网络不通，网关压根没连上后端。

TLS 正常但等了很久没有响应，常见于后端线程池打满，或者数据库锁等待。

这些判断不需要先登机器。用外部结果把范围缩小，再去看日志，效率高得多。

复测与告警

间歇性 5xx 最坑，测一次正常就以为恢复了。连续复测几轮，看错误是不是稳定出现在同一批节点、同一个时间段。

把状态码纳入定时监控，用连续失败次数触发告警，比盯响应时间更直接。

该警惕的是：大面积 5xx 同时静态资源也失败，错误页开始出现堆栈或内部地址，间歇 5xx 的频率在上升。这几种别等，先回滚最近一次变更，再慢慢定位。