least_conn 实现负荷均衡需验证后端ESTABLISHED连接数是否趋于一致：通过stub_status和$upstream_addr日志统计代理侧连接分布，结合ss命令核验后端真实连接数，并排除keep-alive配置缺失、max_conns错误、健康检查失效等干扰。
要验证 least_conn 是否真正实现了后端节点负荷均衡，不能只看配置是否写对，关键得观测“连接数”在各节点间的实际分布是否趋于一致——因为 least_conn 的调度依据就是 Nginx 维护的活跃连接数（ESTABLISHED TCP 连接），不是请求数、响应时间或 CPU。
观察 Nginx 自身连接分发情况
启用 stub_status 模块，它是最直接的入口：
- 在 server 块中添加 location /nginx_status { stub_status; allow 127.0.0.1; deny all; }，重启 Nginx
- 访问 http://your-nginx-ip/nginx_status，查看 Active connections 及各 upstream server 的连接计数（需配合
$upstream_addr日志变量） - 在 log_format 中加入
$upstream_addr，例如：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_addr"';
压测时抓取 access.log，用awk '{print $14}' access.log | sort | uniq -c | sort -nr统计每台后端被选中的频次和连接归属
核验后端真实 ESTABLISHED 连接数
Nginx 的连接统计只是代理侧视角，必须与后端真实状态交叉比对：
- 在每台后端服务器上执行：
ss -s | grep "tcp:"或更精准地ss -tn state established '( dport = :8080 )' | wc -l（替换为你的服务端口） - 持续采样（如每 5 秒一次），记录一段时间内的连接数曲线，观察峰值/均值是否接近
- 若某节点长期显著偏高（比如高出均值 50% 以上），说明 least_conn 未起效，可能原因包括：该节点 max_conns 设置过低、健康检查失效导致其被持续跳过、或后端主动关闭连接慢（linger 长），使连接滞留
压测中做定向干扰验证策略逻辑
用可控方式触发 least_conn 的 fallback 行为，确认它是否按预期降级：
- 临时将一台后端的
max_conns=1，其余设为较大值（如 1000），然后发起并发请求 - 观察日志和连接数：当该节点连接数达 1 后，新请求应立刻转向其他节点；若仍持续打过去，说明 max_conns 未生效或配置位置错误（必须写在 server 行末尾）
- 再人为让一台后端失联（如关服务或防火墙拦截），检查其余节点连接数是否自动承接流量，且 stub_status 中该节点状态变为 down —— 这验证了健康检查与 least_conn 的协同有效性
排除常见干扰因素
很多“不均衡”其实是外部条件掩盖了 least_conn 的效果：
- 确保压测工具复用连接（如 wrk 加
-H "Connection: keep-alive"，ab 加-k），否则短连接下连接数瞬时归零，least_conn 退化为轮询 - 检查后端是否支持 HTTP Keep-Alive：Tomcat 要设置
keepAliveTimeout，Node.js 默认支持，Spring Boot 内嵌 Tomcat 需显式配置 - 确认 Nginx 的
keepalive 32;已写在 upstream 块内，且 proxy_http_version 为 1.1、proxy_set_header Connection '' 已配置，否则连接无法复用
