Nginx 中健康检查如何测试后端服务突发崩溃时的自动故障转移效率

Nginx故障转移效率测试需模拟可控突发崩溃，结合被动检查（max_fails/fail_timeout）与主动探测（nginx_upstream_check_module），观测首挫延迟、零失败窗口、误恢复风险等指标。

要测试 Nginx 在后端服务突发崩溃时的自动故障转移效率，核心是模拟真实故障场景，并观察 Nginx 从检测失败、剔除节点、重试请求到流量完全绕过的全过程耗时与成功率。关键不在于“是否能切”，而在于“多快切稳、是否误切、会不会反复试探坏节点”。

构造可控的突发崩溃场景

避免用 kill -9 随机中断进程——这可能导致连接未及时断开、Nginx 无法立即感知。推荐方式：

1. 在目标后端服务上部署一个可触发的 /crash 接口（如 Spring Boot 的 Actuator + 自定义 endpoint），调用后立即终止主线程并关闭端口
2. 或使用 iptables 拦截特定后端 IP:PORT 的所有入向连接：iptables -A INPUT -s 192.168.1.10 -p tcp --dport 8080 -j REJECT，模拟网络层瞬断
3. 配合 curl 或 ab 工具持续发起请求（如 watch -n 0.2 'curl -s -o /dev/null -w "%{http_code}n" http://gateway/api/test'），实时观察响应码变化

验证被动容错的实际响应时间

被动检查依赖真实请求失败，其效率直接受 max_fails 和 fail_timeout 控制。例如配置 max_fails=3 fail_timeout=20s：

1. 第 1 次请求失败 → 记录失败计数，但不标记 down
2. 第 2 次失败（在 20 秒内）→ 计数变为 2，仍不 down
3. 第 3 次失败（仍在 20 秒窗口内）→ 立即标记为 down，后续请求跳过该节点
4. 此时再发请求，若启用了 proxy_next_upstream error timeout http_502，Nginx 会在单次请求失败后立刻换节点重试，用户侧感知延迟 ≈ 单次超时时间（如 proxy_connect_timeout 3s）

用主动探测补足秒级发现能力

仅靠被动机制，首次失败请求必然失败，且需凑够失败次数。对低频请求业务尤其不友好。建议加装 nginx_upstream_check_module：

1. 配置 check interval=2 rise=1 fall=2 timeout=1 type=http：每 2 秒探一次 /health，连续 2 次失败即下线，1 次成功即恢复
2. 探活路径必须轻量：只检查进程存活、端口通、基础依赖（如 Redis 连通性），不走业务逻辑链路
3. 通过 curl "http://nginx-ip:8080/upstream_check?format=json" 可实时查看各节点状态和最近探测结果

观测与压测的关键指标

不能只看“最后是否通”，要抓取中间态数据：

1. 首挫延迟：从服务崩溃开始，到 Nginx 首次返回非 502/504 响应（即成功转到其他节点）的时间
2. 零失败切换窗口：在持续请求流中，出现 5xx 的请求数占比（理想应 ≤ 1～2 次，对应 max_fails 值）
3. 误恢复风险：服务刚重启但尚未就绪时，健康检查是否因短暂响应慢而过早将其拉回流量池（可通过 rise=2 和延长 timeout 缓解）
4. 日志佐证：开启 error_log /var/log/nginx/error.log notice;，搜索 "upstream temporarily disabled" 和 "no live upstreams" 等关键词确认状态变更时机