Nginx需在upstream的server指令中成对配置max_fails和fail_timeout，并配合proxy_next_upstream、合理超时参数才能实现故障节点自动剔除与转移；max_fails定义滑动窗口内最大失败次数，fail_timeout既是统计窗口也是禁用时长，超时后由新请求试探恢复。
要让 Nginx 在后端出问题时自动剔除故障节点并完成故障转移，max_fails 和 fail_timeout 必须成对配置在 upstream 的每个 server 指令中，且必须配合 proxy_next_upstream 和显式超时参数才能真正生效。
基础配置写法与作用逻辑
这两个参数共同定义一个“滑动失败窗口”：
-
max_fails：表示在
fail_timeout时间段内，允许该后端返回失败响应的最大次数（默认为 1） - fail_timeout：既是失败统计的时间窗口（秒），也是节点被标记为不可用后的禁用时长；超时后，首个新请求会试探性转发，成功即恢复服务
典型写法示例：
upstream backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
}
含义：任一节点在 30 秒内累计失败 3 次（如连接超时、502/503/504），就被临时下线 30 秒；之后由真实请求试探恢复。
必须同步启用的配套配置
仅设 max_fails 和 fail_timeout 不起作用，以下三项缺一不可：
- 在
location块中显式开启错误识别：proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
——否则后端返回的 5xx 不会计入失败，节点永远不被剔除 - 设置合理超时，确保失败能快速判定：
proxy_connect_timeout 5s;<br>proxy_send_timeout 10s;<br>proxy_read_timeout 10s;
注意：proxy_read_timeout应明显小于fail_timeout，否则请求卡住无法及时触发计数 - 可选但推荐添加重试限制：
proxy_next_upstream_tries 3;<br>proxy_next_upstream_timeout 10s;
防止重试放大延迟或压垮剩余节点
按业务特征调优参数组合
统一用 max_fails=3 fail_timeout=30s 容易误剔或反应迟钝，应结合后端行为调整：
-
高 QPS 网关（如 API 入口）：用
max_fails=15 fail_timeout=10s，缩短窗口、提高容错，过滤瞬时毛刺 -
慢操作服务（如导出、上传）：用
max_fails=2 fail_timeout=60s，避免一次正常长耗时请求被误判为故障 -
强一致关键链路（如支付回调）：用
max_fails=1 fail_timeout=10s，首次失败即隔离，宁可保守也不冒险
增强容错：加 backup 节点实现手动 Failover
当所有主节点都被标记为不可用时，可指定备用服务器承接流量：
upstream backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.99:8080 backup max_fails=2 fail_timeout=20s;
}
backup 节点默认不参与轮询，仅当主节点全部失效时启用；它也支持健康检查，保障自身可用性。
