max_fails与fail_timeout必须协同生效：在fail_timeout定义的滑动时间窗口内累计失败max_fails次，节点即被标记不可用并跳过exactly fail_timeout秒，到期后由首个新请求试探恢复；需同步配置proxy_next_upstream启用错误判定，否则健康检查失效。
max_fails 和 fail_timeout 是 Nginx upstream 被动健康检查的核心参数，它们必须成对使用、协同生效，共同定义一个「滑动失败计数窗口」：只有在 fail_timeout 秒内累计失败达到 max_fails 次，节点才会被临时标记为不可用；该状态持续 exactly fail_timeout 秒，到期后由下一个新请求试探恢复。
它们不是独立工作的
max_fails 不是总失败次数，也不是“失败几次就永久下线”。它只在长度为 fail_timeout 的滚动时间窗内统计可识别的失败事件。例如：
- fail_timeout=30s，T₀ 失败一次 → 计数为 1
- T₀+25s 再失败 → 计数为 2（仍在同一窗口）
- T₀+50s 又失败 → T₀ 已滑出窗口，但后两次仍在窗内 → 计数达 3，立即触发摘除
- 节点被标记 down 后，fails 归零，新计数从首次恢复请求开始
fail_timeout 具有双重含义
它既是失败统计的时间范围，也是节点被跳过的实际时长：
- 统计维度：用于判断“最近 fail_timeout 秒内是否达到 max_fails 次失败”
- 行为维度：节点一旦被摘除，就会被跳过 exactly fail_timeout 秒
- 恢复机制：到期后不自动轮询，而是靠“下一个新请求”去试探——成功则重新加入，失败则重置计时并再次禁用
不配置 proxy_next_upstream 就等于白设
默认情况下，Nginx 只把连接拒绝（connect refused）和连接超时（timeout）算作失败；502/503/504 等 HTTP 错误码默认不计入 fails。哪怕后端持续返回 502，max_fails 也不会增长。必须显式启用：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;- 搭配
proxy_next_upstream_tries 3;控制最多换 2 个节点重试 - 搭配
proxy_next_upstream_timeout 10s;防止用户长时间等待
常见误配会导致失效或震荡
- 只改 max_fails=10，fail_timeout 仍为默认 10s → 高 QPS 下极易反复上下线
- fail_timeout=60s 但 max_fails=1 → 单次超时就停 60 秒，恢复太慢
- fail_timeout=0 → 彻底关闭被动健康检查，节点宕机也无法感知
- proxy_read_timeout ≥ fail_timeout → 读阶段超时无法及时上报，失败计数滞后甚至失效
