max_fails是Nginx upstream被动健康检查的核心参数，需与fail_timeout协同生效：在fail_timeout定义的滑动时间窗口内累计失败达max_fails次，节点即被标记不可用并跳过exactly fail_timeout秒，到期后由首个新请求试探恢复；必须配合proxy_next_upstream显式启用错误类型（如timeout、http_502）才会计入失败。
max_fails 是 Nginx 中 upstream 模块用于健康检查的关键参数，它定义了在 fail_timeout 时间窗口内，某个后端节点连续失败多少次后，Nginx 就将其标记为“不可用”，暂时剔除出负载均衡池。
max_fails 的作用机制
它不单独起作用，必须配合 fail_timeout 使用。Nginx 会记录每次与该节点通信失败（如连接超时、502/503/504 等网关错误）的次数，并在 fail_timeout 秒内累计。一旦失败次数达到 max_fails，该节点会被标记为“down”，在此后的 fail_timeout 秒内不再接收新请求。
- 失败判定依据：默认仅包括连接拒绝（connection refused）、连接超时（connection timed out）、读取超时（read timeout）；HTTP 状态码如 500/502/503/504 不自动计入，除非配合
proxy_next_upstream显式启用 - 计数重置：只要在
fail_timeout内有一次成功响应，失败计数清零 - 恢复方式：节点不会自动“复活”，需等待
fail_timeout时间过去后，Nginx 才会尝试再次转发请求；若这次成功，则重新纳入可用池
基本配置示例
在 upstream 块中为每个 server 设置：
upstream backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
}
含义：任一节点在 30 秒内连续失败 3 次，就暂停使用 30 秒。
配合 proxy_next_upstream 提升检测灵敏度
默认情况下，Nginx 不把 HTTP 错误状态当作“失败”来触发 max_fails 计数。要让 502/503/504 等也参与故障统计，需在 location 中开启重试逻辑：
-
proxy_next_upstream error timeout http_502 http_503 http_504;—— 表示遇到这些情况时，将请求转发给下一个 upstream 节点，同时本次失败会计入该节点的max_fails - 注意：
http_500默认不包含，如需加入，需显式添加 - 避免滥用：不要加
http_404或invalid_header，否则正常业务错误也可能误判为节点故障
验证与排查建议
可通过 Nginx 内置状态页或日志确认节点是否被标记为 down：
- 启用
stub_status或使用nginx-upstream-check-module（第三方）查看实时状态 - 检查 error log：出现
upstream server temporarily disabled即表示已触发 max_fails 限流 - 临时模拟故障测试：停掉某台后端服务，观察访问是否自动切到其他节点，并留意日志中的失败计数和 down 标记时间
