监控 502，我却打不开监控的结论

告警说 502，我打开浏览器，页面正常。第一反应是误报，差点把告警关了。

后来才知道，监控走的是另一个地区、另一条路径，正好撞上了有问题的节点。那次之后我学会先看「哪台、哪个地区」，再谈真假。

先确认是不是同一条路

监控测的 URL、参数、方法、协议，和你打开的是不是一致？

带参数的动态接口和首页，走的可能是不同的后端。http 和 https 也可能落到不同配置。

如果监控测的是接口，而你打开的是首页，两边结论不同很正常。把监控配置和浏览器地址栏逐项对一遍，差异很快就能发现。

节点分布决定范围

用宝塔拨测的网站测速跑多地区多运营商节点，看 502 出现在哪。

所有节点都 502，是源站或统一入口的问题；只有部分节点，偏 CDN 边缘、区域策略；只有一个节点，先怀疑那个节点自己。

平均、最快、最慢一起看，能判断是持续还是偶发。也可以对照源站日志里的请求来源，确认哪些节点的请求压根没到。

静态资源也 502，更像网关或源站整体问题；只有接口 502，偏应用。

间歇性 502，多半是上游

上游有多个实例，其中一个不健康，负载轮询到它时才报错。

表现是刷新几次就正常，过一会儿又来一次。这时候健康检查和实例日志比什么都重要。

还有连接池打满、后端超时被网关判定失败，也会间歇性返回 502。发布过程中新实例没起来、旧实例已经被摘掉，也会出现短暂空窗。

分段耗时帮着定性

TTFB 很短就 502，说明网关快速拒绝，通常连不上上游。

TTFB 很长才 502，说明等到了超时，问题在上游处理慢。

这两种处理方向完全不同，别混在一起改。如果 TCP 阶段就失败，那压根不是 502 的问题，是更下面的连接问题。

复测和验证

用同一路径、同一批节点连测几次，记录每次的结果和时间点，再和源站日志对齐。

如果改完配置，复测要看原来出问题的节点是否恢复，而不是只看自己电脑。别只测一次就下结论，间歇性问题最会躲。

告警阈值也要复核。有些平台单次失败就算一次告警，很容易被偶发打爆。把监控频率和超时设置贴出来看，很多「误报」其实是超时设得太短。先分类，再决定要不要叫醒人。

页面能打开，不代表服务没毛病，也不代表其他地区没事。它只是说明你走的这条路，暂时是通的。