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 秒后自动重试，若恢复则重新加入。
失败判定依赖 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）实现类似能力
