网关不是一台机器

很多人以为「网关」就是 Nginx。实际从用户到代码之间可能站着一串：CDN 边缘、四层或七层负载均衡、反向代理、Ingress、Sidecar。

每一层都可能成为网关，也都可能返回 502。所以看到错误页，第一件事不是翻日志，而是问一句：这个页面是谁回的？

错误页会留下指纹

各家的默认错误页长得不一样，Server 头、页面里的标识、排版细节都能说明来源。CDN 的 502 通常带自己的标识，Nginx 是大家都熟的那一页，云厂商的负载均衡又是另一套。

如果错误页是应用自己渲染的，说明请求已经打到应用层，这时候去查网关方向就反了。

很多网关还会在响应头里带上链路标识，比如上游地址、节点编号。这些信息在排查时很值钱，能看出请求最终落到了哪台后端。

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

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

同一句 502，可能差着好几跳

用户说 502，实际可能是 CDN 回源时连接被拒绝，也可能是源站 Nginx 连不上应用。前一种情况，源站日志里可能一条记录都没有。

判断方法很实际：同时测一个静态文件和一个动态接口。静态文件也 502，问题更靠前；只有动态接口 502，问题在后端应用。

用节点分布缩小范围

在宝塔拨测的控制台做 HTTP 监控，从多个地区、多个运营商的节点请求同一路径，记录状态码和响应时间。

所有节点同时 5xx，问题在公共路径上——源站、统一入口。只有某几个地区 5xx，先怀疑那些地区的边缘节点或线路，源站可能完全正常。

按运营商分组，还能看出某条线路回源是不是异常。

时间也在说话

TTFB 很短就返回 502，说明网关很快判定上游不可用，通常是对端连接被拒、进程没起。

TTFB 很长才返回 502 或 504，说明网关一直在等，最后放弃，问题出在后端处理速度。

TCP 阶段就失败，那连网关都没到，属于端口或网络层的问题。

还有一种：TCP 建连很快、TLS 也正常，但网关迟迟不返回任何字节，最后超时。这种情况多半是后端接了连接却不处理，线程池已经满了。

复测与判断边界

间歇性 502 最难查，可能是后端某个实例不健康，轮询到它时才报错。连续复测几轮，再对比不同路径，能判断是不是单实例的问题。

把 5xx 纳入定时监控，连续失败触发告警。别用单次结果下结论，也别在没弄清哪一跳出错之前就改配置——改错了，现场就没了。