最少连接调度（least_conn）要求连接数真实反映后端负载，必须同时满足：upstream中声明least_conn、server配置max_fails和fail_timeout、启用proxy_next_upstream被动检查、upstream开启keepalive且后端支持长连接。
最少连接调度（least_conn）不是“挑个空闲节点凑合用”，而是让 Nginx 在请求到达瞬间，从所有健康后端里选出当前活跃连接数最少的那个——它真正起效的前提，是连接数能真实反映后端负载。
必须配齐的四个基础项
光写 least_conn 这一行配置，几乎没用。以下四点缺一不可：
- upstream 块中明确声明
least_conn，否则默认走轮询 - 每个
server行必须带max_fails=2 fail_timeout=15s，否则宕机节点仍持续收请求 - 启用被动健康检查：在 location 或 upstream 外层配置
proxy_next_upstream error timeout http_500 http_502 - upstream 内开启连接复用：
keepalive 32，同时后端服务需支持长连接（如 Tomcat 设置maxKeepAliveRequests）
连接数要“准”，才调度得对
活跃连接数不准，least_conn 就变成随机分发。常见干扰来源有两个：
- 后端维持大量空闲长连接却不释放，导致连接数虚高——可通过减小
keepalive值（如设为 16）或加proxy_http_version 1.1; proxy_set_header Connection '';让 Nginx 主动管理连接生命周期 - 短连接高频建连断连，连接刚建立就关闭，统计窗口内连接数跳变剧烈——此时建议搭配
weight参数，给性能更强的机器更高权重，避免小规格节点被频繁选中却撑不住
监控要看组合指标，不能只盯一个数
单看 $upstream_addr 日志只能知道落到哪台机器，无法判断调度是否合理：
- 用
stub_status或 Prometheus exporter 查各后端的active connections，若某台长期接近worker_connections上限，说明已到瓶颈，算法再准也无济于事 - 对比
$upstream_header_time和$upstream_response_time：前者稳定、后者飙升，问题在后端逻辑；两者同步升高，可能是 Nginx 自身连接池不足或网络延迟突增 - 加日志字段
$upstream_cache_status，排除因缓存失效引发的重复计算压力，尤其在模型推理类服务中很关键
适合场景与明显不适用的情况
least_conn 对以下情况提升显著：
- 请求处理时间差异大（比如 100ms 的普通接口混着 8 秒的 AI 推理）
- 存在长连接（WebSocket、SSE、文件上传等），连接生命周期远超请求处理时间
- 后端资源（CPU/内存）不均，但可通过
weight显式表达差异
但它不适合：
- 所有后端响应时间高度一致且极短（如毫秒级键值查询），此时轮询更稳定
- 后端本身无连接状态管理（例如无状态函数计算 FaaS），连接数失去参考意义
- 网络抖动频繁、超时阈值过松，导致健康检查失效，least_conn 会把请求持续打向不稳定节点
