最少连接策略（least_conn）在Nginx中实时选择当前活跃连接数最少的后端服务器，专注连接数这一即时指标，适合高并发、长连接及处理时长差异大的场景，能动态避让满负荷节点、抑制热点、降低尾部延迟。
最少连接策略（least_conn）在 Nginx 中不是靠预估或统计历史负载，而是实时查看各后端服务器当前活跃连接数，把新请求发给此刻连接数最少的那台。它不关心响应快慢、CPU 占用或内存使用，只盯住“正在处理的连接数量”这个即时指标——这恰恰让它在高并发、长连接、处理时长差异大的场景下，比轮询更平滑、更抗压。
为什么最少连接更适合高并发下的负载平滑
轮询按顺序派发，容易造成“请求堆积在慢节点”。比如一台后端处理一个请求要 2 秒，另一台只要 200 毫秒，轮询仍会平均分配，结果慢节点连接越积越多。而最少连接策略能动态避开已满负荷的节点，天然抑制热点形成。
- 对长连接友好：WebSocket、HTTP/2 流、文件上传等场景中，单连接持续时间长，连接数比请求数更能反映真实压力
- 自动适配性能差异：无需人工设权重，新旧服务器混用时也能自发平衡
- 降低尾部延迟：避免把请求塞进已排队的节点，整体 P95/P99 延迟更稳定
配置要点与常见误区
最少连接策略启用简单，但效果依赖合理的基础配置。光写 least_conn 不够，还需注意几个关键点：
- upstream 块中必须显式声明：
least_conn;，否则默认是轮询 - 确保后端服务正确关闭空闲连接（如设置
keepalive_timeout），否则连接数长期不释放，策略会失效 - 配合
max_conns限制单台最大连接数，防止某台机器被突发流量打穿（例如：server 192.168.1.101 max_conns=1024;） - 不建议与
ip_hash或hash $request_uri同时启用，二者逻辑冲突
搭配健康检查提升稳定性
最少连接本身不判断后端是否存活。若某台服务器网络断开但连接未超时，Nginx 仍可能把它当作“连接数少”的可用节点继续转发，导致请求失败。因此务必开启主动健康检查：
- 使用
health_check指令（需 stream 或 http 模块支持）定期探测后端 HTTP 状态码 - 或结合
max_fails和fail_timeout，让 Nginx 在连续失败后临时剔除异常节点 - 推荐组合：
least_conn+max_fails=3 fail_timeout=30s+health_check interval=5s fails=2 passes=2
性能表现与适用边界
实测数据显示，在后端处理耗时不均的典型 Web API 场景下，least_conn 相比轮询可提升约 40% 的吞吐量，P99 延迟下降明显。但它也有局限：
- 不适合极短连接（如毫秒级静态资源请求），此时连接数变化太快，统计意义减弱
- 无法感知 CPU、磁盘 I/O 等系统级瓶颈，仅反映连接层负载
- 在连接数极低（如每秒几请求）时，和轮询差异几乎不可测
