fail_timeout是节点被标记为不可用后的静默等待时长及失败统计时间窗口，与max_fails构成滑动窗口机制：在fail_timeout秒内失败≥max_fails次即下线，下线后需等待fail_timeout秒才允许首个试探请求；其值需依后端类型合理设定，并须与proxy_connect_timeout、proxy_read_timeout、proxy_next_upstream协同调优，配合主动健康检查可提升恢复速度。
fail_timeout 不是“检测周期”，而是节点被标记为不可用后的静默等待时长，也是失败统计的时间窗口长度。它决定两个关键行为：一是在多长时间内累计多少次失败会触发下线；二是下线后要等多久才允许第一次试探性恢复请求。配置不合理会导致节点反复震荡下线，或故障修复后长期无法回流。
理解 fail_timeout 的真实作用机制
它和 max_fails 绑定构成滑动时间窗口：
- 在任意连续 fail_timeout 秒 内，该节点失败 ≥ max_fails 次，即被标记为 down
- 标记后，Nginx 在接下来的 fail_timeout 秒 内完全不发任何请求给它
- 期满后，**首个真实业务请求**会试探打过去——成功则立即恢复，失败则重置计时、再等一个 fail_timeout
- 失败只计入 proxy_next_upstream 显式启用的类型（如 timeout、error、http_502），不是所有异常都算
按后端特征设置合理值
不能统一设成 10s 或 30s，需匹配实际恢复节奏与网络稳定性：
- 同机房 Web/API 服务（RT 100–300ms）：fail_timeout=30s，配合 max_fails=3
- 跨机房或弱网络链路（丢包/延迟波动常见）：fail_timeout=60s，max_fails=5
- 慢响应服务（报表、大文件上传，单次耗时 40–60s）：fail_timeout=90s～120s，max_fails=2
- 强实时接口（支付、风控回调）：fail_timeout=5s，max_fails=1，但必须有幂等与客户端重试兜底
- 缓存类后端（Redis/Memcached，毫秒级）：fail_timeout=10s，max_fails=2
必须同步调优的配套参数
单独改 fail_timeout 几乎无效，以下三项必须对齐：
- proxy_connect_timeout 必须小于 fail_timeout：例如 fail_timeout=30s，则 connect_timeout ≤10s（内网）或 ≤15s（跨可用区），否则建连卡住，整个 fail_timeout 周期白白浪费
- proxy_read_timeout 必须明显小于 fail_timeout：建议设为 fail_timeout 的 1/3～1/2，确保读超时能及时上报失败，不拖慢计数更新
-
proxy_next_upstream 必须显式启用判定项：如
error timeout http_502 http_504，否则默认只认连接拒绝和建连超时，502 等错误不参与计数
叠加主动健康检查提升恢复速度
纯被动机制依赖真实流量试探，恢复慢且滞后。推荐加一层主动探测：
- 使用 nginx_upstream_check_module 或 OpenResty 的 health_check
- 探测间隔 interval ≈ proxy_connect_timeout × 1.5（如 connect_timeout=10s，则 interval=15s）
- 失败阈值 fall=2，恢复阈值 rise=3，避免单次抖动误判
- 主动检查成功后可立即恢复节点，不再等待 fail_timeout 到期
