轮询模式本身不会导致流量聚集，真正原因在于配置干扰、健康状态不一致或worker局部行为误读；需清理weight、hash等干扰指令，统一健康检查参数，并通过日志验证长期分发均衡性。
轮询模式本身不会导致流量聚集，真正引发单机流量偏高的是配置干扰、健康状态不一致或 worker 进程局部行为被误读。关键不是“防聚集”，而是让轮询回归确定性、稳定性和可观测性。
清理所有干扰配置，确保纯轮询生效
轮询是严格按 server 列表顺序循环分发的，但以下配置会覆盖它：
- 删掉所有 weight= 参数——哪怕只有一台设了 weight，整个 upstream 就变成加权轮询，不再均等
- 彻底移除 ip_hash、hash $arg_id、least_conn 等指令——注释掉也不行，必须整行删除
- 每台 server 保持最简格式：server 192.168.1.10:8080;，不带 backup、down、max_fails 等修饰
统一健康检查参数，防止节点被“隐形剔除”
轮询不感知状态，但健康检查配置不一致会让某台服务器频繁被临时摘除，造成实际流量向剩余节点倾斜：
- 为每台 server 显式加上相同探测参数：max_fails=2 fail_timeout=15s
- 避免 A 节点用 max_fails=1、B 节点用 max_fails=5 这类不对齐配置
- 这样所有节点在异常时被摘除的门槛一致，轮询队列才稳定
用日志验证真实分发路径，别靠感觉判断
worker 进程各自维护轮询指针，短时间可能看到某台连续收请求，这是正常现象。判断是否真聚集，得看长期分布：
- 在 http 块定义日志格式：log_format upstream_log '$remote_addr - $upstream_addr [$time_local] "$request" $status';
- 在 location 中启用：access_log /var/log/nginx/upstream.log upstream_log;
- 发起上百次请求后查日志，各后端 IP 出现次数差异应 ≤3%；若持续超 10%，优先排查是否有节点因超时被反复剔除
接受 worker 局部波动，关注整体统计均衡
Nginx 每个 worker 独立计数，高并发瞬间出现局部连续打到同一台，属于设计使然，不是故障：
- 这不是轮询失效，而是多进程模型下的正常表现
- 长期（数百次以上）统计中，各后端 access.log 行数偏差控制在 1%~3% 即属健康
- 无需调大 worker 数量或改用其他算法来“修正”，那反而引入复杂性和不确定性
