least_conn适用于响应时间波动大、长连接多或后端性能不均的场景；它基于活跃连接数调度，不支持权重，需配合健康检查使用，短连接下效果有限。
在高并发、动态请求频繁的场景中，Nginx 的 least_conn 负载均衡策略比默认的轮询（round_robin）更合理——它把新请求发给当前活跃连接数最少的上游服务器，能更公平地分摊瞬时压力，尤其适合响应时间差异大、长连接多或后端处理耗时不均的情况。
什么时候该用 least_conn？
它不是万能替代方案，适用场景有明确特征：
- 后端服务响应时间波动大（比如有的请求查缓存快，有的要走数据库慢查询）
- 存在长连接或流式响应（如 SSE、WebSocket 代理、文件下载），连接生命周期长且不均等
- 后端节点性能不完全一致（例如混合部署了不同规格的机器）
- 轮询模式下已观察到个别节点 CPU 或连接数持续偏高
基础配置写法与关键细节
在 upstream 块中直接声明即可，无需额外参数：
upstream backend {
least_conn;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}注意三点：
- 它只统计当前 Nginx 与后端之间的活跃连接数（即已建立、未关闭的 TCP 连接），不感知后端内部线程或请求队列
- 不支持权重（
weight）和least_conn混用；若需加权，得改用商业版的least_time或自行结合健康检查做逻辑分流 - 对短连接（典型 HTTP/1.1 短平快请求）效果有限——因为连接建立/关闭太快，统计滞后可能削弱优势
搭配健康检查提升实效性
least_conn 本身不剔除故障节点，必须配合主动健康检查，避免流量打到失联或过载的后端：
upstream backend {
least_conn;
# 主动探测：每 3 秒发一次 HEAD 请求，失败 3 次标记为 down
check interval=3 rise=2 fall=3 timeout=1;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}如果使用开源版 Nginx，可借助 nginx_upstream_check_module 编译模块；OpenResty 用户则原生支持 check 指令。
对比其他策略的真实取舍
别盲目替换，默认轮询在多数 REST API 场景依然够用。简单对比：
- 轮询（round_robin）：简单高效，适合后端响应时间稳定、无长连接的微服务
- ip_hash / hash $request_uri：解决会话粘滞或缓存局部性，但易导致负载倾斜
- least_conn：更适合连接密集型或响应离散型业务，但监控需关注各节点连接数分布是否真正趋近均衡
- 第三方插件（如 nginx-plus 的 least_time）：基于响应时间决策，更智能，但需付费
上线前建议用 ab 或 wrk 模拟真实请求分布，对比 stub_status 中各 upstream server 的 Active connections 指标变化。
