最少连接策略（least_conn）不直接降低响应耗时，而是通过将新请求分配给活跃连接数最少的后端，避开长任务节点以减少排队等待；其效果依赖健康检查、keepalive配置、max_conns限流及stream模块支持TCP长连接场景。
最少连接策略（least_conn）本身不直接降低响应耗时，它只是把新请求发给当前活跃连接数最少的后端。真正缩短耗时的关键，在于它能避开正忙于处理长任务的节点——比如一个还在跑报表导出或模型推理的服务器，从而减少排队等待时间。但这个效果必须依赖几项关键配置才能落地。
健康检查必须到位
如果某台后端已卡顿但 TCP 连接还没断，least_conn 会继续往它派请求，连接数可能仍显示很低，结果就是请求堆积、超时增多。所以：
- 每个
server行必须配max_fails=2 fail_timeout=15s，让失败触发临时剔除 - 配合
proxy_next_upstream error timeout http_500 http_502，确保后端返回异常状态时能重试其他节点 - 有条件的话，启用主动健康检查（
health_check），比被动探测更及时
keepalive 要开启且合理设置
least_conn 统计的是“活跃 TCP 连接数”，包括 keepalive 空闲连接。如果后端每请求都新建连接，那连接数≈请求数，算法就退化成轮询。要让它反映真实负载：
- Nginx upstream 中加
keepalive 32;（不宜过大，否则空闲连接拉高账面数值） - 后端服务需开启 HTTP Keep-Alive，并设合理 timeout（如 Tomcat 的
maxKeepAliveRequests> 0） - 客户端也得支持复用（现代浏览器默认开启，移动端需确认）
性能差异靠 max_conns 来体现
least_conn 忽略 weight 参数，不能靠 weight 区分强弱节点。想让高性能机器多承接流量，要用 max_conns：
- 例如：高配节点设
server 10.0.1.10:8080 max_conns=2000; - 普通节点设
server 10.0.1.11:8080 max_conns=800; - 当活跃连接达到上限，least_conn 自动跳过，相当于软性容量控制
TCP 长连接场景需用 stream 模块
如果是数据库、WebSocket 或游戏网关这类 TCP 层服务，HTTP 的 upstream 不适用：
- 编译 Nginx 时确认含
--with-stream，运行中用nginx -V | grep with-stream验证 - 在
stream { }块里定义 upstream，同样支持least_conn和max_conns - 注意多 worker 场景下要加
zone tcp_pool 64k共享状态
