最少连接算法将新请求分配给当前活跃连接数最少的后端，仅统计nginx与后端间未关闭的tcp连接，不考虑cpu、响应时间等指标；适用于长连接及响应时间差异大场景，多节点连接数相同时按weight加权轮询，需配合keepalive和健康检查才有效。
最少连接算法在高负载场景下能更合理地分摊压力，尤其适合长连接、处理耗时差异大的后端服务。它不按固定顺序或权重分配请求，而是实时关注每台服务器当前活跃连接数，把新请求导向“最空闲”的节点。
为什么高负载时最少连接比轮询更合适
轮询假设所有服务器处理能力一致、每个请求耗时相近，但真实环境中常有数据库慢查询、文件上传、WebSocket长连接等场景，导致某些服务器连接堆积而其他服务器闲置。最少连接算法动态感知连接负载，天然适配非均匀响应时间与长连接业务。
- 避免“请求排队雪崩”：某台服务器因慢接口积压大量连接时，新请求不再继续打过去
- 对异构集群友好：即使后端服务器配置不同（如 4C8G 和 8C16G），也能靠实时连接数自动倾斜，无需人工调权
- 减少平均等待延迟：客户端请求更大概率落到低负载节点，响应更快
配置最少连接算法的关键写法
只需在 upstream 块中显式声明 least_conn，Nginx 即启用该策略。注意它不支持 weight 参数参与计算（权重仅影响初始连接倾向，不改变“最少连接”判定逻辑）：
upstream app_servers {
least_conn;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
若需结合健康检查，可叠加 max_fails 和 fail_timeout，确保故障节点被及时剔除，避免连接数统计失真：
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
配合连接管理提升效果
最少连接的效果依赖于 Nginx 能准确统计后端连接状态，因此需确保以下配置协同生效：
-
开启 keepalive 连接复用：在 upstream 中配置
keepalive 32;，减少 TCP 握手开销，让连接数统计更稳定 -
设置合理的超时参数：如
proxy_connect_timeout 3s;和proxy_read_timeout 30s;，防止僵死连接长期占用计数 - 避免 proxy_buffering off：关闭缓冲会延长连接生命周期，干扰连接数判断；如必须关闭，建议搭配短超时使用
监控与验证是否生效
可通过 Nginx 的 stub_status 模块或第三方模块（如 nginx-module-vts）查看各 upstream server 的 active connection 数。部署后观察一段时间，应能看到连接数分布明显趋近均衡，而非轮询式的“阶梯式增长”。也可用 ab 或 wrk 压测，对比相同 QPS 下各后端的连接数标准差——最少连接策略下该值通常比轮询低 40% 以上。
