least_conn在短连接下基本不生效，因其依赖实时活跃连接数，而短连接生命周期过短导致Nginx统计的活跃连接几乎恒为0，使其退化为近似随机分发。
least_conn 在短连接下基本不生效，测试它的“瓶颈”没有实际意义——它不是为短连接设计的。算法依赖实时活跃连接数做调度决策，而短连接建连→发请求→断开全程可能不到100ms，Nginx 统计到的 active connections 几乎始终为 0，导致 least_conn 退化为近似随机分发。
为什么短连接会让 least_conn 失效
核心原因在于连接生命周期太短：
- Nginx 的 upstream 连接统计只在 TCP 连接处于 ESTABLISHED 状态且未关闭时有效；
- 短连接（如 ab -n 1000 -c 100）每秒新建数百连接，但每个连接存活仅几十毫秒，活跃连接数无法形成稳定差值；
- least_conn 每次选节点时看到的都是“几乎全为 0”，失去比较依据，调度行为不可控、不可复现。
如果非要压测，重点不是看算法，而是暴露底层瓶颈
此时测试目标应转向 Nginx 自身或系统层限制，而非 least_conn 的逻辑表现：
-
连接建立速率瓶颈：用 wrk 或 hey 发起高并发短连接（如 -c 2000 -d 30s），观察 Nginx error log 是否出现
connect() failed (24: Too many open files)，检查 ulimit -n 和 net.core.somaxconn 设置； -
TIME_WAIT 泛滥：后端机器执行
ss -s | grep TIME_WAIT，若超数万，说明连接释放过快、端口耗尽，需调优net.ipv4.tcp_tw_reuse和net.ipv4.tcp_fin_timeout； - worker 进程打满：top 中 nginx worker CPU 持续 100%，说明 epoll_wait / accept 频繁触发，已逼近事件处理极限，与 least_conn 无关，而是短连接模型本身开销过大。
真正该测的对比项：换 round-robin 会更差吗？
在纯短连接场景下，least_conn 和 round-robin 表现差异极小，因为两者都缺乏有效负载信号。此时可做对照实验：
- 用相同压测参数，分别配置
least_conn和round_robin（默认）； - 记录两组的总体 QPS、P95 延迟、后端 access.log 请求分布（用
awk '{print $1}'统计来源 IP）； - 你会发现分布标准差接近，延迟曲线重合——这恰恰证明：least_conn 在短连接下没带来收益，也没引入额外损耗。
结论：别在短连接上验证 least_conn
它适用的场景很明确：长轮询、WebSocket、gRPC、AI 推理等连接长期存活的业务。若你的真实后端是短连接模型，应该考虑改用 hash $request_uri 做一致性哈希，或直接上 least_time（需商业版）结合响应时间反馈。least_conn 不是通用解法，强行在错误场景下测“瓶颈”，只会把问题引向系统调优，而非负载均衡策略本身。
