fail_timeout决定节点被标记为down后的静默期长度，到期后仅用首个真实请求试探恢复；需确保proxy_read_timeout＜fail_timeout、精准启用proxy_next_upstream，并按服务RT差异化设值。
要避免故障节点被高频重试卡死，核心不是加快探测频率，而是控制试探节奏、缩短单次试探的阻塞时间，并防止失败判定被延迟放大。
fail_timeout 本身不驱动重试，但决定试探时机
fail_timeout 不是“每隔几秒检查一次”，而是定义节点被标记为 down 后的静默期长度。到期后，Nginx 只用下一个真实请求去单次试探该节点：成功则恢复，失败则重置计时、继续跳过。高频重试卡死，往往源于这个“试探请求”本身耗时过长，把整个 fail_timeout 周期无效占满。
必须让试探请求快速失败，不能卡住
若试探请求因超时太长而迟迟不返回，就会导致：
- Nginx 在整个 fail_timeout 期间无法发起下一次试探（因为还没等到上一次结果）
- 用户请求被阻塞在读阶段，体验卡顿，还掩盖了真实恢复窗口
因此必须确保：
- proxy_read_timeout < fail_timeout（建议 ≤ fail_timeout 的 1/2）
- proxy_connect_timeout ≤ 2–3s（连接层异常要秒级识别）
- proxy_send_timeout ≤ 3s（尤其对上传类代理）
例如 fail_timeout=10s 时，proxy_read_timeout 应设为 3–5s，而非默认 60s。
精准启用 proxy_next_upstream，避免错误码干扰判断
默认情况下，Nginx 只将连接拒绝和连接超时计入失败；后端返回的 502/503 等不会触发 max_fails 计数——这会导致故障节点持续收请求却始终不下线。但盲目开启所有状态码又可能把 404、429 等业务态误判为故障。
正确做法是显式启用真正代表后端异常的错误类型：
- proxy_next_upstream error timeout http_500 http_502 http_503 http_504
- 不加 http_404（静态资源缺失是常态）
- 缓存类后端慎加 http_502（进程崩溃应直接剔除，而非反复重试）
按服务响应特征差异化设置 fail_timeout
设得太短（如 5s）易引发震荡：节点刚恢复就遭遇 GC 或排队，一次试探失败即重新 down；设得太长（如 120s）又拖慢回流。推荐参考实际 RT 特征设定：
- 常规 Web/API（RT 100–300ms）：fail_timeout=30s
- 高并发网关（QPS 万级+）：fail_timeout=10s（配合更高 max_fails）
- 慢响应服务（报表、大文件）：fail_timeout=60–90s
- Redis/Memcached（毫秒级响应）：fail_timeout=10s
注意：所有节点的 fail_timeout 可不同，稳定节点可设短些，老旧或弱网节点可略长。
