max_fails与fail_timeout协同决定后端节点临时摘除时机：在任意fail_timeout时间窗口内失败次数≥max_fails即摘除该节点；必须配合proxy_next_upstream启用重试才生效。
max_fails 不是“失败次数”，而是 fail_timeout 窗口内的连续失败计数
很多人把 max_fails 理解成“只要累计失败 3 次就永久剔除”，这是错的。它只在 fail_timeout 定义的时间窗口内有效，且失败计数会随时间滑动重置：如果某节点在 10 秒内失败 2 次，第 15 秒又失败 1 次，那这 3 次并不构成“连续失败”——因为中间断开了统计窗口。
真正触发摘除的条件是：在任意一个 fail_timeout 长度的时间段内（比如 10s），该节点被记录的失败次数 ≥ max_fails。
-
max_fails=3 fail_timeout=10s：只要存在某个 10 秒区间内出现 3 次失败，该节点立刻停用 10 秒 - 失败记录只来自
proxy_next_upstream显式启用的类型（如timeout、http_502），不是所有 HTTP 状态码都会计入 - 连接拒绝（connect refuse）和超时（timeout）永远计入；但
http_404默认不计入，除非你写了proxy_next_upstream http_404
高 QPS 场景下 max_fails=3 是危险配置
线上 QPS 过万时，max_fails=3 fail_timeout=30s 容易造成“毛刺”：单个慢请求或瞬时网络抖动就可能凑够 3 次失败，导致健康节点被误摘除 30 秒，流量被迫压向剩余节点，引发雪崩式排队。
实际运维中更稳妥的做法是拉长观察粒度、提高容错阈值：
- 保持
fail_timeout缩短到 10s（Nginx 默认值），让节点失效期可控 - 把
max_fails提高到 10–20，具体看后端节点数和平均 RT：节点越少、RT 越高，max_fails应越高 - 例如 4 节点集群、平均 RT 800ms，可设
max_fails=15 fail_timeout=10s；若只剩 2 节点，则建议 ≥20
fail_timeout 决定业务恢复节奏，不是越长越好
fail_timeout 不是“故障持续时间”，而是“节点被静默观察的周期”。它直接影响服务从异常中恢复的速度：设为 60s，意味着即使节点秒级恢复，Nginx 也要等满 60 秒才重新尝试转发请求。
这个值必须和你的业务容忍延迟对齐：
- 金融类接口要求快速响应，
fail_timeout建议 ≤10s，配合max_fails=1实现秒级隔离（但需确认后端有重试兜底） - 报表导出类长耗时服务，
fail_timeout可设为 60s，避免单次 45s 的成功请求因前序 timeout 被连带误判 - 绝对不要设
fail_timeout=0：这会让 Nginx 彻底关闭被动健康检查，节点挂了也不会自动剔除
必须配 proxy_next_upstream，否则 max_fails 形同虚设
max_fails 本身不产生任何失败记录——它只是个计数器开关。真正决定“什么算一次失败”的，是 proxy_next_upstream 的配置。
默认只认 error timeout，即仅连接失败或超时才触发计数。如果你后端返回大量 502 却没配 http_502，那这些错误完全不会影响 max_fails 计数，节点会持续收流量直到彻底不可达。
- 常规 Web 服务建议至少加
http_500 http_502 http_503 http_504 - 要控制重试成本，务必配
proxy_next_upstream_tries 3和proxy_next_upstream_timeout 10s，防止重试链拖垮整体延迟 - 别漏掉
invalid_header：gRPC 或某些 FastAPI 服务返回空 header 时会触发此错误，不加它会导致失败不计数
最常被忽略的一点：max_fails 和 fail_timeout 是 per-server 的，不是全局策略。同一 upstream 块里不同 server 可以设不同值，但混用时要注意监控是否出现“部分节点频繁摘除而其他节点过载”的失衡现象。
