max_fails与fail_timeout共同决定后端节点摘除与恢复：fail_timeout定义失败统计窗口及down状态持续时长，max_fails为该窗口内触发摘除的失败次数阈值；二者必须协同调优，如常规web服务设3/30s，高qps服务宜用20/10s，慢响应服务推荐2–3/60s。
在 Nginx 的 upstream 配置中，max_fails 和 fail_timeout 是控制后端服务器健康状态判定与故障转移的关键参数，它们共同决定 Nginx 何时将某台服务器标记为“不可用”，以及多久后尝试恢复它。
max_fails：连续失败次数阈值
该参数定义在 fail_timeout 时间窗口内，Nginx 向某台后端服务器发起请求时，允许的最大连续失败次数。一旦达到该值，Nginx 就会将该服务器临时标记为“down”，不再转发新请求过去。
- 默认值是
1，即只要一次请求失败（如超时、连接拒绝、500/502/503/504 等错误响应），就认为该节点异常 - 设为
0表示禁用失败计数，Nginx 不做主动健康检查（仍可能因连接失败触发临时剔除，但不累积计数） - 建议根据业务容忍度调整，例如对稳定性要求高的服务可设为
3，避免偶发网络抖动误判
fail_timeout：失败统计窗口与恢复等待时间
这个参数有双重含义：
- 作为“失败计数周期”：Nginx 只在最近
fail_timeout秒内发生的失败计入max_fails统计（比如设为30s，则只看最近 30 秒内的失败次数） - 作为“下线保持时间”：当服务器被标记为 down 后，Nginx 会在
fail_timeout秒后自动将其重新纳入负载均衡池，尝试发送新请求进行探测
注意：这两个作用共用同一个数值，不能单独配置。例如 fail_timeout=60s 意味着——统计最近 60 秒失败次数，且节点 down 后 60 秒才尝试恢复。
典型配置示例与行为解读
以下是一个常见 upstream 块：
upstream backend {server 192.168.1.10:8080 max_fails=3 fail_timeout=60s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=60s;
}
其实际行为是：
- 如果 192.168.1.10 在 60 秒内连续 3 次请求失败（如超时或返回 502），Nginx 将它标记为 down
- 接下来 60 秒内，所有请求都只会打到 192.168.1.11；同时 Nginx 不再向 192.168.1.10 发起任何新请求（包括健康探测）
- 60 秒到期后，Nginx 自动将 192.168.1.10 重新加入可用列表，并在下次请求时尝试转发——若成功则持续使用，若再次失败则重新开始计数
注意事项与常见误区
这些参数仅对 proxy_pass、fastcgi_pass 等代理指令生效，且依赖于 Nginx 主动发起的请求失败判断。它们不是主动心跳探活机制（如 keepalive 或自定义 health_check），所以：
- 若后端长期无流量，即使已宕机，Nginx 也不会主动发现，直到第一个请求触发失败并开始计数
- 失败判定基于连接层和 HTTP 状态码：连接拒绝、连接超时、读取超时、HTTP 5xx 响应（默认）会被计入；4xx 通常不视为失败（除非配置了
proxy_next_upstream error http_4xx） - 多个 upstream server 可以设置不同值，实现差异化容错策略
