least conn算法通过将新请求优先分发给当前活跃tcp连接数最少的后端，从源头避免连接堆积；需配置keepalive、http/1.1长连接、健康检查与max_conns，并通过stub_status和压测验证调度效果。
Least Conn 算法不是靠“加快响应”来缓解压力，而是靠“选对人”——把新请求交给当前手上活儿最少的后端，从源头避免连接堆积。它不看 CPU、不比耗时，只盯一个数：Nginx 与该后端之间尚未关闭的 TCP 连接数。这个数字越真实，调度就越准。
让连接数真正反映实时压力
如果连接数始终接近 0 或长期失真，least_conn 就退化为随机分配。关键动作有三：
- 在 upstream 块中启用连接复用：keepalive 32;（每个 worker 缓存最多 32 条空闲连接）
- 在 proxy_pass 所在 location 中强制协议并清理头：proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 确保后端支持 keep-alive：Tomcat 调大 keepAliveTimeout，FastAPI/Uvicorn 启用 --keep-alive 5，Node.js 默认可用
若后端每次请求都新建连接，活跃连接数就无法体现真实负载，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;
按业务特性分离流量路径
长耗时请求（如报表导出、AI 推理）会拉高连接数，污染短平快接口。应物理或逻辑隔离：
- 单独定义专用 upstream 处理长任务，启用 least_conn + max_conns=50–100
- 普通 API 请求走另一组 upstream，可用轮询或一致性哈希
- 幂等查询可结合 hash $arg_id 实现局部亲和，但不与 least_conn 混用
验证调度是否真正生效
改完配置不能只看 Nginx 是否启动成功，要观察实际行为：
- 开启 stub_status 模块，在 server 块中加：location /nginx_status { stub_status; }，访问后查看各后端 Active connections 是否趋于均衡
- 用 ss -s | grep 'estab' 或 netstat -an | grep :端口 | grep ESTAB | wc -l 对比后端实际连接数，确认与 Nginx 统计一致
- 压测时分析 access log 时间戳分布——连接数低的节点应更早、更密集地承接请求
