Nginx故障转移实测耗时通常为5–10秒，涵盖首次感知失败、标记节点down及重试成功返回200的全过程，需通过error.log定位首次失败时间、nginx -T确认max_fails/fail_timeout参数，并在access.log中验证proxy_next_upstream重试生效。
测试后端宕机时 Nginx 的故障转移速度，核心不是看“配置写了多久”，而是实测从服务不可用到请求成功返回之间的真实耗时。整个过程分三段：Nginx 首次感知失败、标记节点为 down、完成流量切换并返回成功响应。必须用日志、指标和主动探测交叉验证。
抓取首次失败时间点
打开 error.log，搜索目标后端地址（如 192.168.1.20:8080）和错误关键词：connect() failed、Connection refused、upstream timed out。首次出现的时间即为 Nginx 第一次感知异常的时刻。
- 若配置了
upstream_connect_timeout 3s且网络正常，首次失败通常出现在宕机后 3 秒内 - 注意区分：
connect失败是秒级感知；read timeout可能拖到几十秒，且不触发健康检查计数 - 确认
proxy_read_timeout和proxy_send_timeout是否过长，避免卡在读响应阶段
确认节点被标记为 down 的时刻
Nginx 不会立即下线节点，需满足 max_fails 次失败且都在 fail_timeout 时间窗口内。例如 max_fails=3 fail_timeout=30s：
- 第 1 次失败 → 计数=1，节点仍参与调度
- 第 2 次失败（5 秒后）→ 计数=2
- 第 3 次失败（再过 2 秒）→ 计数=3，节点立即标记为 down
- 从首次失败到标记 down 的实测耗时，通常为 5–10 秒
- 执行
nginx -T | grep upstream确认实际生效的参数，检查是否被 location 块覆盖
验证用户请求是否真正恢复
节点 down 不代表业务无感。关键看单次请求是否通过 proxy_next_upstream 触发重试，并最终返回 200：
- 在 access.log 中找含
502或504的行，再往后翻几行，看同一客户端 IP + 相近时间戳是否有200请求 → 表明重试成功 - 确认 location 块中启用
proxy_next_upstream error timeout http_502 http_504，否则请求直接失败 - 用
curl -w "@format.txt" -o /dev/null -s http://test/连续发 5 次，观察第几次开始稳定返回 200；中间穿插的错误码次数和间隔就是真实影响窗口
补充：用轻量脚本做端到端计时
写一个简单脚本，在后端宕机瞬间启动计时，持续请求直到连续 3 次成功：
- 在目标 Tomcat 上执行
kill -9 $(pgrep -f "catalina")同时记录时间 T₀ - 另一台机器运行循环请求：
while ! curl -s --max-time 2 http://nginx-vip/healthz -o /dev/null; do sleep 0.2; done - 记录从 T₀ 到首次成功的时间差，再观察后续请求是否稳定低延迟
- 该值应 ≤ 10 秒（典型 max_fails/fail_timeout + 重试开销），超时说明配置或链路存在瓶颈
