nginx轮询调度默认启用，需配置两个以上后端server，按顺序循环分发；必须设置max_fails和fail_timeout实现被动健康检查；backup节点仅在主节点全不可用时启用，且须同样配置健康检查参数。
Nginx 轮询调度是高可用集群中最基础也最常用的负载分发方式，它本身不带健康感知能力，但作为默认策略，天然适合作为高可用架构的起点——只要配合几个关键参数，就能快速构建出具备基本容错能力的稳定分发层。
轮询如何自动启用
只要在 upstream 块中配置两个或以上后端 server，Nginx 就会默认启用轮询，无需额外声明 round_robin 或其他指令：
- 请求按配置顺序严格循环：server1 → server2 → server3 → server1…
- 每台 server 默认权重为 1，不写
weight即表示均等分配 - 建议使用内网 IP + 明确端口（如
10.0.1.5:8080），避免 DNS 解析延迟 - 确保 Nginx 已编译含
http_upstream_module（开源版默认包含）
必须加的健康检查参数
轮询不会主动探测后端是否存活，必须靠 max_fails 和 fail_timeout 实现被动健康检查：
-
max_fails=3 fail_timeout=30s：某台 server 连续 3 次失败（连接超时、拒绝、502/503 等代理错误），则接下来 30 秒内跳过该节点 - 失败判定不包含应用返回的 500，如需检测 HTTP 状态码（比如 5xx 视为异常），需引入
upstream_check_module或使用 Nginx Plus - 每个
server行都应显式加上这对参数，不能只配在 upstream 顶层
备份节点与降级能力
当所有主节点都被标记为不可用时，backup 节点才参与调度，这是服务兜底的关键设计：
- 在 server 行末尾添加
backup，例如：server 10.0.1.100:8080 backup; -
backup仅在轮询模式下生效；ip_hash、least_conn 等策略不支持 - 不能所有 server 都设为 backup，否则无可用节点，客户端将收到 502 错误
- backup 节点也应配置
max_fails/fail_timeout，防止它上线后自身故障导致雪崩
辅助优化与验证要点
让轮询真正落地，还需关注连接效率和实际分流效果：
- 启用
keepalive复用上游连接，减少 TCP 握手开销（配合proxy_http_version 1.1和proxy_set_header Connection ''） - 通过 access_log 中的
$upstream_addr字段确认请求是否真实落到不同后端 - 手动模拟某台 server 宕机，观察日志中是否在
fail_timeout内停止向其转发 - 主动维护时可用
down标记临时下线节点，Nginx 会立即跳过该地址
