least_conn通过动态选择活跃连接数最少的后端实现负载均衡，有效应对处理时长不一的请求；需配置keepalive、HTTP/1.1、后端长连接支持，并叠加max_conns、健康检查、超时重试及请求路径分离等机制保障效果。
least_conn 能解决后端处理时间长短不一的问题，核心在于它不按顺序或固定规则分发请求，而是每次把新请求交给“当前手上活儿最少”的后端——也就是活跃连接数最低的节点。这样，正在处理长耗时请求（如报表导出、AI推理、大文件上传）的节点，连接数会快速上升，新请求就会自动避开它，转向空闲或轻载节点。
连接数真实反映实时压力
如果连接数不准，least_conn 就失效。关键配置包括：
- 在 upstream 中启用连接复用：
keepalive 32;（每个 worker 最多缓存 32 条空闲连接） - 在 proxy_pass 所在 location 中强制 HTTP/1.1 并清除 Connection 头：
proxy_http_version 1.1;proxy_set_header Connection ''; - 后端必须支持 keep-alive：Tomcat 调大
keepAliveTimeout，FastAPI/Uvicorn 加--keep-alive 5，Node.js 默认支持
若后端每请求都新建 TCP 连接，活跃连接数始终接近 0，least_conn 会退化为随机分配。
防止慢节点拖垮调度效果
least_conn 不识别节点是否卡死或假活，需叠加保护机制：
- 为每个 server 设置
max_conns=800;（高性能机可设 2000，普通机建议 600–800），超限即跳过 - 配置主动健康检查：如
check interval=3 rise=2 fall=3 timeout=1 type=http，及时剔除僵死节点 - 设置合理超时与重试：
proxy_read_timeout 120;（略高于后端 P99 耗时），proxy_next_upstream error timeout http_500;
按业务分离长/短请求路径
避免长耗时请求污染短平快接口：
- 单独定义专用 upstream 处理长任务（如报表、AI 推理），启用
least_conn+max_conns=50–100（严格限制单节点并发） - 普通 API 请求走另一组 upstream，可用轮询或一致性哈希
- 幂等查询可结合
hash $arg_id做局部亲和，但不与 least_conn 混用
验证调度是否真正生效
改完配置后要观察实际行为，不能只看 Nginx 是否启动成功：
- 开启
stub_status，访问/nginx_status查看各后端Active connections是否趋于均衡，无明显单点偏高 - 对比后端真实连接数：
ss -s | grep 'estab'或netstat -an | grep :8080 | grep ESTAB | wc -l - 压测时对比 tail latency（如 P95/P99 响应时间），确认长请求堆积现象是否缓解
不复杂但容易忽略
