如何设定Nginx upstream max_fails的最佳阈值，在业务恢复时间与系统稳定性间取得平衡？

本文共计1032个文字，预计阅读时间需要5分钟。

很多人把`max_fails`理解成只要失败3次就永久剔除，这是错误的。它实际上只在与`fail_timeout`定义的时间窗口内有效，且失败计数会随时间滚动重置。例如，如果在10秒内失败2次，在第15秒又失败1次，这3次并不构成连续失败，因为中间间隔了5秒，超过了系统统计窗口。

真正触发摘除的条件是：在任意一个 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 秒，流量被迫压向剩余节点，引发雪崩式排队。