max_fails是被动健康检查的失败计数阈值，必须与fail_timeout协同构成滑动窗口：在fail_timeout秒内累计失败≥max_fails次即标记节点不可用并跳过该时长，到期由首个请求试探恢复；需配合proxy_next_upstream等参数才生效。
nginx 故障转移中，max_fails 不是“失败重试次数”，而是被动健康检查的失败计数阈值，必须和 fail_timeout 配合使用才能生效。单独设 max_fails 没有意义，也不会触发节点摘除或重试切换。
max_fails 和 fail_timeout 的真实作用逻辑
它们共同定义一个滑动时间窗口：
- 在 fail_timeout 秒长度的时间窗口内，该 upstream server 失败次数 ≥ max_fails，Nginx 就将其标记为不可用
- 该节点会被跳过 exactly fail_timeout 秒，到期后由下一个新请求试探恢复（成功即重新加入，失败则重置计时）
- 每次失败都会刷新窗口起始时间；中间有成功请求，失败计数也不会清零
常见业务场景推荐配置
配置需匹配后端响应特征，不能一概而论：
- 缓存类服务（毫秒级响应）：max_fails=2，fail_timeout=10s
- 常规 Web/API（100–300ms）：max_fails=3，fail_timeout=30s
- 慢响应服务（40–60秒）：max_fails=2，fail_timeout=60s 或 90s
- 高 QPS 场景（万级请求）：max_fails=15–20，fail_timeout=10s
- 强实时接口（如支付）：max_fails=1，fail_timeout=5s
让故障转移真正生效的必要配套设置
仅配 max_fails 和 fail_timeout 还不够，必须同步完成以下几项：
-
显式开启 proxy_next_upstream，例如：
proxy_next_upstream error timeout http_502 http_503 http_504；否则失败不会触发重试或摘除 -
限制总尝试次数：用
proxy_next_upstream_tries 3（表示最多发 3 次请求，含首次），避免雪崩 -
超时参数对齐：确保
proxy_read_timeout和proxy_connect_timeout均小于fail_timeout，否则重试发不出去 -
upstream 至少 2 台可用节点，否则重试无目标；可加
backup节点兜底
典型错误配置要避开
这些写法会导致故障转移失效：
- 只改
max_fails却没设fail_timeout，或反过来 -
proxy_next_upstream_tries 1—— 等同于不重试 -
proxy_next_upstream漏掉timeout或error，导致连接拒绝、超时不触发切换 - 把
http_404或http_500加进重试条件，可能掩盖业务异常 - 启用
non_idempotent导致 POST 请求被重复发送，引发数据重复问题
