轮询分配不均主因是keep-alive导致连接扎堆而非请求派发错误；应查ss命令的estab连接分布、禁用ip_hash等绑定策略、配置max_fails健康检查，或改用least_conn算法。
轮询负载均衡请求分配不均，往往不是配置写错了，而是实际连接行为和日志观察方式出了偏差。重点要区分“请求次数”和“连接归属”——轮询只管新请求派发顺序，不管这些请求是不是复用同一个长连接落到同一台后端。
看连接分布，别只盯请求日志
access log 里的 $upstream_addr 字段默认记录的是“请求打到哪台 backend”，但若客户端启用了 HTTP Keep-Alive，多个请求可能共用一个 TCP 连接，全部落在同一台 server 上。这时日志看似均匀（比如每台各 300 条），实际连接却集中在 1–2 台。
- 用 ss -tnp | grep :backend_port 在后端服务器上查 ESTAB 状态连接，看 IP:PORT 对是否长期固定在少数节点
- 统计 Nginx access log 中 $upstream_addr 的 唯一连接地址数（如 10.0.1.10:8080#12345），而非总请求数
- 临时关闭 keepalive 测试：在 location 块中加 proxy_http_version 1.0;，再对比连接分布变化
检查轮询是否被其他策略干扰
ip_hash、hash $request_uri 或 sticky cookie 这类绑定型策略，会强制同一类请求始终打到同一台 backend，直接覆盖轮询逻辑。
- 确认 upstream 块中没出现 ip_hash、hash 或 sticky 指令
- 检查是否有第三方模块（如 nginx-sticky-module）或 Nginx Proxy Manager 的高级路由规则悄悄启用了会话保持
- 用 curl -H "User-Agent: test1" 和 curl -H "User-Agent: test2" 分别请求，看是否始终落到同一台——这是 hash 类策略的典型表现
验证后端健康状态与故障剔除是否生效
轮询本身不感知后端真实负载，但会跳过标记为 down 的节点。如果某台 server 偶发超时或响应慢，又没配 max_fails，它仍会被持续轮到，造成“请求分过去了、但处理不过来”的假性不均。
- 检查 upstream server 行是否带 max_fails=3 fail_timeout=30s 参数
- 查 error log 是否有大量 "connect() failed" 或 "no live upstreams" 报错
- 手动模拟故障：停掉一台 backend，观察剩余两台的请求量是否翻倍；恢复后，是否快速重新参与轮询
考虑 least_conn 替代轮询（尤其启用了 Keep-Alive 时）
当后端开启 HTTP/1.1 keepalive 且客户端复用连接频繁时，least_conn 比轮询更贴近真实负载——它每次选的是当前活跃连接最少的节点，天然缓解连接扎堆问题。
- 改 upstream 配置：least_conn; 替换默认轮询逻辑
- 支持加权：server 10.0.1.10:8080 weight=2; 仍有效，能力强的节点在连接数相近时自然承接更多新连接
- 避免混用：不要和 ip_hash、hash 等指令共存，否则 least_conn 不生效
