Nginx被动健康检查需max_fails与fail_timeout联动生效：fail_timeout定义统计窗口和禁用时长，max_fails为该窗口内累计失败阈值；两者缺一不可，且须配套proxy_next_upstream、proxy_read_timeout等配置才有效。

直接配置 max_fails 和 fail_timeout 就能启用 Nginx 原生的被动健康检查，但必须理解它们是联动参数——不是“失败几次就永久下线”，而是在指定时间窗口内累计失败达到阈值后临时摘除，到期自动试探恢复。

核心行为：窗口统计 + 冷却恢复

fail_timeout 既是失败统计的时间窗口长度，也是节点被摘除后的禁用时长；max_fails 是该窗口内触发摘除所需的失败次数。两者缺一不可：

• 若只写 max_fails=3 不配 fail_timeout，Nginx 会用默认 10 秒，容易在高并发下误剔除
• 若设 fail_timeout=0，等于完全关闭被动检查，节点宕机也不会被感知
• 失败不需“连续”：只要在当前 fail_timeout 窗口内累计达 max_fails 次（含中间有成功请求），即触发摘除
• 摘除后，Nginx 在 fail_timeout 秒后用第一个新请求试探；成功则恢复，失败则重置计时

按业务类型选组合值

不能套用统一数值，关键看典型请求耗时和错误容忍节奏：

• 常规 Web 接口（如用户查询、管理后台）：平均响应 100–300ms，偶有抖动 → max_fails=3 fail_timeout=30s
• 高 QPS API（如网关、订单接口）：每秒数千请求，毛刺常见 → max_fails=20 fail_timeout=10s，防频繁震荡
• 慢响应服务（如报表导出、大文件上传）：单次可能耗时 40–60 秒 → max_fails=2 fail_timeout=60s，避免慢请求被误判
• 缓存后端（Redis/Memcached）：毫秒级响应，失败多为真故障 → max_fails=2 fail_timeout=10s，快速隔离

必须配套的关键配置

光调这两个参数不够，以下三项不配好，健康检查基本失效：

• proxy_next_upstream 必须显式启用：默认不把 5xx 当失败，建议写 error timeout http_500 http_502 http_503 http_504
• proxy_read_timeout 应小于 fail_timeout：比如 fail_timeout=10s，则 proxy_read_timeout 设为 3–5s，否则读超时不计入失败计数
• proxy_next_upstream_tries 和 proxy_next_upstream_timeout 要设边界：例如 tries 3（最多换 2 个节点）、timeout 10s（整个重试过程上限）

典型 upstream 配置示例

放在 http 或 stream 块中：

<br>upstream backend {<br>  server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;<br>  server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;<br>  server 192.168.1.12:8080 max_fails=2 fail_timeout=10s; # 缓存节点更敏感<br>}

再在对应 location 中补上重试逻辑：

proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 10s;