fail_timeout是统计窗口长度与节点冷却期的双重时间值：既定义最近fail_timeout秒内失败计数范围，又决定节点被摘除后跳过调度的时长；到期后需靠新请求试探恢复，非自动轮询。
fail_timeout 不是“摘除后等多久恢复”的倒计时，而是定义失败统计窗口长度和节点冷却期的双重时间值。它直接决定 Nginx 何时开始怀疑一个节点、又何时愿意再给它一次机会——配得不准，要么频繁误杀健康节点，要么对真实故障反应迟钝。
理解 fail_timeout 的两个关键角色
它在节点状态变化中承担两种功能，且不可拆分：
- 统计窗口：Nginx 只在最近 fail_timeout 秒内累计失败次数（配合 max_fails 判断是否摘除）；
- 冷却期：节点一旦被标记为 down，就会被跳过整整 fail_timeout 秒，期间不接收任何新请求；
- 到期后不是自动探测，而是靠下一个真实请求试探：成功即恢复，失败则重置计时、继续禁用。
按业务响应节奏匹配 fail_timeout 值
不能脱离单次请求耗时谈 fail_timeout。设得太短，一次慢请求就触发误判；设得太长，故障节点长期拖累流量。
- 常规 Web/API 服务（如用户查询、后台管理，平均响应 100–300ms）：设 fail_timeout=30s。30 秒内有足够样本判断异常，又能避开 GC 暂停或瞬断抖动；
- 高 QPS 网关类服务（QPS 万级+，失败绝对数高）：缩至 fail_timeout=10s。缩短观察周期，避免慢速统计导致节点反复进出 down 状态；
- 慢响应服务（报表导出、大文件上传，单次可能耗时 40–90s）：拉长到 fail_timeout=60s 或 90s。确保一次真实慢请求不会被重复计入多个失败窗口；
- 强一致低频接口（如支付回调、风控通知）：可设 fail_timeout=10s，但需搭配 max_fails=1，做到首次失败即隔离。
必须同步校准的关联项
fail_timeout 单独调优没有意义，以下三项必须协同设置：
- proxy_read_timeout 必须小于 fail_timeout：例如 fail_timeout=10s，proxy_read_timeout 建议设为 3–5s。否则请求卡在读阶段超时，无法及时归入失败计数；
- max_fails 必须成比例调整：fail_timeout 缩短时，max_fails 要相应提高（如 10s/20 次），否则毛刺即下线；拉长时则降低（如 60s/2 次），防止单次慢请求凑数；
-
proxy_next_upstream 必须显式启用错误码：默认只统计连接拒绝和超时，502/503/504 不计入失败。务必写明：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504。
常见踩坑点提醒
- 把 fail_timeout 设为 5s，但后端平均响应要 8s → 节点上线即被反复判定失败；
- 只改 fail_timeout 为 60s，max_fails 还是默认 1 → 一次超时就下线 60 秒，恢复太慢；
- 忽略 proxy_next_upstream 配置，后端持续返回 502，但 fails 计数器始终为 0；
- 设 fail_timeout=0 → 相当于关闭被动健康检查，节点永不自动摘除。
