max_fails是在fail_timeout窗口内连续失败达指定次数后临时摘除节点，需按业务类型差异化配置：高敏感接口设为1/10s，常规api设2–3/30s，慢服务设2/60s；必须配合proxy_next_upstream启用状态码失败计数，节点在fail_timeout后首次新请求时尝试恢复，建议叠加主动健康检查。
max_fails 不是“失败多少次就永久下线”，而是在 fail_timeout 时间窗口内连续失败达到该次数后，临时摘除节点——它决定的是故障响应速度与误判风险之间的平衡点。生产环境不能只设一个固定值，必须结合业务特征、响应模式和容错目标来配置。
按业务类型设定 max_fails 和 fail_timeout
不同服务对延迟、错误容忍度差异很大，参数需差异化配置：
-
高敏感低流量接口（如支付回调、风控校验）：建议 max_fails=1 + fail_timeout=10s。单次超时或 502 即标记不可用，快速规避风险；但要配套开启
proxy_next_upstream timeout http_502，避免偶发抖动被误杀。 - 常规 Web API（如用户查询、列表分页）：推荐 max_fails=2–3 + fail_timeout=30s。兼顾稳定性与恢复灵敏度，符合多数 HTTP 服务的平均响应波动范围。
- 慢响应服务（如报表导出、大文件生成）：应增大 fail_timeout=60s，同时保持 max_fails=2。防止因单次耗时长（如 45s）被连续计入失败，导致健康节点被误摘。
必须配合 proxy_next_upstream 才能真正触发失败计数
Nginx 默认只把 connect refused 和 connection timeout 当作失败，HTTP 状态码（如 500/502/503）默认不计入 fails。若不显式配置，即使后端返回一堆 502，max_fails 也不会累加。
正确做法是在 location 块中启用对应错误重试：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;- 再搭配
proxy_next_upstream_tries 3;（最多换 2 台其他节点重试）和proxy_next_upstream_timeout 10s;（整个重试过程总超时）
只有在这些错误发生并触发重试时，Nginx 才会将该次请求失败计入对应 upstream server 的 fails 计数器。
节点自动恢复机制与边界情况处理
被标记为 down 的节点不会永远离线，Nginx 会在 fail_timeout 结束后自动发起一次探测请求，成功即重新纳入轮询池。但要注意两个关键细节：
- 恢复不是“定时心跳”，而是“首次新请求到达时尝试”。如果流量稀疏，可能几十秒甚至几分钟才触发恢复探测。
- 当所有主节点都 down 时，Nginx 会强制重试全部节点一次（包括刚被标记为 down 的），此时若某台已恢复，就能立即承接流量。
- backup 节点仅在所有非 backup 都不可用时启用，且它本身也受 max_fails 控制——不要假设 backup 就绝对可靠，同样要配 fail_timeout。
主动探测 + 被动容错才是完整方案
仅靠被动检查（max_fails）存在“首请求失败”问题：第一个访问故障节点的用户必然收到 502。生产环境强烈建议补上主动健康检查：
- 使用开源模块
nginx_upstream_check_module，在 upstream 中添加：check interval=5 rise=2 fall=3 timeout=1 type=http;check_http_send "HEAD /health HTTP/1.1\r\nHost: example.com\r\n\r\n";check_http_expect_alive http_2xx; - 含义：每 5 秒发一次 HEAD 健康探针；连续 2 次成功则上线，连续 3 次失败则下线；超时 1 秒即判失败。
- 主动探测与 passive max_fails 并存不冲突，二者互补：主动提前发现隐患，被动兜底真实请求异常。
