Nginx轮询配置需在upstream块中顺序列出server（如192.168.1.101:8080），默认权重1:1:1；必须搭配max_fails=3 fail_timeout=30s实现基础健康检查；不适用于性能差异超20%、响应延迟悬殊或需会话保持的场景。
Linux 下 Nginx 轮询（Round Robin）负载均衡配置本身很简单，但真正用稳、用准，关键在细节处理和场景适配。它不是“写完就能跑”，而是需要结合后端能力、故障响应和验证手段综合落地。
轮询配置怎么写才规范
轮询是 Nginx 默认策略，无需显式声明 round_robin，只要在 upstream 块中按顺序列出 server 即可生效：
- 每个
server行代表一个后端节点，支持 IP + 端口（如192.168.1.101:8080），也支持域名（需确保 Nginx 能解析） - 默认权重为 1，三台服务器就按 1:1:1 循环分发
- 不建议混用带端口和不带端口的写法，统一格式便于维护
- 避免在
server行末尾加斜杠（如192.168.1.101/），Nginx 会报语法错误
必须加的健康保障参数
轮询本身不主动探测服务是否“真可用”，只在建立 TCP 连接失败时触发隔离。因此，务必补上基础容错参数：
-
max_fails=3：连续 3 次连接失败（如超时或拒绝），标记该节点为不可用 -
fail_timeout=30s：进入不可用状态后，30 秒内不再转发请求；超时后尝试恢复连接 - 两者要成对使用，单独写一个无效
- 示例：
server 192.168.1.101:8080 max_fails=3 fail_timeout=30s;
什么时候不该用纯轮询
轮询公平但“无脑”，遇到以下情况容易出问题：
- 后端服务器 CPU、内存或磁盘 I/O 差异超过 20%，会导致高配节点空转、低配节点积压请求
- 接口耗时差异大（比如有的响应 50ms，有的要 1.5s），轮询会让慢节点持续排队，拖累整体 P95 延迟
- 业务依赖会话状态（如登录态、订单草稿），轮询会把同一用户请求打到不同机器，造成数据丢失或重复提交
- 此时应改用加权轮询（按性能分配流量）或
ip_hash（绑定用户 IP）
上线前必须做的三件事
配置写完不等于能用，得验证真实效果：
- 用
nginx -t检查语法，再用nginx -s reload平滑重载，别直接 kill 进程 - 用
curl -s http://your-nginx-ip/连续执行 10 次，观察返回内容是否按后端标识循环出现（如 server1 → server2 → server3 → server1…） - 查看各后端服务器的 access 日志，确认时间戳和来源 IP 是否呈规律交替，排除浏览器 Keep-Alive 复用连接干扰
