Nginx 中轮询策略结合 Fail_timeout 实现自动容错

Nginx轮询本身不判断后端可用性，真正实现自动容错依赖max_fails与fail_timeout协同构成滑动失败窗口：在fail_timeout时间内累计失败达max_fails次即标记节点不可用并绕过该节点fail_timeout秒，到期由首个请求试探恢复；必须配合proxy_next_upstream指定error/timeout/5xx等触发重试，否则机制失效。

Nginx 轮询本身不感知后端状态，真正实现自动容错，靠的是 max_fails 和 fail_timeout 的配合。它们共同构成一个“失败计数窗口”，让 Nginx 在请求失败后能临时跳过异常节点，而不是反复重试导致雪崩或用户体验中断。

轮询与 fail_timeout 如何协同工作

轮询按顺序把请求分发给每个 server，但一旦某台后端响应异常，max_fails 和 fail_timeout 就开始介入：

1. 每次请求失败（如连接超时、502/503/504 等），Nginx 会为该 server 计一次失败
2. 如果在 fail_timeout 秒内累计失败达到 max_fails 次，该 server 就被标记为“不可用”
3. 接下来 fail_timeout 秒内，轮询指针会自动绕过它，不再转发新请求
4. 时间一到，Nginx 会尝试发一个探测请求；若成功，立刻重新纳入轮询队列

这个过程完全自动，无需重启或人工干预。

配置要点与常见误区

1. fail_timeout 不只是“隔离时长”，它同时定义了失败统计的时间窗口
2. max_fails=0 表示禁用失败计数，等同于关闭容错，不建议生产环境使用
3. 默认值 max_fails=1 fail_timeout=10s 过于敏感，小抖动就触发剔除，容易造成流量倾斜
4. 所有 server 应保持一致的 max_fails 和 fail_timeout 值，否则队列完整性会被破坏

必须搭配的 proxy_next_upstream

仅靠 max_fails + fail_timeout 还不够——它只解决“事后剔除”，不解决“当前请求失败怎么办”。必须启用：

1. proxy_next_upstream error timeout http_500 http_502 http_503 http_504：定义哪些错误触发重试
2. proxy_next_upstream_tries 2：最多换 2 个节点再返回错误，避免单点卡死
3. proxy_next_upstream_timeout 10s：整个重试过程不能超过 10 秒，防止用户长时间等待

实际验证方式

上线后别只看平均响应时间，直接查 access log 最可靠：

1. 在 log_format 中加入 $upstream_addr 字段，记录每次实际转发到哪台后端
2. 发起 20+ 次请求，观察日志是否呈现循环序列（如 A→B→C→A…）
3. 手动停掉一台后端，确认后续请求是否全部落到其余节点，且错误日志中无持续连接失败

不复杂但容易忽略