least_conn策略将新请求分配给当前连接数最少的后端，依据实时活跃连接数而非历史流量或权重，适合长耗时、响应差异大的场景，能避免过载与雪崩。
最少连接策略（least_conn）在 Nginx 中不是“平均分配请求”，而是“把新请求交给此刻连接数最少的后端”。它不看历史流量、不按权重轮转，只盯住每个上游服务器当前活跃连接数——这个实时指标更能反映真实负载压力，尤其适合长耗时、响应时间差异大的业务场景。
为什么 least_conn 更适合高并发下的负载平稳
当多个后端处理能力相近但请求耗时波动大（比如有的接口要查数据库+调第三方，有的只是返回静态 JSON），轮询容易让某台机器堆积大量未完成连接。least_conn 会持续识别并避开已满负荷的节点，天然避免“雪崩式过载”。它不是追求理论上的请求数均分，而是守住每台机器的并发连接水位线。
- 对慢请求友好：一个耗时 5 秒的请求占着连接，least_conn 会自动绕开这台机器，直到它释放连接
- 无需预估权重：不用人为给服务器打分或设 weight，靠实时连接数说话
- 自动适配动态扩容：新增一台后端，只要健康检查通过，立刻参与连接数竞争，平滑接入
配置 least_conn 的关键细节
启用 least_conn 很简单，但真正起效依赖几个协同配置：
- 必须写在
upstream块里：least_conn;—— 这一行就启用了该策略 - keepalive 连接会计入统计：如果 upstream 里配了
keepalive 100，那些空闲保活连接也会算进“当前连接数”，可能影响调度精度；建议 keepalive 值设为合理上限（如 32 或 64），避免虚高 - 健康检查是前提：Nginx 默认用被动检测（max_fails + fail_timeout），建议搭配主动健康检查模块（如 nginx-plus 或开源的 nginx_upstream_check_module），确保不可用节点及时剔除，不然 least_conn 会把请求继续发给已卡死的机器
least_conn 和其他策略的配合使用
least_conn 不是万能解药，实际中常和别的机制组合：
- 与 IP 哈希共存？不行 —— 两者逻辑冲突，IP 哈希强制绑定，least_conn 动态选节点，只能二选一
- 可叠加权重：Nginx 支持
least_conn+weight，即优先选连接少的，连接数相同时再按权重分配，适合新老机器混搭 - 配合连接限制：在 server 或 location 级用
limit_conn控制单 IP 或 zone 的并发连接，防止个别客户端拖垮整条链路
监控与验证 least_conn 是否生效
光配对不等于跑对。上线后需确认三点：
- 查 Nginx 状态页（需编译时启用 http_stub_status_module）：看各 upstream server 的
Active connections是否始终接近、无明显长期偏高 - 用
nginx -T检查配置是否被正确加载，确认 upstream 块里确实有least_conn且无语法错误 - 模拟压测：用 ab 或 wrk 发起一批长连接请求，观察后端 access_log 中各机器的请求到达时间分布，应呈现“谁空闲谁接单”的趋势，而非固定轮转
