一排 200，页面却是错的

监控报告里所有节点都是 200，我以为一切正常。用户发来截图，页面上写着「服务暂时不可用」。

状态码只说明请求被处理了，不说明结果是对的。有些应用出错也返回 200。那次差点把故障当成误报。200 也可能是缓存命中，内容对不对要看正文。

先看大类

2xx：请求成功。但成功不等于内容正确。

3xx：跳转。看跳到哪，以及跳几次。301 和 302 的差别在缓存，临时和永久处理不同，别把所有 3xx 当成故障，那会误伤。

4xx：请求或权限问题。403 是被拒绝，可能是 WAF 也可能是权限，看响应内容能区分；404 是不存在；429 是限流，常被忽略，它说明被限流了。

5xx：服务端问题。500 是程序错，502 是网关连不上上游，504 是等上游超时。先看是网关回的还是应用回的，看响应头里的标识。

大类定了，排查方向基本就定了。状态码不是越少越好，有些跳转是必要的，关键是符合预期，预期是什么要提前定。比如登录跳转就是正常 302，静态资源 304 也正常。

再看分布

用宝塔拨测的网站测速跑多地区多运营商节点，同一 URL 可能有的 200、有的 502。

全部节点同码，是全局问题。

只有部分节点异常，偏 CDN 边缘、区域策略或单台后端，这类问题最容易被平均值掩盖。

按运营商分组，能看出边界在哪，分布比单点有用。

看是否持续

偶发一次 5xx，先复测，别急着叫醒所有人。

连续几次都出现，才是稳定故障。

间歇性 502 最麻烦，往往意味着某个上游实例不健康，轮询到才报错。持续性是定性的关键。

和分段配合

4xx 通常 TTFB 很短，因为被快速拒绝。

504 的 TTFB 会接近网关超时阈值。

502 的 TTFB 可长可短，短的是连接被拒，长的是上游崩溃。

状态码定性，分段定量，两者结合才完整。

复测与记录

连测三次，看状态码是否稳定，再决定是单次抖动还是真故障。

记录节点、时间、状态码和响应片段，记录要能复核。监控告警只报偏离基线的，噪音少很多。

只写「200，正常」的报告，等于没写。第一步分类，第二分布，第三持续，三步走完再谈修复；修复后复测同样的三步，看是否回到基线。没回到基线就不算修好，不要自我安慰。数据不会骗人，只要你看得懂，多看看，慢慢练。

状态码是入口，不是结论。