Nginx轮询机制默认按配置顺序循环分发请求，实现轻量、无状态的负载均衡；需配合max_fails、fail_timeout等参数实现自动故障剔除与恢复，并适用于性能相近、无状态的后端场景。
轮询是怎么工作的
轮询把请求一个接一个地分给 upstream 中配置的每台服务器，循环往复。比如三台服务器 A、B、C，第 1 个请求到 A，第 2 个到 B，第 3 个到 C，第 4 个又回到 A，以此类推。
它不看响应时间、不查 CPU 使用率、也不统计当前连接数，只依赖配置顺序和基础计数器。这种“无状态”设计让它轻量、稳定、可预测。
如何让轮询真正“自动”起来
纯轮询本身不带故障感知能力，但配合几个关键参数，就能实现自动剔除与恢复：
- max_fails：允许连续失败多少次（默认为 1），超过就标记该 server 为不可用
- fail_timeout：失败达到 max_fails 后，暂停分发请求的时间（单位秒），超时后尝试恢复
- down：显式标记某台 server 暂不参与轮询（常用于维护）
- backup：仅当其他 server 全部不可用时才启用，适合灾备节点
示例配置：
upstream backend {
server 192.168.1.10 max_fails=3 fail_timeout=30s;
server 192.168.1.11 max_fails=3 fail_timeout=30s;
server 192.168.1.12 backup;
}
轮询的适用边界在哪
它适合后端服务性能相近、处理耗时波动小、且本身无状态的场景。常见于静态资源服务、RESTful API 网关、或已做 session 外置（如 Redis 存储）的应用。
如果遇到以下情况，轮询可能不是最优选择：
- 服务器硬件差异大（比如一台 16 核，一台 4 核）→ 改用加权轮询
- 需要用户会话始终落在同一台机器（比如没做 session 共享）→ 改用 ip_hash
- 大量长连接或请求耗时极不均匀（如含文件上传、报表生成）→ 改用 least_conn
实际部署中的小技巧
轮询看似简单，但几个细节会影响真实效果：
- 确保 upstream 内 server 地址写法一致（IP+端口 或 域名），避免因解析延迟导致调度偏差
- 配合
keepalive指令复用连接，减少握手开销，尤其对高频短请求更明显 - reload 配置时，Nginx 不中断已有连接，新请求才走新 upstream 规则，适合灰度切换
- 可通过
nginx -t验证语法，再用nginx -s reload平滑生效
