nginx中max_fails与fail_timeout需成对配置于upstream的server指令内，共同定义滑动时间窗口内的失败阈值与禁用时长；必须配合proxy_next_upstream显式启用5xx等错误计数，否则仅连接类失败触发剔除。
在 Nginx 中，max_fails 和 fail_timeout 是 upstream 模块中用于健康探测的关键参数，它们配合使用，可以让 Nginx 自动将连续失败的后端节点临时标记为不可用，实现故障节点的自动剔除（即“被动健康检查”）。
这两个参数必须在 upstream 块中配置
它们不能单独存在，必须写在 upstream 块内的 server 指令里。Nginx 默认不开启主动健康检查，所以依赖这两个参数做简单的失败统计与隔离。
-
max_fails：指定在fail_timeout时间窗口内，允许该 server 返回失败响应的最大次数（默认为 1） -
fail_timeout：定义一个时间窗口（单位秒），在这个时间段内累计失败达到max_fails次，该 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;
server 192.168.1.12:8080 max_fails=3 fail_timeout=30s;
}
含义是：任一后端在 30 秒内连续失败 3 次（如连接超时、502/503/504 等错误响应），Nginx 就将其从可用列表中临时移除；30 秒后，Nginx 会再次尝试向它转发请求，若成功则重新纳入轮询，否则继续隔离。
什么算“失败”？Nginx 的判定逻辑
不是所有 HTTP 错误码都会触发计数，Nginx 默认只把以下情况视为一次失败：
- 连接后端失败（connection refused / timeout）
- 向后端发送请求时出错（send timeout）
- 从后端接收响应头超时（read timeout）
- 后端返回空响应或无效响应头
-
注意：HTTP 状态码如 500、502、503、504 默认不计入
max_fails，除非你显式启用proxy_next_upstream http_500 http_502 ...
若希望 5xx 响应也参与失败统计，需在 location 或 upstream 外层加上：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
验证和排查建议
实际运行中可结合日志观察是否生效：
- 开启
error_log级别为notice或更高，Nginx 会在日志中记录类似server 192.168.1.10:8080 was marked as failed的信息 - 通过
nginx -t检查语法，避免拼写错误（如写成fail_timeout写成fail_time_out会被忽略） - 注意：这些参数对
ip_hash或hash负载策略同样生效，但若只剩一个节点，即使被标记为失败，Nginx 仍可能强制转发（取决于proxy_next_upstream_tries和重试逻辑）
