Nginx轮询默认无状态感知，需依赖被动或主动健康检查实现可用性保障：被动检查通过max_fails、fail_timeout和proxy_next_upstream配置实现失败重试；主动检查需扩展模块，探测/actuator/health并校验响应，配合状态暴露与告警闭环。
Nginx 默认轮询调度本身不感知后端服务器状态，它只按配置顺序机械分发请求，既不看响应时间、连接数，也不主动判断节点是否存活。真正的状态感知必须靠额外机制补足。
轮询默认行为：无状态、无反馈
- 请求严格按
server声明顺序循环分配（如 A→B→C→A），每台权重默认为 1 - 不检查后端是否响应、是否返回 5xx、是否超时——哪怕某节点已宕机，只要没被标记为 down，轮询仍会把请求发过去
-
max_fails=1和fail_timeout=10s是被动触发的兜底机制，但需真实请求失败后才起作用，存在滞后性
必须搭配健康检查才能“看清”状态
仅靠轮询无法实现可用性保障，需组合以下两类机制：
-
被动健康检查（开箱即用）
- 在
upstream的每个server行添加max_fails=3 fail_timeout=30s - 配合
proxy_next_upstream error timeout http_502 http_503 http_504，让失败请求自动重试其他节点 - 日志中记录
$upstream_addr $upstream_status $upstream_response_time，用于回溯分析单点异常
- 在
-
主动健康检查（需扩展支持）
- 开源版需编译
nginx_upstream_check_module，配置check interval=3 rise=2 fall=3 type=http - 探测路径设为
/actuator/health，用check_http_expect_alive http_2xx+ 自定义响应体校验（如"status\":\"UP"） - 禁用原生
max_fails（设为0），避免被动与主动机制冲突
- 开源版需编译
状态要能被看见、被使用，才算闭环
- 暴露
/status接口（如check_status或 Lua 动态聚合），返回各节点 IP、当前状态、失败次数、最后探测时间 - 限制访问来源（如
allow 10.0.0.0/8; deny all;），防止信息泄露 - 对接 Prometheus 抓取指标，对
upstream_down == 1设置告警；或在balancer_by_lua_block中读取健康评分，实时跳过低分节点
不复杂但容易忽略
