max_fails和fail_timeout是nginx被动健康检查的核心绑定参数：在fail_timeout滑动时间窗口内累计失败max_fails次即标记节点不可用并跳过fail_timeout秒，到期由首个请求试探恢复。

在 Nginx 的轮询（round-robin）负载均衡中，本身不直接提供“失败次数阈值”这一配置项；真正控制后端节点健康状态与摘除逻辑的是 health_check（需搭配 upstream_hash 或 stream 模块）或更常用的 proxy_next_upstream + max_fails/fail_timeout 机制。这些参数虽不属于轮询算法本身，但实际决定了某个后端在连续失败多少次后被临时剔除——也就是你关心的“失败阈值”。

max_fails 和 fail_timeout 是核心组合

这两个指令必须配合使用，定义后端服务器被标记为“不可用”的条件：

• max_fails：在 fail_timeout 时间窗口内，允许连续失败的最大次数（默认为 1）
• fail_timeout：时间窗口长度（单位秒），同时也是该节点被标记为不可用的持续时间（默认 10s）

例如：server 192.168.1.10:8080 max_fails=3 fail_timeout=30s; 表示：若该节点在 30 秒内连续 3 次无法响应（如超时、返回 5xx、连接拒绝等），Nginx 就会将其暂时从轮询池中剔除，30 秒内不再转发请求；30 秒后自动重试，若恢复则重新加入。

Nginx Hosting

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

下载

失败判定依赖 proxy_next_upstream

仅配置 max_fails 不生效，必须启用错误传播机制：

• 在 location 块中设置 proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
• 这表示当上游返回指定错误类型或发生连接/读写超时时，Nginx 才会尝试下一个 upstream server，并计入该 server 的失败计数
• 注意：http_404 默认不触发重试（业务正常返回），除非显式加入列表

注意几个常见误区

轮询本身无“失败计数”逻辑 —— 它只是按顺序分发请求；失败统计和剔除由 Nginx 的被动健康检查（基于请求结果）驱动。

• max_fails=0 表示禁用失败计数，该 server 永远不会被标记为不可用（慎用）
• 失败计数是“连续”的，但不是严格要求同一秒内；只要在 fail_timeout 窗口内累计达到 max_fails 次，即触发屏蔽
• 日志中可通过 $upstream_addr 和 $upstream_status 辅助排查是否发生了重试和切换

进阶建议：结合主动健康检查（Nginx Plus 或开源版 1.11.5+ with http_upstream_module）

若需更精准、及时的故障发现，可启用主动健康检查（需编译支持或使用 Plus 版本）：

• 使用 health_check interval=3 fails=2 passes=2; 在 upstream 块中
• 它独立于用户请求，定时探测，失败 2 次即下线，恢复 2 次再上线，比被动方式更可控
• 开源 Nginx 主线版本（≥1.11.5）可通过第三方模块（如 nginx_upstream_check_module）实现类似能力