发布前必须做故障模拟，否则上线后大概率救火；需用tc模拟网络抖动验证被动检查灵敏性、压测健康端点真实性、构造半死不活状态检验failover策略、验证监控闭环可用性。
发布前不做故障模拟，上线后大概率要救火。Nginx 健康检查的可靠性不能靠“看起来正常”来判断，必须在受控环境下复现真实故障场景，验证它能否及时识别、准确隔离、平稳恢复。
一、用 tc 模拟网络层抖动，验证被动检查是否灵敏
很多雪崩始于专线瞬断或防火墙策略变更，不是服务挂了，而是建连失败。别等线上出事才反应：
- 在 Nginx 机器上执行：
tc qdisc add dev eth0 root netem loss 1% 25% delay 15ms 5ms，模拟偶发 SYN 丢包（非全断） - 同步调高
proxy_connect_timeout至实测建连峰值的 1.8 倍（例如实测 2.3s → 设为 4s），避免误判 - 关闭 keepalive：
keepalive 0;，强制每请求新建连接，放大闪断影响，快速触发重试行为 - 观察 error.log 中
connect timeout是否在 1–2 秒内集中出现，并确认对应 upstream 节点是否被标记为down
二、主动探测路径专项压测，验证健康端点是否真可靠
别只信 /health 返回 200，要验证它是否代表业务可服务：
- 用 curl 并发 50 路反复请求后端
/ready接口（不走业务链路），同时抓包：tcpdump -i any port 8080 -w ready.pcap - 检查响应时间分布：若 P95 > 3s 或出现超时，说明该端点本身有瓶颈，不能作为健康依据
- 手动 kill 后端进程，看 Nginx 主动探测（
nginx_upstream_check_module）是否在fall × interval内（如 fall=5, interval=3s → 最多 15s）下线节点 - 重启后端服务，确认
rise=2是否防止偶发 GC 导致的短暂 503 误判，避免频繁上下线
三、构造“半死不活”状态，检验 failover 策略是否兜得住
最危险的不是全挂，而是部分功能降级、响应极慢、间歇性 502——这类节点最容易被默认配置漏判：
- 在某台后端上注入延迟：
sleep 8在/health响应前，使其超时但未断连 - 检查 Nginx 是否因
proxy_read_timeout触发proxy_next_upstream timeout，并成功转发到其他节点 - 确认 access.log 中该节点的
$upstream_addr出现频次是否显著下降，且$upstream_http_x_backend_status标记为 unhealthy - 用
ss -tnp | grep :80 | wc -l查连接数，确保未因重试耗尽 worker_connections
四、验证监控闭环是否真正可用
健康检查的价值，最终体现在能否被看见、被告警、被追溯：
- 访问
/status或 stub_status 接口，确认各节点 state、fails、rise 字段实时更新 - 用 Prometheus 抓取指标，设置规则：当
nginx_upstream_check_fails_total{upstream="api"} > 3持续 2 分钟即告警 - 回放一次故障过程，比对告警时间与 error.log 首次出现
no live upstreams的时间差，应 ≤ 15 秒 - 导出故障时段 access.log，用
awk '$9==502 {print $7}'统计失败路径，确认是否集中在已下线节点关联接口
