least_conn在长连接场景下确实有效，它依据各后端当前未关闭连接数动态调度，通过wrk压测、stub_status监控及合理keepalive配置可验证其均衡效果。
直接用长轮询接口压测，就能看清 least_conn 在长连接场景下是否真正在起作用。它不看响应快慢，只盯每个后端当前有多少没关闭的连接，所以测试核心是观察“连接堆积有没有被绕开”。
准备能体现长连接特征的后端服务
部署至少两台后端，每台提供一个模拟长轮询的 HTTP 接口：
- 返回前 sleep 5–10 秒，真实模拟等待事件的长连接行为
- 使用 HTTP/1.1 并开启 keepalive，避免短连接干扰连接数统计
- 后端禁用 linger 或设为 0，防止主动快速断连，否则 Nginx 会误判连接已释放
配置 upstream 启用 least_conn 和合理连接池
在 Nginx 的 upstream 块中明确启用 least_conn，并配 keepalive 提升稳定性：
- keepalive 值建议设为 16–32，过大容易让空闲连接虚高“账面连接数”，干扰调度判断
- location 中要透传 Connection 头：proxy_http_version 1.1; proxy_set_header Connection '';
- 健康检查必须开启（如 health_check interval=3 fails=2），否则高延迟节点不会被及时摘除
用 wrk 等工具做持续长连接压测
不用 ab 这类短连接工具，改用支持长连接的压测方式：
- 用 wrk 发起 100+ 并发，每个请求保持连接直到服务返回（即真正长轮询）
- 运行 30–60 秒，期间持续有新请求接入，模拟真实用户不断建连
- 重点看各后端 access log 的请求数分布：least_conn 下应明显比轮询更均衡，尤其当某台后端因延迟卡住时，新请求会自动绕开它
通过 stub_status 实时验证连接数分配逻辑
开启 stub_status 模块，访问 /nginx_status 查看每台 upstream server 的活跃连接数：
- 对比压测前后 conn_active 值变化，确认 least_conn 确实在选“数字最小”的那个
- 若某台后端连接数持续远高于其他节点，先检查健康检查是否生效、max_fails/fail_timeout 是否配置，再排查 keepalive 是否过大导致空闲连接占满“名额”
- 可配合 proxy_next_upstream timeout http_504 使用，让超时请求有机会重试到更空闲的节点
