事情本身不复杂，线索都在日志里。自研巡检脚本里只有两个分支，200 算正常，404 记死链，其余状态码直接跳过。跑了一个月，报告里 5xx 一条没有，实际日志里有 400 多条 502 和 503 没被记录。
第一反应是「报告只写通过和不通过 没有中间状态」，验证下来不成立。
这类报错背后常见的原因有几处，逐个排除就行。脚本只判断两个状态码 其余落进 else 被丢弃。还有一种是5xx 页面重试后返回 200 巡检只取最后一次。
不容易想到的是，巡检没有记录响应时间 慢页面看不出来。
第一件事是按状态码统计巡检结果
awk '{print $2}' check_result.txt | sort | uniq -c | sort -rn随后把 5xx 单独归一类并保留样本
if [ $code -ge 500 ]; then echo "$url $code" >> error5xx.txt; fi再往下记录每次请求的耗时
curl -s -o /dev/null -w '%{http_code} %{time_total}\n' "$url"失败地址重试两次再判定
for i in 1 2; do curl -s -o /dev/null -w '%{http_code}\n' "$url"; sleep 2; done恢复的判定其实很直接。巡检报告里能看到 5xx 的计数和样本地址，与源站日志的数字对得上。
补一句。巡检脚本的分支要覆盖所有状态码，else 里丢掉的往往正是最该看的那一类。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。