Nginx 默认轮询不自带健康检查，需配合health_check指令（Nginx≥1.11.0）或第三方模块（如nginx_upstream_check_module）实现状态感知；其原生行为按序分发请求，不判断后端存活与否，须结合主动探测与max_fails/fail_timeout等被动机制才能避免故障节点持续接收请求。
Nginx 默认的轮询（Round Robin）调度本身不自带健康检查能力，必须配合 health_check 指令（需启用 stream 或 http 模块中的上游健康监测机制）或第三方模块（如 nginx_upstream_check_module），才能实现“轮询 + 状态感知”的动态负载均衡。
轮询的基本行为与局限
原生轮询按顺序将请求分发给 upstream 中定义的服务器，不判断后端是否存活或响应是否正常。一旦某台服务器宕机或响应超时，Nginx 仍会继续向其转发请求，直到连接失败触发重试或超时——这会造成请求失败率上升、用户体验下降。
- 默认不标记失效节点，也不自动剔除
- 无主动探测机制，仅依赖被动错误（connect timeout / read timeout / 5xx）触发临时摘除
- 失败后默认重试同一 upstream 组内其他节点（受
proxy_next_upstream控制）
启用主动健康检查（HTTP 场景）
在 http 块中配置 upstream 时，可通过 health_check 子指令开启周期性 HTTP 探测（要求 Nginx ≥ 1.11.0，且编译时启用了 http_health_check 模块）：
- 使用
health_check interval=2 fails=2 passes=2 uri=/health表示每 2 秒 GET /health，连续 2 次失败则标记为 down，连续 2 次成功恢复为 up - 探测路径需返回 HTTP 200，且响应体可为空；非 2xx/3xx 响应均视为失败
- 该机制独立于 proxy_pass 请求流，不影响业务流量，但要求后端提供稳定可用的探针接口
结合 passive 状态反馈增强鲁棒性
即使启用主动检查，仍建议保留被动错误处理逻辑，形成双保险：
- 在 location 或 upstream 中设置
proxy_next_upstream error timeout http_500 http_502 http_503 http_504 - 配合
proxy_next_upstream_tries 3和proxy_next_upstream_timeout 10s控制重试范围 - 注意：被动失败不会改变 upstream 节点的长期状态（除非配合
max_fails+fail_timeout）
例如：server 192.168.1.10:8080 max_fails=3 fail_timeout=30s; 表示 30 秒内失败 3 次后，该节点被标记为不可用，持续 30 秒不再参与轮询分发。
状态同步与一致性注意事项
健康状态是 worker 进程本地维护的，多 worker 下存在短暂不一致可能；Nginx 官方未提供跨 worker 共享状态的机制（如共享内存健康映射表），因此：
- 各 worker 独立执行探测和标记，可能导致不同 worker 对同一后端状态判断不同步
- 高并发下若某节点刚恢复，部分 worker 可能仍将其视为 down，需依赖探测周期收敛
- 生产环境建议搭配服务发现（如 Consul + nginx-module-consul）或外部 LB（如 Envoy）弥补该限制
