least_conn是nginx原生支持的负载均衡算法，优先将新请求分发给当前活跃连接数最少的后端服务器，适用于长连接多、响应时间差异大或后端性能异构的场景，需配合keepalive、健康检查及max_conns等配置才能有效发挥负载均衡作用。
“最少连接”调度本身不是 Nginx 原生支持的负载均衡算法，Nginx 默认使用轮询（round-robin）和加权轮询，不直接提供“least_conn”之外的动态连接数感知型调度。但 upstream 模块确实支持 least_conn 策略，它是提升高并发下请求吞吐率的有效手段——尤其当后端节点处理能力不均或响应时间差异较大时。
least_conn 是什么？适用哪些场景？
least_conn 会让 Nginx 把新请求优先发给当前活跃连接数最少的后端服务器。相比轮询，它更适应“长尾响应”或“处理耗时波动大”的服务（如含数据库查询、文件解析、AI推理的接口），避免请求堆积在已繁忙的节点上。
- 适合：后端实例性能不一致（如混合部署旧/新机器）、接口响应时间离散度高、存在慢请求拖累整体吞吐的场景
- 不适合：所有后端响应极快且均匀（如纯静态资源）、连接生命周期极短（
如何正确配置 least_conn？关键不止一行指令
仅写 least_conn 不够，需配合连接复用、超时控制与健康检查，否则可能适得其反：
- 启用 keepalive 连接池：
keepalive 32;（推荐值 16–100），减少建连开销，让 least_conn 统计更稳定 - 设置合理的 keepalive_timeout（如
60s），避免空闲连接长期占用计数 - 搭配
max_fails=2 fail_timeout=30s，及时剔除异常节点，防止 least_conn 把请求持续导向故障实例 - 慎用
slow_start（尤其新上线节点），避免冷启动时因连接数少被过度倾斜分配
为什么吞吐率能提升？背后的逻辑是什么？
least_conn 的价值不在“绝对公平”，而在“动态负载收敛”：
- 当某台后端因 GC、锁竞争或磁盘延迟导致响应变慢，其活跃连接会快速堆积；least_conn 自动降低后续请求命中率，形成负反馈调节
- 避免了轮询下“请求照常打过去→排队等待→超时重试→雪崩放大”的恶性循环
- 实测表明，在后端 P95 响应时间差异 >3× 的场景中，启用 least_conn 可使整体 RPS 提升 15%–40%，错误率下降明显
必须同步优化的配套项
单独改调度策略效果有限，需整体协同：
-
调高 worker_connections 和系统 ulimit：确保 Nginx 自身不成为连接瓶颈（例如
worker_connections 8192+worker_rlimit_nofile 65535） - 缩短 client_header_timeout / client_body_timeout：快速拒绝畸形或慢速上传请求，释放连接计数
- 开启 proxy_http_version 1.1 和 Connection keep-alive：保障 upstream 与后端之间也复用连接，让 least_conn 统计真实有效
-
监控 active connections 分布：用
nginx -T | grep upstream+ Prometheus + nginx-vts-exporter 观察各 backend 的active值是否趋于均衡
