least_conn核心逻辑是将新请求发给当前活跃TCP连接数最少的后端，仅统计Nginx与后端间已建立未关闭的连接，不感知CPU、内存或响应时间；适用于长连接及响应时间差异大场景，多节点连接数相同时按weight加权轮询，需配合keepalive和健康检查才有效。
least_conn 的核心逻辑很简单：每次有新请求进来时，Nginx 会查看 upstream 中所有后端服务器当前与它保持的活跃 TCP 连接数（即已建立、尚未关闭的连接），然后把请求发给其中连接数最少的那个节点。
只看连接数，不看其他指标
它不读取 CPU 使用率、内存占用、响应时间或磁盘 I/O——只统计 Nginx 和后端之间“正在通信”的连接数量。这个数字反映的是服务器“手头上还有几个活儿没结束”，比轮询更贴近真实压力。
- 适用于长连接场景（如 WebSocket、HTTP/2 流、文件上传、数据库连接池）
- 对响应时间差异大的服务效果明显（比如既有毫秒级接口，也有几秒的报表导出）
- 在后端存在性能异构时（例如混用新旧机型），能自然倾向处理能力更强的节点
多个节点连接数相同时怎么选
如果两个或多个 server 的活跃连接数完全一样，least_conn 会退回到加权轮询逻辑：按 weight 值比例分配，weight 越高，被选中的概率越大。这意味着 weight 仍起作用，不是完全失效。
它不自动剔除故障节点
least_conn 本身不具备健康检查能力。即使某台后端已宕机、无法响应，只要 TCP 连接还没超时断开，它的连接数可能仍显示为 0 或很低，Nginx 就可能继续往它转发请求。
- 必须额外配置 health_check 指令（七层）或 use_healthcheck（四层）
- 或配合 max_fails / fail_timeout 参数做被动探测
和 keepalive 配合才真正有效
如果后端应用不复用连接（比如每个 HTTP 请求都新建 TCP 连接），那么活跃连接数始终接近请求数，least_conn 就退化成近似轮询。要发挥效果，需确保：
- Nginx 启用 upstream keepalive（如 keepalive 100）
- 后端服务开启 HTTP Keep-Alive，并合理设置 timeout
- 客户端也支持连接复用（现代浏览器默认开启）
