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;
