max_fails与fail_timeout必须协同生效：在fail_timeout定义的时间窗口内连续失败max_fails次，Nginx才标记节点不可用并跳过该节点fail_timeout秒，到期自动探测恢复；单独设置max_fails几乎无效。
被动健康检查不是“定时 ping”，而是靠真实请求失败来触发节点摘除。max_fails 和 fail_timeout 必须成对出现、协同生效，单独设置 max_fails 几乎无效。
它们到底怎么联动？
max_fails 不是总失败次数，而是在 fail_timeout 定义的时间窗口内，连续失败达到该数值，Nginx 才会将该 upstream server 标记为不可用，并在接下来的 fail_timeout 秒内跳过它。到期后自动发起一次试探性请求，成功即恢复服务。
例如：
server 10.0.1.5:6379 max_fails=2 fail_timeout=10s;
表示：10 秒内若发生 2 次代理失败（如连接拒绝、读超时、502 等），该 Redis 节点立即下线；之后 10 秒内所有请求绕开它；第 11 秒起，Nginx 会尝试发一个新请求探测——成功则重新纳入负载池，失败则再等 10 秒。
注意：
– 若只写 max_fails=2 而不配 fail_timeout，Nginx 使用默认值 10 秒，容易在高并发场景下误剔除
– fail_timeout=0 是禁用被动检查，节点宕机也不会被感知，绝对不要这么设
不同业务类型怎么配才合理？
没有万能值，关键看请求耗时特征和故障容忍度：
- 缓存类服务（Redis/Memcached）：响应快（max_fails=2 fail_timeout=10s，快速隔离；但需确保客户端有重试能力
- 常规 Web 接口（官网、管理后台）：平均响应 100–300ms，偶有网络抖动 → max_fails=3 fail_timeout=30s 更稳妥，平衡敏感性与稳定性
- 长耗时服务（报表导出、大文件上传）：单次请求可能持续 40–60 秒 → 应设 fail_timeout=60s，max_fails=2 或 3，避免一次慢请求就触发误判
- 金融级强实时接口：要求秒级故障隔离 → 可设 max_fails=1 fail_timeout=5s，但必须搭配 proxy_next_upstream 重试 + 后端幂等保障
光调这两个参数远远不够
max_fails/fail_timeout 是“摘机逻辑”，但若没配套配置，它就形同虚设：
- proxy_read_timeout 必须小于 fail_timeout：比如 fail_timeout=10s，proxy_read_timeout 建议设为 3–5s。否则请求卡在读阶段超时，无法及时计入失败计数
- proxy_next_upstream 必须显式开启：默认不重试。建议至少启用 error timeout http_502 http_503 http_504；再配合 proxy_next_upstream_tries 3 和 proxy_next_upstream_timeout 10s 控制重试边界
- 慎用 http_502 重试：缓存服务返回 502 多因进程崩溃，应直接剔除，而不是反复换节点重试
- 后端要提供真实 /health 接口：若引入主动健康检查（如 OpenResty 或第三方模块），/health 必须执行实际连接测试（如 Redis::ping()），不能只返回 200 表示进程存活
一句话总结调优逻辑
让失败计数窗口（fail_timeout）覆盖 1–2 个典型请求周期，把失败阈值（max_fails）设为该窗口内可容忍的异常次数。窗口太短易抖动，太长难发现；阈值太高拖累可用性，太低牺牲稳定性。它不是调参游戏，而是对业务节奏的理解落地。
