Nginx故障转移效率测试需模拟可控突发崩溃，结合被动检查（max_fails/fail_timeout）与主动探测（nginx_upstream_check_module），观测首挫延迟、零失败窗口、误恢复风险等指标。
要测试 Nginx 在后端服务突发崩溃时的自动故障转移效率，核心是模拟真实故障场景，并观察 Nginx 从检测失败、剔除节点、重试请求到流量完全绕过的全过程耗时与成功率。关键不在于“是否能切”，而在于“多快切稳、是否误切、会不会反复试探坏节点”。
构造可控的突发崩溃场景
避免用 kill -9 随机中断进程——这可能导致连接未及时断开、Nginx 无法立即感知。推荐方式：
- 在目标后端服务上部署一个可触发的 /crash 接口（如 Spring Boot 的 Actuator + 自定义 endpoint），调用后立即终止主线程并关闭端口
- 或使用 iptables 拦截特定后端 IP:PORT 的所有入向连接：
iptables -A INPUT -s 192.168.1.10 -p tcp --dport 8080 -j REJECT，模拟网络层瞬断 - 配合 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 次请求失败 → 记录失败计数，但不标记 down
- 第 2 次失败（在 20 秒内）→ 计数变为 2，仍不 down
- 第 3 次失败（仍在 20 秒窗口内）→ 立即标记为 down，后续请求跳过该节点
- 此时再发请求，若启用了
proxy_next_upstream error timeout http_502，Nginx 会在单次请求失败后立刻换节点重试，用户侧感知延迟 ≈ 单次超时时间（如proxy_connect_timeout 3s）
用主动探测补足秒级发现能力
仅靠被动机制，首次失败请求必然失败，且需凑够失败次数。对低频请求业务尤其不友好。建议加装 nginx_upstream_check_module：
- 配置
check interval=2 rise=1 fall=2 timeout=1 type=http：每 2 秒探一次 /health，连续 2 次失败即下线，1 次成功即恢复 - 探活路径必须轻量：只检查进程存活、端口通、基础依赖（如 Redis 连通性），不走业务逻辑链路
- 通过
curl "http://nginx-ip:8080/upstream_check?format=json"可实时查看各节点状态和最近探测结果
观测与压测的关键指标
不能只看“最后是否通”，要抓取中间态数据：
- 首挫延迟：从服务崩溃开始，到 Nginx 首次返回非 502/504 响应（即成功转到其他节点）的时间
- 零失败切换窗口：在持续请求流中，出现 5xx 的请求数占比（理想应 ≤ 1～2 次，对应 max_fails 值）
-
误恢复风险：服务刚重启但尚未就绪时，健康检查是否因短暂响应慢而过早将其拉回流量池（可通过
rise=2和延长timeout缓解） -
日志佐证：开启
error_log /var/log/nginx/error.log notice;，搜索"upstream temporarily disabled"和"no live upstreams"等关键词确认状态变更时机
