least_conn更适合长耗时请求，因其按实时活跃连接数分配请求，避免轮询或IP hash导致的单点过载；需Nginx 1.3.1+，配合max_conns、keepalive及合理timeout设置方可发挥最佳效果。
当后端服务存在明显长耗时请求（如文件上传、报表导出、AI推理等）时，Nginx 默认的轮询（round-robin）或 IP hash 调度容易导致连接堆积、响应延迟升高甚至超时。least_conn 算法能更合理地将新请求分发给当前活跃连接数最少的上游服务器，特别适合长连接、慢响应场景，是优化此类负载分配的关键手段。
为什么 least_conn 更适合长耗时请求？
轮询算法不关心后端实际负载，只按顺序分发，可能导致某台机器持续处理大文件上传，连接数飙升而其他节点空闲；IP hash 则完全绑定客户端，无法动态均衡。而 least_conn 实时比较每个 upstream server 的当前活跃连接数（即已建立但尚未关闭的连接），优先把新请求交给最“轻闲”的节点——这直接缓解了单点过载，提升了整体吞吐与稳定性。
启用 least_conn 的基础配置
在 Nginx 配置的 upstream 块中添加 least_conn 指令即可启用：
- 确保使用的是 Nginx 1.3.1+（该算法自该版本起正式支持）
- 配置示例如下：
upstream backend {
least_conn;
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.12:8080 max_fails=3 fail_timeout=30s;
}
注意：least_conn 不与 weight 直接兼容（权重仅在轮询中生效），但可通过搭配 max_conns 实现软限制：例如为性能更强的节点设置 max_conns=200，普通节点设为 max_conns=100，让 least_conn 在各自上限内择优选择。
配合 keepalive 与 timeout 提升效果
单独用 least_conn 不够，还需调整连接生命周期参数，避免“假空闲”：
- 在
upstream中启用长连接复用：keepalive 32;（保持 32 个空闲连接供后续请求复用） - 设置合理的超时，防止慢请求长期占位：
proxy_read_timeout 300;（匹配后端最长预期处理时间） - 避免客户端短连接频繁重建：在
server块中加keepalive_timeout 65;
这样既能减少建连开销，又能让 least_conn 统计到真实活跃连接压力，而非被大量刚建立就关闭的瞬时连接干扰。
验证与调优建议
上线后需确认算法是否生效并持续观察分布合理性：
- 通过
nginx -T | grep least_conn检查配置是否加载成功 - 访问
/nginx_status（需启用 stub_status 模块）查看各 upstream server 的Active connections实时值 - 模拟长耗时请求（如用 curl 发起 200 秒 sleep 接口），观察新请求是否倾向落到活跃连接更少的节点
- 若发现某节点始终连接数偏低，检查其健康检查状态、网络延迟或是否存在未暴露的资源瓶颈（如磁盘 I/O、线程池满）
least_conn 不是万能解药，它依赖准确的连接数统计。确保后端正确关闭连接（或使用 HTTP/1.1 + Connection: close 明确标识），避免因连接泄漏导致调度失真。
