最少连接策略（least_conn）通过实时比较各后端服务器当前活跃TCP连接数，选择数值最小者分发新请求；若相同则按配置顺序选首个，且自动剔除故障节点。
最少连接策略（least_conn）不是按请求顺序或预设权重平均分发，而是实时看哪个后端服务器当前活跃连接数最少，就把新连接交给它。核心逻辑是“谁空闲，谁接活”，特别适合后端处理时间不均、存在长连接或慢响应的场景。
最少连接策略怎么判断“最闲”的服务器
Nginx 会持续统计每个 upstream server 当前已建立但尚未关闭的 TCP 连接数（即活跃连接数），这个数值反映真实负载压力。每次有新请求到达时，Nginx 比较所有可用节点的该数值，选择最小的那个；如果多个节点数值相同，则按配置中 server 的声明顺序选取第一个。
- 只统计代理层可见的活跃连接（如 proxy_pass 建立的连接），不包含后端内部线程或数据库连接
- 不依赖响应时间、请求数或 CPU 使用率等外部指标，纯基于连接状态做决策
- 若某 server 处于 down 状态或健康检查失败，会被自动剔除，不参与 least_conn 计算
为什么它比轮询更适合压力不均的系统
轮询策略假设每个请求耗时相近，但现实中常有上传大文件、生成报表、WebSocket 长连等操作，导致某些节点连接堆积而其他节点空转。least_conn 能动态避开已满负荷的节点，避免雪崩式过载。
- 例如：Server A 正在处理 3 个耗时 10 秒的请求，Server B 只有 1 个 2 秒请求 —— 新请求会优先给 B
- 对 HTTP/1.1 Keep-Alive 或 gRPC 长连接服务效果更明显，因连接生命周期远长于单次请求
- 配合 upstream 的 keepalive 指令使用，可复用连接，进一步降低新建连接开销
配置时要注意的关键细节
least_conn 本身只需一行指令，但实际效果取决于配套设置是否合理：
- 必须启用健康检查（如 health_check 或 max_fails/fail_timeout），否则故障节点仍会被计入“连接数最少”候选
- 支持与 weight 结合：权重影响“连接数相同时的优先级”，不改变 least_conn 的基本比较逻辑
- 建议开启 stub_status 模块，通过
/nginx_status实时观察各 server 的 active connections，验证策略是否生效 - 避免在短连接高频场景下盲目启用——连接建立/断开频繁时，least_conn 优势不明显，轮询反而更稳定
它不能解决哪些问题
least_conn 是连接维度的均衡，不是万能负载调节器：
- 无法感知后端 CPU、内存、磁盘 IO 等资源瓶颈，仅反映网络连接压力
- 对突发流量无预测能力，只能被动响应已有连接状态
- 不处理请求内容特征（如图片压缩 vs JSON API），需结合业务层限流或路由规则补充
- 若所有后端都接近满连接，least_conn 只是“矮子里面拔将军”，不能替代扩容或性能优化
