fail_timeout 不控制熔断时长，而是定义失败统计窗口和节点恢复试探的冷却期；它在节点正常时用于滑动统计失败次数，在节点被标记为 down 后作为静默期，到期后才用新请求单次试探恢复情况。

fail_timeout 并不直接控制“熔断”时长，而是定义两个关键行为：失败统计窗口长度和节点恢复试探的冷却期。它不是熔断持续时间本身，但决定了节点从被标记为不可用到首次获得重试机会之间的时间间隔。

---

fail_timeout 的真实作用

• 它是一个双用途时间值：

  • 在节点正常时：用于滑动统计“多少秒内失败多少次”（配合 max_fails 判断是否摘除）；
  • 在节点被标记为 down 后：作为“静默期”，到期后 Nginx 才会用下一个真实请求去试探该节点是否恢复。

• 节点不会自动心跳探测，也不会定时轮询；恢复是被动、按需、单次试探的——只有新请求到来时，才向该节点发一次请求：

  • 成功 → 立即重新加入 upstream 轮询；
  • 失败 → 继续标记为 down，再等下一个请求来重试。

---

如何用 fail_timeout 控制恢复节奏

• 设得太短（如 5s）：

  

  AI Code Reviewer

  一款AI开发辅助工具，主要用于AI自动审核代码，适合需要提升相关任务效率的用户。

  下载
  • 可能还没等后端真正恢复（比如 GC 刚结束、连接池重建中），Nginx 就已发起试探，反复失败 → 节点长期卡在 down 状态；
  • 高频试探还可能加重后端负担。

• 设得太长（如 300s）：

  • 即使后端秒级自愈，Nginx 也要等满 fail_timeout 才尝试恢复 → 用户流量长时间绕过健康节点，负载不均、延迟上升。

• 合理设定原则：

  • 应略大于后端典型故障恢复时间（如服务重启耗时、DB 连接重建时间、中间件重连窗口）；
  • 同时兼顾业务容忍度：管理后台可设 30s，支付回调类强一致接口建议 10s，报表导出类慢服务可设 60–90s。

---

与 max_fails 协同调优恢复体验

• fail_timeout 单独调整效果有限，必须和 max_fails 匹配：

  • 若 fail_timeout=10s，max_fails=20：说明你允许节点在 10 秒内失败 20 次才下线 → 恢复后也只需等 10 秒就试探；
  • 若 fail_timeout=60s，max_fails=2：强调“宁可慢判、不可误判”，恢复等待也是 60 秒，但更稳妥。

• 实际线上推荐组合：

  • 常规 Web 接口：max_fails=3 fail_timeout=30s
  • 高 QPS 网关：max_fails=15 fail_timeout=10s
  • 报表/大文件上传：max_fails=2 fail_timeout=60s
  • 支付回调/风控通知：max_fails=1 fail_timeout=10s

---

让恢复更可靠的关键补充

• 必须启用 proxy_next_upstream，否则失败不计数，fail_timeout 形同虚设；
• 建议搭配主动健康检查（如 health_check 指令或外部探活），弥补低流量时段被动试探失效的问题；
• 注意 proxy_connect_timeout 和 proxy_read_timeout 设置：若它们远大于 fail_timeout，会导致失败判定延迟，削弱恢复灵敏度。