least_conn是基于实时活跃连接数的负载均衡策略，需在upstream块首行配置、启用keepalive、结合max_conns和健康检查协同调优，不可与ip_hash等混用。
least_conn 不是“挑空闲机器”，而是让新请求绕开正在处理慢任务的节点——它靠的是实时活跃连接数，不是响应时间或权重。要让它真正起作用，必须和 upstream 模块协同调优，否则容易变成伪随机分配。
确保 least_conn 位置和语法正确
least_conn 必须作为 upstream 块内的第一条指令出现，不能放在 http 或 server 块顶层，也不能和其他调度策略混用：
- ✅ 正确写法：upstream backend { least_conn; server 10.0.1.10:8080; }
- ❌ 错误写法：把 least_conn; 放在 upstream 外、或和 ip_hash 写在同一块里，Nginx 会直接报错 “directive is not allowed here”
- ⚠️ weight 参数会被 least_conn 忽略，但 max_fails / fail_timeout 等健康检查参数仍有效，可照常使用
必须启用 keepalive 连接复用
如果每次请求都新建 TCP 连接，活跃连接数瞬间归零，least_conn 就失去意义。关键配置有三处：
- 在 upstream 块中加 keepalive 32;（建议 16–64，太小会导致空闲连接不足）
- 在 proxy_pass 所在 location 中启用 HTTP/1.1：proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 后端服务自身要支持长连接，例如 Tomcat 设置 keepAliveTimeout，Node.js 默认支持，FastAPI 需加 --keep-alive 5
用 max_conns 控制单节点真实容量
性能强的机器不该和普通机器“比连接数”，而应允许它承载更多连接。max_conns 是最贴近实际的软性限流手段：
- 高性能节点可设 server 10.0.1.20:8080 max_conns=2000;
- 普通节点设 server 10.0.1.21:8080 max_conns=800;
- 一旦某节点达到 max_conns，least_conn 会自动跳过它，相当于“带硬上限的动态调度”
叠加健康检查防止失效转发
least_conn 只看连接数，不判断后端是否卡死。一台机器 TCP 连接没断但应用已僵住，它仍会持续分发请求：
- 被动检查：在 location 中加 proxy_next_upstream error timeout http_500 http_502;
- 每个 server 行后加 max_fails=2 fail_timeout=15s;
- 有条件就上主动健康检查（如 OpenResty 的 check 指令），每 3 秒探测 HTTP 状态码
按业务分离 upstream 提升精准度
长耗时请求（如报表导出、AI 推理）和短平快接口混在一起，least_conn 很难兼顾：
- 为长任务单独建一个 upstream，启用 least_conn + max_conns=50–100，避免单节点并发过高
- 普通 API 请求走另一组 upstream，可用轮询或 hash，避免干扰
- 不要把 least_conn 和 ip_hash/hash 混用在同一 upstream 块中
