Nginx可通过proxy_next_upstream配合被动健康检查实现多节点连续宕机时的故障转移：配置max_fails、fail_timeout及重试策略，结合可切换HTTP服务模拟节点逐个下线，并通过日志、响应一致性与恢复能力三方面验证效果。
要测试 Nginx 在多节点连续宕机时的故障转移表现，核心是模拟真实后端服务逐个失效的过程，并观察 Nginx 是否能自动剔除不可用节点、平滑切换到健康节点，以及是否出现请求失败或超时堆积。
配置支持健康检查的 upstream
Nginx 默认不主动探测后端健康状态，需启用 health_check（需使用 Plus 版本）或通过开源模块（如 nginx_upstream_check_module）实现主动探测。更通用且免费的方式是结合 proxy_next_upstream 与被动健康检查：
- 在
upstream块中设置max_fails=2 fail_timeout=10s，表示某节点连续 2 次失败（如连接拒绝、超时、500/502/503/504）后，在 10 秒内不再转发请求给它 - 配置
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，让 Nginx 在遇到这些情况时尝试下一个 upstream 节点 - 建议加上
proxy_next_upstream_tries 3和proxy_next_upstream_timeout 3s，限制重试总次数和总耗时，避免长尾延迟
构建可控制的后端故障环境
手动停服务不够灵活，推荐用轻量方式模拟节点逐个下线：
- 用 Python/Node.js 启多个本地 HTTP 服务（如端口 8001–8004），每个返回固定响应（如
{"id": "node-1", "status": "ok"}） - 提供一个
/toggle接口，调用后立即关闭当前服务（模拟宕机），再启动时恢复监听 - 用
curl -X POST http://localhost:8001/toggle按顺序关停 node-1 → node-2 → node-3，观察 Nginx 日志与客户端响应变化
验证故障转移行为的关键指标
不能只看“有没有响应”，要关注三个层面：
-
日志证据：开启
error_log /var/log/nginx/error.log notice;，搜索"upstream failed"和"no live upstreams"，确认是否触发了 failover，以及最终是否所有节点都被标记为 down -
响应一致性：持续压测（如
ab -n 1000 -c 10 http://nginx-proxy/），检查返回的id字段是否随节点下线动态变化，且无 502/503 错误（除非全部宕机） -
恢复能力：重启已宕节点后，观察其是否在
fail_timeout后自动重新加入负载池（Nginx 不会主动探活，依赖后续请求触发“试探”）
极端场景补充测试项
连续宕机测试还需覆盖边界情况：
- 当最后一个健康节点也宕机时，Nginx 应返回 502 或你配置的
error_page 502 /fallback.html，而非无限等待 - 若启用了
keepalive连接池，注意连接复用可能缓存已失效的后端连接，建议加proxy_http_version 1.1; proxy_set_header Connection '';避免复用断连 - 对 WebSocket 或长连接服务，
proxy_next_upstream不生效，需改用主动健康检查或四层负载均衡（如 keepalived + LVS）兜底
