轮询算法仅控制新请求派发顺序，不感知后端活跃连接数，启用http keep-alive时易导致连接分布严重倾斜；排查需聚焦实际连接分布（如$upstream_addr统计、ss命令查看estab连接）、排除ip_hash等干扰配置，并可切换least_conn算法或收紧upstream keepalive参数验证优化。
轮询本身不保证请求实际负载均衡，尤其在启用 HTTP Keepalive 时，容易出现“日志显示均匀、真实连接严重倾斜”的假象。排查重点不是看请求次数，而是看连接分布和后端状态。
查 upstream 连接实际分布，而非请求数
轮询只控制新请求派发顺序，不感知后端当前活跃连接数。一个复用的长连接可能承载上百个请求，全部落到同一台 backend，但 access log 里只记一次 $upstream_addr。
- 在 Nginx 日志中启用 $upstream_addr 字段，统计不同 IP:PORT 对的数量（不是请求数），看是否长期固定在少数几台
- 在 backend 服务器执行 ss -tnp | grep :服务端口，观察 ESTAB 状态连接的实际分布
- 临时关闭 proxy_http_version 1.1 和 Connection 头，对比连接分布变化，确认是否由 keepalive 复用导致
验证轮询逻辑是否被干扰
某些配置会覆盖或削弱轮询效果，造成事实上的非轮询行为。
- 检查是否误配了 ip_hash、hash $request_uri 或其他 hash 类指令——它们强制绑定客户端与后端，必然导致不均
- 确认所有 backend server 行未意外设置 weight=0 或 down，否则会被跳过
- 查看是否有 max_fails 触发临时剔除，某台节点因偶发超时被持续隔离
换 least_conn 验证是否为连接级失衡
如果切换为 least_conn 后连接分布明显改善，基本可断定是 keepalive 复用 + 轮询策略不匹配所致。
- 配置示例：upstream backend { least_conn; server 10.0.1.10:8080; server 10.0.1.11:8080; }
- 该算法直接基于后端当前活跃连接数选节点，天然适配长连接场景
- Nginx 1.15+ 支持加权 least_conn，如需能力差异可保留 weight 参数
收紧 upstream keepalive 参数
Nginx 自身的连接池管理不当，会加剧连接滞留问题。
- 在 upstream 块中显式配置 keepalive 32（建议值 16–64，视并发量调整）
- 在 location 中主动关闭与 client 的 keepalive：proxy_http_version 1.1; proxy_set_header Connection '';
- 同步调小后端服务的 keepalive_timeout（如 Tomcat 的 keepAliveTimeout），避免空闲连接长期占位
