Nginx故障转移后自动回切需满足无抖动、不丢请求、不重复转发、不卡休眠期：须启用upstream_check_module主动探测（rise=2），验证状态恢复与真实流量承接时间差≤3s，禁用非必要重试状态码，配合slow_start=15s渐进上线。
测试 Nginx 故障转移后的“自动回切平滑度”，核心是验证：当原故障后端恢复后，Nginx 是否能**无抖动、不丢请求、不重复转发、不卡在休眠期**地重新纳入流量。这不是简单“看到节点变绿”，而是关注恢复过程中的请求行为是否连续可控。
确认健康检查机制已启用主动探测
被动检查（靠请求失败计数）无法支撑可靠回切——节点恢复后仍需等 fail_timeout（如30秒）才重试，期间所有请求都绕过它，造成人为“冷启动延迟”。必须使用 upstream_check_module 的主动探测：
- 检查配置中是否有 check interval=2 rise=2 fall=3 类参数，且 rise=2 表示连续两次探测成功即标记为“上线”
- 执行 nginx -V 2>&1 | grep upstream_check，确保模块已编译启用
- 访问 /status（需配置 stub_status 或 check_status）确认节点状态从 down 变为 up 的时间点
模拟恢复并观测真实请求路径
不要只看状态页，要测真实流量是否立刻承接：
- 用 iptables -D INPUT -p tcp --dport 8080 -j DROP 恢复后端端口（撤掉之前模拟宕机的规则）
- 立即发起持续请求：while true; do curl -s -o /dev/null -w "%{http_code}\n" http://vip/health; sleep 0.5; done
- 观察输出：首次返回 200 的时间点，与状态页显示“up”的时间差应 ≤ interval + timeout（例如 2s+1s=3s 内）
- 重点检查恢复瞬间是否出现 502 或超时——若有，说明 proxy_next_upstream 未合理配置，或新节点尚未完成 warmup
验证回切过程不引发重复或错乱
尤其对非幂等操作（如 POST 提交），回切阶段若重试逻辑失控，可能造成业务侧重复写入：
- 在 upstream 中显式限制重试边界：proxy_next_upstream_tries 2（不超过节点总数）、proxy_next_upstream_timeout 6s
- 确保 proxy_next_upstream 不含 http_500 或 http_404，仅保留 error timeout http_502 http_503 http_504
- 用抓包工具（如 tcpdump）在 Nginx 侧监听，确认同一请求在恢复窗口期内最多只发往一个后端，不会因“刚上线又失败”导致二次分发
结合 slow_start 避免冷启动冲击
即使节点被标记为 up，若瞬间涌入全量流量，可能因连接池未建立、缓存未热而再次触发失败，形成震荡。启用渐进上线：
- 在 upstream server 行添加 slow_start=15s（Nginx ≥1.15.10）
- 该参数让节点上线后，15 秒内权重从 0 线性升至 100%，天然抑制回切抖动
- 搭配 max_fails=1 fail_timeout=10s，可防止因初期少量失败被误踢出
