max_fails与fail_timeout是Nginx被动健康检查的核心绑定参数：在fail_timeout滑动时间窗口内累计失败max_fails次即标记节点不可用并跳过fail_timeout秒，到期由首个请求试探恢复。
故障转移要真正“精准”，核心是让 Nginx 不仅知道后端挂了，还要清楚它什么时候挂、为什么挂、还能不能恢复。健康检查不是开关，而是判断依据——被动检查靠失败反馈，主动检查靠定期探测，二者结合才能实现有依据、有节奏、可验证的故障隔离。
用 max_fails + fail_timeout 实现基础故障标记
这是开源版 Nginx 原生支持的被动机制，不依赖模块，但必须配对使用：
- max_fails=3：不是累计失败3次就踢，而是“在 fail_timeout 时间窗口内连续失败3次”才触发标记
- fail_timeout=30s：既定义判定周期，也决定该节点被标记为 down 后的“冷静期”——30 秒内不再转发任何请求
- 单次超时（如 proxy_connect_timeout=3s）或 502/503 响应，只要落在这个窗口内且达阈值，就会被临时剔除
靠 proxy_next_upstream 控制重试边界
光剔除不够，得让请求“有路可走”。这个指令决定了什么情况下才触发故障转移：
- 写全常见异常：proxy_next_upstream error timeout http_500 http_502 http_503 http_504
- 避免漏判：比如后端进程僵死但 TCP 连接能建上，此时只有 timeout 触发重试；若只写 error，这类情况就被忽略
- 不建议加 invalid_header 或 updating，它们易引发非预期重试，干扰故障定位
引入主动探测提升感知精度（推荐）
被动检查滞后、误判率高，尤其对“端口通但业务卡死”的节点完全无感。加装 nginx_upstream_check_module 后可做到：
- 每 3 秒发一次 GET /health HTTP/1.0，不走业务链路，轻量可控
- 用 check_http_expect_alive http_2xx 精确匹配状态码，拒绝把 404、503 当健康
- 配合后端返回的 {"status":"UP"} 做响应体校验，确保应用层真就绪，不止是进程活着
- 通过 /status 接口实时查看各节点 last_status、rise/fall 计数，运维可快速确认是网络抖动还是服务崩溃
配合长连接与超时参数防止误伤
很多“假故障”其实来自连接管理不当：
- 在 upstream 中加 keepalive 32，复用连接，避免 TIME_WAIT 拥塞导致连接拒绝被当成后端宕机
- 设 proxy_connect_timeout 3s（防建连卡住）、proxy_read_timeout 15s（防业务慢拖垮整体）
- backup 节点只在所有主节点都不可用时启用，不参与日常负载，专用于兜底，避免因权重配置失当引发流量倾斜
