fail_timeout是与max_fails配合使用的冷却期，定义判定宕机的观察窗口和恢复试探的等待时长；10秒内失败3次则标记不可用，10秒后首次请求命中时重试，成功即恢复。
在 Nginx 的 upstream 配置中，fail_timeout 并不是用来“锁定节点”的独立开关，而是与 max_fails 配合使用，共同决定后端服务器被标记为不可用（即“宕机”）后，多久才重新尝试将其加入健康检查队列。它不表示强制隔离时长，而是一个“冷却期”窗口。
fail_timeout 的真实作用
fail_timeout 定义两个关键时间行为：
- 当后端在
fail_timeout时间内连续失败max_fails次，Nginx 就会将该 server 标记为 unavailable（暂时不可用）； - 被标记为 unavailable 后，Nginx 会在
fail_timeout时间结束后，**自动恢复对该 server 的试探性请求**（即下一次请求可能再次发给它），并根据响应结果判断是否继续可用。
注意：这个“恢复试探”不是定时轮询，而是按需触发——只有新请求到达且轮到该 server 时，才会尝试发一次。如果这次请求成功，就重新纳入正常调度；若仍失败，则重新计数（从 0 开始累积失败次数）。
典型配置示例
以下 upstream 块表示：某节点 10 秒内失败 3 次，就被暂时剔除；10 秒后，首次有请求命中它时会重试：
upstream backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=10s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=10s;
}
其中 fail_timeout=10s 同时约束了“判定宕机的观察窗口”和“恢复试探的等待时长”。它不能设为 0（Nginx 会报错），最小值通常为 1s。
配合 health_check 实现更主动的探测（可选增强）
仅靠 max_fails + fail_timeout 是被动检测（依赖真实业务请求失败）。若需主动、周期性探活，需启用 health_check（仅限 Nginx Plus，或开源版搭配 nginx_upstream_check_module）：
- 主动健康检查会定期发 HEAD / 或自定义探针，不依赖用户流量；
- 此时
fail_timeout仍生效，但主要用于控制“探针失败后保持 unavailable 的最短时间”； - 例如：
health_check interval=5 fails=2 passes=2表示：每 5 秒探一次，失败 2 次即下线，成功 2 次才上线；而fail_timeout=30s可确保即使探针立刻变好，也至少等待 30 秒才允许恢复（防抖）。
常见误区提醒
- fail_timeout 不是“永久封禁”或“管理员手动解锁”机制——Nginx 不提供手动踢出/恢复节点的命令行接口（除非 reload 配置或调用 API）；
-
它不控制单次请求超时——请求级超时由
proxy_connect_timeout、proxy_read_timeout等控制； - 多个 server 共享同一套 fail_timeout 规则，但各自独立计数（每个 server 维护自己的失败计数器和上次失败时间戳）；
- 若未显式设置
max_fails，默认为 1；未设fail_timeout，默认为 10s。
