Nginx轮询需配合健康检查实现节点自动下线与平滑恢复：被动检查靠max_fails/fail_timeout和proxy_next_upstream配置，主动检查需nginx_upstream_check_module模块探测/health接口，再依业务调优参数并控制超时与权重。
Nginx 轮询本身不识别后端是否存活，必须靠健康检查机制来发现并剔除死节点。它不是算法升级问题，而是配置组合问题——轮询负责分发，健康检查负责“把关”。只要配对关键参数、明确失败定义、控制超时节奏，就能实现自动下线+平滑恢复。
被动检查：靠真实请求触发故障识别
这是最常用、无需编译的方案，适合绝大多数业务场景：
- 在 upstream 中每个 server 显式加容错参数：
max_fails=3 fail_timeout=30s。表示 30 秒内连续失败 3 次，该节点被临时屏蔽 30 秒 - 在 location 块中启用错误重试：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504。注意不能写http_50x，必须逐个列出 - 必须设超时，否则卡住的请求无法快速失败：
proxy_connect_timeout 5s；proxy_send_timeout 10s；proxy_read_timeout 10s
主动检查：提前发现“假存活”节点
被动检查依赖流量，低峰期或刚挂掉时可能滞后。用 nginx_upstream_check_module 可主动探测：
- OpenResty 已内置该模块；原生 Nginx 需编译加入
- 在 upstream 中添加探测配置：
check interval=3 rise=2 fall=3 timeout=1 type=http uri=/health - 后端需提供轻量
/health接口，返回 200 且响应稳定（建议响应时间 ≤200ms）
按业务调优失败阈值
统一用 max_fails=3 fail_timeout=30s 容易误判或响应滞后，应结合后端行为调整：
-
高频短连接服务（如用户中心 API）：设
max_fails=15 fail_timeout=10s，扩大容错次数、缩短统计窗口，避免毛刺导致频繁剔除 -
慢操作服务（如报表导出）：改用
max_fails=2 fail_timeout=60s，防止一次长耗时请求被误判为故障 -
强一致链路（如支付回调）：用
max_fails=1 fail_timeout=10s，首次失败即隔离，宁可保守也不冒险
平滑切流的关键控制点
剔除只是第一步，真正平滑在于“不丢请求、不断连接、不放大压力”：
- 下线前可先设
weight=0或down，立即停止新请求分发，已有连接继续处理 - 调大
proxy_read_timeout（如 60–90s），匹配业务最长耗时，避免 Nginx 提前中断后端正在执行的任务 - 被标记为
down的节点，会在下一个新请求到达时自动试探一次：成功则立即恢复，失败则继续隔离
