least_conn通过实时选择活跃连接数最少的健康后端实现负载均衡，需配合keepalive复用、健康检查及max_conns配置才能真实反映负载；多节点连接数相同时按weight加权轮询。
要真实测出 least_conn 在不同连接保持时间下的表现，不能只看配置是否生效，得让连接“活”起来、有差异、可观察——重点是制造可控的连接生命周期，并验证 Nginx 是否真的按“此刻谁连得最少”来分发。
一、准备可区分响应节奏的后端服务
least_conn 不感知耗时，只数连接数。所以必须让后端主动控制连接释放时机：
- 用两个简单 HTTP 服务：一个立即返回（
sleep(0)），一个固定延迟返回（如sleep(3)或sleep(10)） - 确保它们都支持 HTTP/1.1 keepalive，且不主动关闭连接（比如 Nginx 反向代理时设
proxy_http_version 1.1; proxy_set_header Connection '';） - 避免后端自身限制连接复用（如 Tomcat 的
maxKeepAliveRequests=1会强制断连，干扰统计）
二、配置带 keepalive 和健康检查的 upstream
空连接池或无健康检查会让 least_conn 失效：
- upstream 中必须启用
keepalive 32（建议 16–64），否则短连接频繁新建/断开，连接数跳变剧烈，“最少”变成伪随机 - 必须配
max_fails=2 fail_timeout=10s或启用主动健康检查（health_check），否则慢节点卡住但不断连，仍持续收新请求 - 示例：
least_conn;
keepalive 32;
server 127.0.0.1:8081 max_fails=2 fail_timeout=10s;
server 127.0.0.1:8082 max_fails=2 fail_timeout=10s;
}
三、用压测工具制造稳定长连接流
轮询式短请求压测看不出 least_conn 优势，要模拟真实长连接场景：
- 用
wrk -t4 -c100 -d30s --http-version 1.1（开启 HTTP/1.1 持久连接） - 或用
ab -n 1000 -c 50 -k（-k启用 keepalive） - 关键：压测期间不退出连接，让连接在后端停留不同时间（比如 A 节点响应快、连接秒关；B 节点响应慢、连接挂 10 秒）
四、实时验证连接数分布是否符合预期
不能只看日志条数，要看“此刻谁手上的连接最多”：
- 开启
stub_status，访问/nginx_status查看各 upstream 的Active connections实时值 - 对比两台后端 access log 中的请求数：慢节点请求数应明显少于快节点（尤其在压测中后期）
- 故意延长一台后端响应时间（如加
sleep(5)），观察其 Active connections 是否快速升至高位，而新请求是否几乎全落到另一台 - 若连接数长期接近、请求数却均匀分布，说明 least_conn 未起效——大概率是 keepalive 未生效或健康检查缺失
