如何配置max_fails与fail_timeout实现集群节点的被动健康检查-Nginx-PHP中文网

nginx被动健康检查依赖请求失败行为判断后端异常，核心参数max_fails与fail_timeout需协同配置：在fail_timeout时间窗口内累计失败max_fails次即标记不可用并跳过该节点fail_timeout秒，到期后以首个请求试探恢复；窗口滑动刷新、失败计数不因成功请求清零；配置需依后端响应特征调整——缓存类服务（毫秒级）宜设max_fails=2、fail_timeout=10s；常规web/api（100–300ms）推荐max_fails=3、fail_timeout=30s；慢响应服务（40–60秒）建议max_fails=2、fail_timeout=60s或90s；高qps场景（万级）可设max_fails=15–20、fail_timeout=10s；强实时接口（如支付）应设max_fails=1、fail_timeout=5s；必须同步配置proxy_next_upstream（显式启用错误判定）、proxy_next_upstream_tries与timeout（限制重试）、proxy_read_timeout与connect_timeout（超时对齐），且fail_timeout不可为0、不可单独修改任一参数、不可小于平均响应时间，否则将导致检查失效或误判。

如何配置max_fails与fail_timeout实现集群节点的被动健康检查

Nginx 的被动健康检查不靠定时探测，而是依赖真实请求的失败行为来判断后端是否异常。max_fails 和 fail_timeout 是一对必须协同配置的核心参数，单独设置其中一个基本无效。

关键逻辑是：在 fail_timeout 定义的时间窗口内，该 upstream server 累计失败达到 max_fails 次，Nginx 就将其标记为不可用，并跳过它 fail_timeout 秒；到期后，用第一个新请求试探恢复——成功即重新加入轮询，失败则重置计时。

这个窗口是滑动的：每次失败都会刷新窗口起始时间，且失败计数不会因中间有成功请求而清零。

max_fails 与 fail_timeout 怎么配才合理

不能套用固定值，要按后端服务的响应特征来匹配：

Nginx Hosting

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

下载

缓存类服务（Redis/Memcached）
响应快（毫秒级），失败多代表真故障：
max_fails=2 fail_timeout=10s —— 快速隔离，适合同机房内网直连
若跨机房或网络不稳定，可放宽为 max_fails=3 fail_timeout=30s
常规 Web/API 接口（如用户查询、订单列表）
平均耗时 100–300ms，需容忍瞬时抖动：
max_fails=3 fail_timeout=30s —— 覆盖 GC 暂停、短时丢包等常见干扰
慢响应服务（报表导出、大文件上传）
单次请求可能持续 40–60 秒：
max_fails=2 fail_timeout=60s 或 90s —— 避免一次长耗时请求被误判为失败
高 QPS 场景（网关、核心 API，QPS 万级以上）
单位时间失败绝对次数高，易震荡：
max_fails=15–20 fail_timeout=10s —— 提高阈值，降低误剔频率
强实时/金融级接口（如支付回调、风控校验）
要求秒级故障感知：
max_fails=1 fail_timeout=5s —— 首次超时或 502 即摘除，但必须搭配幂等与客户端重试

必须同步配置的配套项

只调 max_fails 和 fail_timeout 不够，以下三项不配齐，健康检查就形同虚设：

显式启用错误判定条件
Nginx 默认只将连接拒绝、连接超时计入失败，HTTP 状态码（如 502/503）默认不参与计数。
必须在 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; —— 整个重试过程总耗时上限
超时参数要相互对齐
proxy_read_timeout 应明显小于 fail_timeout（例如 fail_timeout=30s 时，设 proxy_read_timeout=5s），否则请求卡在读阶段迟迟不超时，无法及时触发失败计数。
同样，proxy_connect_timeout 也建议设为 3–5s，避免建连阻塞影响判断。