要让upstream实现快速摘除与平滑容错，关键在于max_fails和fail_timeout构成匹配业务节奏的滑动失败窗口：前者决定“多快下线”，后者决定“下线多久”及“统计窗口宽度”，需按业务类型选配（如高敏感接口用1/10s、常规服务用3/30s），并同步配置proxy_next_upstream启用5xx计数、proxy_read_timeout小于fail_timeout、以及重试边界控制。
要让 upstream 实现上游节点的快速摘除与平滑容错，关键不是单独调大或调小某个值，而是让 max_fails 和 fail_timeout 构成一个匹配业务响应节奏的滑动失败窗口——前者决定“多快下线”，后者决定“下线多久”和“统计多宽”。配置失衡会导致误杀健康节点，或放任故障节点持续承接流量。
按业务响应特征选配组合
不同服务对失败的敏感度和耗时差异很大，不能统一用 3/30：
-
高敏感低频接口（如支付回调、风控通知）：设
max_fails=1 fail_timeout=10s。单次 502 或超时即隔离，避免错误状态扩散；需确保后端有重试兜底，否则可能丢请求 -
常规 Web/API 服务（QPS 数百至数千，RT 100–300ms）：用
max_fails=3 fail_timeout=30s。能过滤 GC 暂停、瞬时网络抖动等偶发异常，是多数场景的稳健起点 -
高并发网关（QPS 万级+，节点少于 3 台）：推荐
max_fails=15–20 fail_timeout=10s。缩短检测窗口、提高失败容忍阈值，防止单个慢请求或毛刺反复触发摘除震荡 -
慢响应服务（报表导出、大文件上传、WebSocket 后端）：设
max_fails=2 fail_timeout=60–90s。避免一次正常耗时 45s 的请求被误判为 timeout 并计入失败，导致健康节点被误摘
必须同步启用 proxy_next_upstream 才真正计数
Nginx 默认只把连接拒绝（connect refused）和连接超时（timeout）算作失败，502/503/504 等 HTTP 错误码默认不参与计数。哪怕后端持续返回 502，max_fails 也不会涨。
务必在 location 块中显式配置：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
其中：
• error 覆盖底层 I/O 异常
• timeout 包含 connect/read/send 超时
• 显式列出关键 5xx 状态码，才能让它们触发重试并计入失败计数
超时参数必须对齐，否则计数失效
仅改 max_fails 和 fail_timeout 不起作用，以下两项必须严格对齐：
-
proxy_read_timeout必须小于fail_timeout - 例如
fail_timeout=30s，则proxy_read_timeout建议设为5s或10s；若设为 35s，请求卡在读阶段超时无法及时上报失败，导致计数严重滞后 proxy_next_upstream_tries和proxy_next_upstream_timeout要控制重试边界- 建议设为
proxy_next_upstream_tries 3;（最多换 2 个节点重试）和proxy_next_upstream_timeout 10s;（整个重试过程总耗时不超 10 秒），防止用户长时间无响应
节点恢复不是定时心跳，而是请求试探
被标记为 down 的节点，在 fail_timeout 秒结束后不会自动轮询探测，而是等待下一个新请求到达时发起一次试探：
- 试探成功 → 立即重新加入 upstream 轮询池
- 试探失败 → 继续标记为 down，并再等下一个请求来重试
- 若所有主节点都已 down，Nginx 会强制重试全部节点（包括刚被标记 down 的），此时若某台已恢复，就能立刻承接流量
这意味着低流量时段恢复可能延迟；如需更及时探测，建议叠加主动健康检查（如 health_check 指令）提升可靠性。
