调优 max_fails 的核心是与 fail_timeout 协同构成贴合业务节奏的滑动失败窗口：fail_timeout 定义滚动统计窗口长度及节点摘除时长，max_fails 为该窗口内累计失败阈值；需显式配置 proxy_next_upstream 启用错误码计数，并确保 proxy_read_timeout

调优 max_fails 的核心，是让它和 fail_timeout 协同构成一个贴合业务真实节奏的滑动失败窗口，而不是单独把它设小或设大。

理解 max_fails 的真实触发逻辑

max_fails 不是“连续失败几次就熔断”，而是在最近 fail_timeout 秒内累计失败次数达到该值，节点才被临时摘除。这个窗口是滚动的，不是从零重计——比如 fail_timeout=30s，第 1 秒失败一次，第 28 秒又失败一次，第 55 秒再失败一次，那第 28 和 55 秒的两次仍在窗口内，就可能触发熔断。

• 默认只把连接拒绝（connection refused）和连接超时（timeout）计入失败；5xx 响应（如 502/503）必须配合 proxy_next_upstream 显式启用才会参与计数
• max_fails=0 等价于禁用被动健康检查，节点挂了也不会被感知
• 节点被标记为 down 后，计数器清零，恢复探测从首次新请求开始，不是定时心跳

按后端类型匹配合理组合值

没有通用最优值，只有适配你后端响应特征的组合。关键看单次请求耗时分布、错误率和容错目标：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 缓存类服务（Redis/Memcached）：毫秒级响应，失败大概率是真故障 → 推荐 max_fails=2 + fail_timeout=10s
• 常规 Web API（QPS 数百～数千）：兼顾抖动过滤与响应速度 → max_fails=3 + fail_timeout=30s 是稳妥起点
• 高并发网关（QPS 万级+）：避免毛刺反复触发震荡 → 缩短窗口、提高容忍，如 max_fails=15–20 + fail_timeout=10s
• 慢响应服务（报表导出、大文件）：单次耗时常超 40 秒 → 设 max_fails=2 + fail_timeout=60s，防止单次长耗时被误判

必须配套的关键配置

只改 upstream 里的 max_fails 和 fail_timeout 几乎无效，以下三项缺一不可：

• 在 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（整个重试流程限时）
• proxy_read_timeout 必须小于 fail_timeout（建议 ≤ 1/2），否则请求卡在读阶段不超时，失败无法及时计入统计

验证是否真正生效的小技巧

修改配置并 nginx -s reload 后，可人工模拟一次明确失败（如临时让后端返回固定 502），然后观察：

• 连续发 2–3 次请求，看 access log 中目标节点 IP 是否不再出现
• 等待 fail_timeout 秒后发第 4 次，看该节点是否重新出现在日志中（说明试探恢复已启动）
• 若所有主节点都 down，Nginx 会强制重试全部节点，此时已恢复的节点能立即承接流量