least_conn通过实时比较后端活跃连接数分配请求，压测需用长连接+可控慢响应验证其绕开卡顿节点能力：部署双后端（如100ms/800ms延迟），启用least_conn与keepalive 32，配合max_conns和健康检查，用wrk并发压测并观察/nginx_status连接分布是否均衡。
直接用长连接+慢响应的组合压测，就能清晰看出 least_conn 和轮询（round-robin）的实际差距——它不比谁快，只看谁“手头活儿少”，关键在连接数是否真实、调度是否及时绕开卡住的节点。
准备可控的慢后端服务
部署至少两台后端，每台提供一个可精确控制延迟的 HTTP 接口：
- 用 sleep 模拟长耗时：例如一台固定响应 100ms，另一台固定 800ms，避免随机波动干扰判断
- 禁用后端缓存与异步逻辑，确保每次请求都真实走完延迟路径
- 开启 HTTP/1.1 keep-alive，且设置足够长的 keepalive timeout（如 60s），防止连接提前断开
- 关闭 linger 或设为 0，避免 TCP 连接在后端关闭后还滞留在 ESTABLISHED 状态，导致 Nginx 统计虚高
配置真实反映压力的 upstream
让 Nginx 的连接数统计不“失真”，是 least_conn 发挥作用的前提：
- upstream 块中第一行写 least_conn，后面加 keepalive 32（不宜过大，否则空闲连接占满“名额”）
- location 中必须设置：proxy_http_version 1.1 和 proxy_set_header Connection ''，强制复用连接
- 每个 server 行加上 max_conns=800（按机器能力调整），防止单节点被慢请求锁死
- 配健康检查：max_fails=2 fail_timeout=10s，快速剔除已卡死但 TCP 未断的节点
用 wrk 持续并发压测并观察核心指标
不用 ab 或 curl 循环，要用支持长连接、能持续建连的工具：
- 启动 wrk：比如
wrk -t4 -c200 -d60s http://nginx-ip/long-poll，保持 200 个长连接不断发起新请求 - 压测过程中，反复访问
/nginx_status，看各后端的 Active connections 是否始终接近、无明显单点堆积 - 对比同一压测流量下换用
round-robin的结果：你会看到慢节点连接数飙升，而 least_conn 下分布更平滑 - 检查后端实际 ESTABLISHED 连接数：
ss -n state established '( dport = :8080 )' | wc -l，应与 Nginx 统计基本一致
验证是否真正绕开慢节点
这是 least_conn 的核心价值，不能只看平均值：
- 当某台后端因长尾请求（如一次 5 秒卡顿）导致连接数突增时，观察新请求是否明显转向另一台——查 access.log 的请求数分布，或用
tcpdump抓包确认流向 - 若发现慢节点连接数持续高于其他节点 2 倍以上，检查是否
max_conns未生效、keepalive值过大，或健康检查参数太宽松 - 错误率上升时，重点看
proxy_next_upstream error timeout http_500是否触发重试，配合 least_conn 形成双重保护
