故障恢复验证需确认5xx清零、upstream_status一致为200、error.log无emerg/alert报错、抽样接口响应稳定。
验证生产环境中故障恢复后的状态码，核心是确认异常是否真正消失、服务是否回归正常响应模式，而不是只看“有没有 5xx”。重点在于比对故障前后关键指标的一致性与稳定性。
查实时访问日志，聚焦 5xx 是否清零并稳定
故障刚恢复时，不能只扫一眼有没有报错。要连续观察几分钟的访问日志，确认 5xx 是否真正归零：
- 用结构化日志（如
status_first格式）快速提取：tail -n 1000 /var/log/nginx/status.log | awk '$1 ~ /^5[0-9]{2}$/ {print $0}' - 若返回为空，说明当前窗口无 5xx；若有输出，需结合时间戳判断是否属于残留请求或新发故障
- 特别注意 502/504 是否成批出现——单条可能是偶发，连续多条（尤其集中在同一分钟）说明后端仍不稳定
核对 upstream_status，确认失败环节已解除
仅看 $status=200 不代表后端真好了。必须同步检查 $upstream_status 字段：
-
$status=200且$upstream_status=200→ 后端响应正常，链路通畅 -
$status=200但$upstream_status="-"或超时值（如504）→ Nginx 仍收不到后端响应，只是自己缓存或 fallback 返回了 200，属“假恢复” - 执行命令：
awk '$1 == 200 && $11 != 200 {print $0}' /var/log/nginx/status.log | head -5（假设$upstream_status是第 11 字段）
比对错误日志时间点，确认无新增 emerg/alert 级报错
访问日志“看起来正常”，不代表底层没隐患。error.log 才是真相出口：
- 提取故障恢复时刻（比如 09:35:00），用该时间前后 2 分钟范围查 error.log：
sed -n '/09:34:5[0-9]/, /09:35:0[0-9]/p' /var/log/nginx/error.log - 重点关注
[emerg]、[alert]、[crit]级别日志，例如connect() failed、Connection refused、upstream timed out - 若该时段 error.log 完全静默，且此前报错已消失，才是可信的恢复信号
抽样验证典型路径，观察响应时间和状态一致性
自动化统计容易漏掉业务逻辑层问题。需人工或脚本抽样验证真实用户路径：
- 选取 3–5 个高频接口（如
/api/user/info、/healthz），用 curl 多次请求：for i in {1..5}; do curl -I -s http://localhost/api/healthz | head -1; done - 确认每次返回都是
HTTP/1.1 200 OK，且time_namelookup、time_connect、time_total波动不大（无明显毛刺） - 若某路径偶发 504 或耗时突增至 5s+，说明后端节点或数据库连接池尚未完全恢复
