本质是连接复用与轮询策略冲突导致负载不均，应改用least_conn算法、优化keepalive参数并加强健康检查。
后端开启 Keepalive 后 Nginx 负载不均，本质不是“分流错了”，而是连接复用机制与默认轮询策略产生隐性冲突：长连接持续占用某台 backend，新请求仍按轮询节奏派发，导致连接数和实际负载严重偏离预期。关键要打破“只看请求次数、不管连接状态”的盲区。
确认是否真为连接级失衡
轮询（包括加权轮询）只控制新请求的派发频次，不感知后端当前活跃连接数。若后端启用了 HTTP/1.1 keepalive 且客户端复用连接（如浏览器、移动端 SDK），一个 TCP 连接可能承载数十甚至上百个请求——这些请求全部落到同一台 server，但日志里只记作“1 条连接 + 多条请求”，容易误判为“流量分配正常”。
- 查 Nginx access log 中 $upstream_addr 字段，统计各 backend 的**独立连接 IP:PORT 对数量**（而非请求数），看是否长期固定在少数几台
- 用 ss -tnp | grep :backend_port 在 backend 侧观察 ESTAB 状态连接的实际分布
- 对比 proxy_http_version 1.1 + proxy_set_header Connection '' 开启前后，连接分布变化
优先启用 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：server 10.0.1.10:8080 weight=3; 仍生效，连接数少且能力更强的节点会自然承接更多新连接
- 注意：不要混用 ip_hash 或 hash $request_uri，它们会强制绑定，加剧连接集中
收紧 keepalive 连接管理参数
Nginx 自身的 upstream keepalive 设置不当，会放大失衡——例如 pool 过大、复用超时过长，导致连接长期滞留某 backend。
- 在 upstream 块中显式配置：keepalive 32;（建议 16–64，根据并发量调整）
- 在 location 中关闭不必要的连接保持：proxy_http_version 1.1; proxy_set_header Connection ''; proxy_set_header Keep-Alive ''; （让 Nginx 主动断开与 client 的 keepalive，仅保留与 backend 的可控复用）
- 后端服务侧同步调小 keepalive_timeout（如 Tomcat 的 connectionTimeout 和 keepAliveTimeout），避免空闲连接僵死占位
补充 passive 健康检查防“假存活”
keepalive 下更易暴露“假存活”问题：后端进程卡死、TCP 端口通但 HTTP 无响应，Nginx 却因连接未断而持续复用该连接，所有后续请求全打到这台“幽灵节点”上。
- 每个 server 行加上：max_fails=2 fail_timeout=10s;，让 Nginx 在连续失败后主动剔除节点
- 配合 proxy_next_upstream error timeout http_500 http_502 http_503 http_504;，确保异常响应触发重试与故障转移
- 若需主动探测，使用 nginx_upstream_check_module 检查 /health 端点（需编译），比 passive 更早发现僵死进程
