Nginx upstream自动下线需max_fails、fail_timeout与proxy_next_upstream协同生效：max_fails指fail_timeout滑动窗口内连续失败次数，proxy_next_upstream必须显式配置error/timeout及5xx码才触发计数，且proxy_read_timeout须小于fail_timeout以确保超时被识别。
要让 Nginx upstream 真正实现集群成员“自动下线”，max_fails 本身不单独起作用，它必须和 fail_timeout、proxy_next_upstream 协同配置——三者缺一不可。触发机制不是“失败几次就永久剔除”，而是在滑动时间窗口内连续失败达到阈值后临时隔离，并在超时后首次请求试探恢复。
明确 max_fails 和 fail_timeout 的绑定关系
max_fails 不是总失败计数，而是指在 fail_timeout 规定的时间窗口内 连续失败次数。例如：
- max_fails=2 fail_timeout=10s：最近 10 秒内出现 2 次可识别失败 → 节点被标记为 down，持续 10 秒不转发流量
- 窗口是滑动的：第 1 秒失败一次，第 8 秒再失败一次 → 计入同一窗口，触发摘除；第 12 秒再失败，则以第 8 秒为新起点重算窗口
- 节点被摘除瞬间，fails 计数器归零，后续恢复请求重新开始统计
必须启用 proxy_next_upstream 才能真正计数失败
Nginx 默认只把 连接拒绝（connect refused）和连接超时（timeout） 当作失败，502/503/504 等 HTTP 错误码默认不计入 fails。若不配置，后端持续返回 502，节点也不会下线。
- 在 location 块中显式开启：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504; - 搭配控制重试行为：
proxy_next_upstream_tries 3;（最多换 2 台其他节点）、proxy_next_upstream_timeout 10s;（整个重试流程不超 10 秒） - 注意：不要加入
http_404，否则正常缺失资源会误触发下线
按业务特征差异化设定触发节奏
没有通用最优值，需匹配接口响应模式与容错目标：
-
高敏感低流量接口（如支付回调、风控通知）：max_fails=1 fail_timeout=10s —— 单次失败即隔离，但必须配
http_502和重试机制防抖动误杀 - 常规 Web API（如用户查询、列表分页）：max_fails=2–3 fail_timeout=30s —— 覆盖常见网络抖动或 GC 暂停，兼顾稳定性与恢复灵敏度
- 慢响应服务（如报表导出、大文件生成）：max_fails=2 fail_timeout=60s —— 防止单次耗时 45 秒的正常请求被误判为失败
- 高 QPS 场景（如 API 网关）：max_fails=15–20 fail_timeout=10s —— 缩短检测窗口，提高失败容忍数，避免毛刺反复触发上下线
配套关键项不能遗漏
仅调参数还不够，以下三项直接影响触发是否及时、准确：
- proxy_read_timeout 必须小于 fail_timeout：例如 fail_timeout=10s 时，proxy_read_timeout 建议设为 3–5s，否则读超时不触发失败计数
- 禁用 proxy_next_upstream http_502（除非真需要）：缓存类服务返回 502 多因进程崩溃，应直接剔除，而非反复重试其他节点
- 后端提供真实 /health 接口：若叠加主动健康检查（如 OpenResty），/health 必须执行实际连接探测（如 Redis::ping()），不能只返回 200 表示进程存活
