nginx upstream 故障自动剔除与恢复依赖 max_fails 和 fail_timeout 成对调优，构成滑动时间窗口机制：fail_timeout 内失败达 max_fails 即标记不可用，持续 exactly fail_timeout 秒后由新请求试探恢复；需同步配置 proxy_read_timeout

要让 upstream 真正做到快速摘除故障节点、又不误杀健康节点，关键不是调大 max_fails 或拉长 fail_timeout，而是让这两个参数形成匹配业务节奏的滑动窗口——失败在窗口内达阈值才触发摘除，摘除后正好等满这个窗口时长再试探恢复。

按服务响应特征选配组合

不同后端的耗时分布和错误容忍度差异很大，统一用 3/30 容易出问题：

• 高敏感低频接口（如支付回调、风控校验）：max_fails=1，fail_timeout=10s。单次失败即隔离，防止错误状态扩散；但必须确保后端有重试兜底，否则可能丢请求
• 常规 Web/API 服务（QPS 数百至数千，RT 100–300ms）：max_fails=3，fail_timeout=30s。能过滤 GC 暂停、瞬时网络抖动等偶发异常，是多数场景的稳健起点
• 高并发网关（QPS 万级+，节点少于 3 台）：max_fails=15–20，fail_timeout=10s。缩短统计窗口 + 提高容错阈值，避免因个别慢请求反复触发误剔，防止流量雪崩式挤压剩余节点
• 慢响应服务（报表导出、大文件上传、WebSocket 后端）：max_fails=2，fail_timeout=60–90s。避免一次正常耗时 45s 的请求被前序 timeout 连带计入失败，导致健康节点被误摘

必须同步启用 proxy_next_upstream 才生效

max_fails 默认只统计连接拒绝（connect refused）和连接超时（timeout），后端返回的 502/503/504 等错误默认不计入失败计数——这意味着即使后端持续返回 502，节点也不会被摘除。

Nginx Hosting

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

下载

务必在 location 块中显式配置：

• proxy_next_upstream error timeout http_500 http_502 http_503 http_504; —— 明确哪些错误触发重试与失败计数
• proxy_next_upstream_tries 3; —— 最多重试 2 个其他节点（共最多发 3 次请求）
• proxy_next_upstream_timeout 10s; —— 整个重试过程总耗时上限，不是单次超时

配套关键项不能遗漏

只改 max_fails 和 fail_timeout 不起作用，以下三项不匹配会直接失效：

• proxy_read_timeout 必须小于 fail_timeout：例如 fail_timeout=10s，proxy_read_timeout 建议设为 3–5s；否则请求卡在读阶段超时，无法及时触发失败计数
• fail_timeout 兼具双重含义：既是失败统计窗口长度，也是节点被跳过的时长；到期后不是自动轮询，而是靠“下一个新请求”来试探恢复——成功则重新纳入轮询，失败则重置计数再等下一次试探
• 切勿设 fail_timeout=0：这会完全关闭被动健康检查机制；max_fails=0 同样等价于禁用该功能

建议叠加主动健康检查提升可靠性

被动检查依赖真实请求，在低流量时段可能长期不触发探测，导致故障节点“隐身”；主动健康检查（如 keepalive 或第三方模块）可定期探测，弥补被动机制盲区。两者结合，才能兼顾低延迟摘除与高确定性恢复。