轮询是Nginx最轻量的负载均衡机制，需通过max_fails、fail_timeout、down、backup和keepalive等参数加固才能实现高可用，适用于无状态且响应稳定的服务，上线前须验证语法、故障转移与实际分发效果。
轮询机制是 Nginx 实现高可用负载均衡最直接、最轻量的起点。它不依赖外部组件，天然支持请求均匀分发，但要真正支撑生产级高可用，不能只靠“默认启用”，必须围绕健康感知、故障转移和资源适配做针对性加固。
轮询的基础配置与默认行为
只要在 upstream 块中列出多个后端 server，Nginx 就自动启用轮询：
- 请求按顺序逐一分发：第1个到 server A，第2个到 server B，第3个回到 server A……循环往复
- 所有 server 权重默认为 1，等概率参与调度
- 不主动探测后端状态——即使某台机器已关机，Nginx 仍会尝试转发，直到连接超时或失败累积触发剔除
让轮询具备高可用能力的关键参数
默认轮询只是“分发”，加上这几项配置才能变成“智能分发”：
-
容错机制：为每个 server 设置
max_fails=3 fail_timeout=30s，表示连续 3 次失败（如连接拒绝、超时、5xx）后，30 秒内不再派发新请求 -
主动标记下线：用
down标记临时维护中的节点，例如server 192.168.1.11:80 down;，Nginx 完全跳过该节点 -
备份节点：添加
backup标识，仅当所有主节点不可用时才启用，适合灾备兜底 -
连接复用：在 upstream 中加
keepalive 32;，复用后端 TCP 连接，减少握手开销，提升吞吐
轮询适用场景与性能边界判断
轮询不是万能的，它的合理性取决于后端服务的特征：
- 适合无状态、响应时间稳定的服务，比如静态资源服务、RESTful API 网关
- 若各节点响应时间差异超过 20%，说明硬件或负载不均，应改用加权轮询或 least_conn
- 不适合需要会话保持的业务（如含 session 的登录态），此时 ip_hash 更合适，但注意它不兼容 weight 参数
- 在短连接高频场景下，轮询可能因建连延迟导致实际负载不均，可配合
least_conn指令缓解
上线前必须验证的三项实操检查
配置写完不等于生效，需通过真实行为确认轮询真正可靠：
- 执行
nginx -t校验语法，再nginx -s reload平滑加载，避免配置错误中断服务 - 停掉其中一台后端，观察 Nginx error 日志是否出现
connect() failed，同时检查其余节点访问日志是否承接全部流量 - 用
curl -I http://your-domain多次请求，配合响应头（如自定义X-Upstream）或后端日志，确认请求确实落在不同服务器上
