核心是验证故障发现—隔离—恢复机制是否可靠：502演练模拟上游不可达以检验快速剔除与流量切换，504演练模拟响应缓慢以验证超时参数合理性；须用iptables/tc等可控方式注入故障，并实时观测Nginx、上游、客户端三层指标，确认max_fails/fail_timeout生效及主动健康检查效果。
验证生产环境中 Nginx 的高可用灾备能力，核心不是“能不能切”，而是“切得准、切得快、不误切”。502 和 504 故障本身是现象，而灾备演练的目标是检验整套故障发现—隔离—恢复机制是否可靠。下面从实操角度给出可落地的验证方法。
明确演练目标：区分 502 与 504 的触发路径
502 和 504 虽然都由上游异常引发，但背后机制完全不同，必须分开验证：
- 502 演练重点：模拟上游服务完全不可达（如进程崩溃、端口未监听、防火墙拦截），验证 Nginx 是否能快速识别失败、剔除节点、将流量导向健康实例；
- 504 演练重点：模拟上游响应缓慢（如人为加 sleep、数据库慢查询、线程池打满），验证超时参数是否合理、Nginx 是否不提前中断连接、下游是否感知为超时而非错误。
设计可控的故障注入方式
避免直接 kill 进程或关机——这无法复现真实业务中“部分请求失败”或“偶发超时”的场景。推荐以下安全可控的方式：
- 对上游服务添加临时路由：比如在 Node.js/Java 服务中，新增
/health/bad接口，返回非标准 HTTP 响应（如空 body、非法 header）来触发 502； - 用 iptables 或 tc 模拟网络异常：例如
iptables -A OUTPUT -p tcp --dport 8000 -j REJECT拒绝出向连接，精准复现 “Connection refused” 类 502； - 用
tc加入延迟和丢包：tc qdisc add dev eth0 root netem delay 5000ms loss 20%，观察 Nginx 是否因读取响应超时而返回 504； - 限制上游资源：用 cgroups 或容器 limit 限制 CPU / 内存，诱发 OOM 或响应阻塞，观察是否出现 “Connection reset by peer” 类 502。
关键指标必须实时观测
光看页面是否返回 502/504 不够，要验证灾备是否生效，需同步采集三类数据：
-
Nginx 层：用
log_format记录$upstream_addr、$upstream_status、$upstream_response_time，确认失败是否集中在某台后端，且后续请求是否已分发到其他地址； - 上游层：检查被故障注入的服务日志，确认其确实收到请求、返回了异常响应（如 500、空响应、RST 包），排除 Nginx 配置误判；
- 客户端层：用 curl 或压测工具（如 wrk）持续请求，统计错误率、P95 延迟、成功切换时间（从首例 502 出现到连续 10 秒无 502 的间隔）。
验证 fail_timeout 与 max_fails 是否生效
原生 Nginx 不主动探测，依赖被动失败计数。必须验证该机制在真实流量下是否按预期工作：
- 设置
max_fails=1 fail_timeout=10s，然后注入一次失败，观察接下来 10 秒内该 upstream 是否真的不再收请求（通过 access.log 或$upstream_addr日志确认）； - 故意把
fail_timeout设得很短（如 2s），再反复触发失败，看是否出现“刚恢复又剔除”的震荡； - 对比开启
health_check（需 stream 模块或 Plus 版本）后的表现，验证主动探测能否缩短故障发现时间。
