轮询调度需搭配健康检查实现故障隔离，关键在于配置max_fails和fail_timeout启用被动检查，并通过proxy_next_upstream指定error、timeout及5xx状态触发重试，配合合理超时参数与日志验证。
轮询调度本身不判断后端是否可用，必须搭配健康检查机制才能实现故障自动隔离。配置时关键不在“加功能”，而在让被动检查真正生效、响应及时、剔除合理。
upstream 中必须设置 max_fails 和 fail_timeout
这是被动健康检查的基石。Nginx 默认只在连接失败或超时时计数，不主动探测；只有达到 max_fails 次失败，且发生在 fail_timeout 时间窗口内，才会将该 server 标记为不可用。
- 推荐值：max_fails=2 fail_timeout=10s（即 10 秒内连续失败 2 次就踢出）
- 若后端响应慢，可适当调大 fail_timeout，但不宜超过 30 秒，否则恢复延迟明显
- max_fails 设为 0 表示禁用失败计数，服务器永不被标记为 down —— 这会绕过健康检查逻辑
proxy_next_upstream 要明确指定哪些状态触发重试
仅靠 upstream 的失败计数还不够，请求仍可能落到已失效但尚未被标记的节点上。proxy_next_upstream 决定了什么情况下 Nginx 主动换一台后端重试。
- 至少包含 error timeout —— 覆盖网络中断和连接超时
- 建议加上 http_500 http_502 http_503 —— 捕获应用层异常返回
- 避免写 http_404 或 http_403，这类状态通常属业务逻辑，不应触发重试
配套设置合理的超时参数
超时值直接影响健康检查灵敏度和用户体验。太短易误判，太长则拖慢整体响应。
- proxy_connect_timeout 控制建连阶段超时，建议设为 3–5 秒
- proxy_read_timeout 控制后端响应读取超时，建议设为 10–15 秒（略大于后端平均处理时间）
- 这两个值应小于 fail_timeout，否则可能因单次超时就触发踢出，而实际服务只是临时抖动
验证时注意观察日志与行为一致性
配置生效不能只看语法正确，要通过真实请求+日志确认逻辑走通。
- 启用 error_log info 级别，关注 upstream timed out / failed / now down 类提示
- 手动停掉某台后端，发连续请求，观察是否快速跳过、且 fail_timeout 后自动恢复
- 用 curl -I 反复请求，结合 access_log 中 upstream_addr 字段，确认流量确实绕开了故障节点
