least_conn负载不均主因是连接数统计失真、keepalive滞留及隐式会话粘性；需对比nginx active connections与系统established数，检查后端keepalive超时、upstream keepalive配置、业务长连接特征，并通过状态页监控、抓包和限流验证。
排查 least_conn 负载均衡下某台后端服务器频繁满载，核心思路是：确认“连接数”是否真实反映负载、检查连接生命周期是否异常、排除非均衡因素干扰。
确认 Nginx 统计的连接数是否准确
Nginx 的 least_conn 算法只统计当前活跃的 upstream 连接（即已建立但尚未关闭的 TCP 连接），不考虑请求处理时长、CPU、内存等实际资源消耗。如果某台机器响应慢但连接很快释放，它可能长期“低连接数”；反之，若它响应快但连接被客户端长时间复用（如 HTTP/1.1 keepalive 未及时断开），连接数会虚高。
- 在 Nginx 主配置中开启
upstream状态页：upstream backend { least_conn; server 192.168.1.10:8080; server 192.168.1.11:8080; }，再配置location /upstream_status { stub_status; } - 访问
/upstream_status查看各节点的Active connections值——这是 Nginx 当前认为的“连接数”，也是least_conn决策依据 - 对比该值与目标机器上真实的 ESTABLISHED 连接数：
ss -tan | grep :8080 | grep ESTAB | wc -l，若两者差异大（比如 Nginx 显示 5，系统显示 200），说明连接未被及时回收或存在连接泄漏
检查后端服务连接保持行为
HTTP/1.1 默认启用 keepalive，客户端可复用 TCP 连接发多个请求。若后端应用（如 Tomcat、Gunicorn）或反向代理（如另一层 Nginx）设置了过长的 keepalive_timeout，会导致连接长期挂起在一台机器上，Nginx 误判其“轻负载”而持续转发新请求，最终堆积。
- 检查后端服务的 keepalive 设置：Tomcat 的
connectionTimeout和keepAliveTimeout；Node.js 的server.keepAliveTimeout；Gunicorn 的--keep-alive - 检查 Nginx upstream 中是否配置了
keepalive指令（如keepalive 32;），该指令控制 Nginx 到后端的连接池大小，若设置过大且后端不主动关闭空闲连接，也会造成连接滞留 - 临时在问题机器上抓包验证：
tcpdump -i any port 8080 -w debug.pcap，观察 FIN/RST 是否及时发出，是否存在大量 TIME_WAIT 或 CLOSE_WAIT
排查请求特征与会话粘性干扰
least_conn 是无状态算法，但实际业务中常伴随隐式粘性：例如 WebSocket 长连接、上传大文件阻塞、或客户端使用 IP Hash 之外的其他方式（如 cookie、JWT）实现逻辑会话绑定，导致流量持续打到同一台机器。
- 查看 access log 中问题机器的请求分布：
awk '$9 ~ /^200$/ && $1 ~ /192\.168\.1\.10/ {print $7}' access.log | sort | uniq -c | sort -nr | head -10，看是否有少数 URL 占比极高（如上传接口、长轮询） - 检查是否启用了
ip_hash或hash $cookie_sessionid consistent;等指令，即使注释了也可能被 include 进来；least_conn不兼容这些策略，混用会导致行为不可预期 - 确认客户端是否复用连接：用 curl 测试时加
-H "Connection: close"强制关闭，对比并发请求下各后端连接数变化，判断是否受 keepalive 影响
补充观测：连接增长趋势与超时行为
单纯看瞬时连接数不够，需观察动态变化。满载往往不是突变，而是缓慢爬升后卡住。
- 用脚本定时采集
/upstream_status数据（如每 5 秒一次），绘图观察问题机器 Active connections 是否呈阶梯式上升、或在某个值附近震荡不降 - 检查 Nginx error log 中是否有
upstream timed out或no live upstreams，表明后端响应慢或崩溃，Nginx 可能因失败重试加剧连接堆积 - 在 upstream 块中临时添加
max_conns=1024;限制单机最大连接数，并配queue 100 timeout=30s;，让 Nginx 主动排队而非盲目转发，可缓解雪崩并暴露真实瓶颈点
