least_conn在长连接场景下需精准配置才能真实反映后端压力：启用keepalive、限制max_conns、设置slow_start、主动健康检查，并按业务分离长/短连接路径。
直接用 least_conn 指令本身很简单，但想让它在长连接场景下真正起作用，关键不在“写不写”，而在“怎么配才让连接数真实反映后端压力”。否则它会变成随机分配，甚至把流量持续打向卡死的节点。
让活跃连接数统计准起来
least_conn 统计的是当前所有已建立、尚未关闭的 TCP 连接，包括 keepalive 空闲连接。如果这个数字失真，算法就失效：
- 在
upstream块中必须加keepalive 32;（建议 32–64，过高会虚高连接数，过低导致频繁建连） - 在
location中配proxy_http_version 1.1;和proxy_set_header Connection '';，强制复用连接 - 后端服务要支持 keep-alive：Spring Boot 设
server.tomcat.connection-timeout=5s，FastAPI/Uvicorn 加--keep-alive 5，Node.js 默认可支持 - 排查响应头是否含
Connection: close（常见于 WAF 拦截、调试开关或错误返回），这类连接无法复用，会拉低连接复用率
防止单点被长连接拖垮
长耗时请求（如报表导出、AI 推理、大文件上传）会让一台机器连接数持续堆积。仅靠 least_conn 不够，得加软性闸门：
- 每个
server行必须配max_conns=800;（普通节点），高性能节点可设 1500–2000；超过即剔出调度池，避免被长尾锁死 - 新扩容节点加
slow_start=30s;，连接权重从 0 线性上升，防止缓存未热、模型未加载就承接全量流量 -
keepalive_timeout设为 5–10 秒，避免空闲连接长期占位，拉高“账面连接数”造成误判
主动识别卡死节点，别等超时
least_conn 不感知后端是否线程阻塞、GC 卡顿或显存耗尽——只要 TCP 连通，它就认为可用。被动检查太迟钝，必须主动干预：
- 优先启用主动健康检查：
health_check interval=3 fails=2 passes=2 match=ok;（需 Nginx Plus 或编译ngx_http_upstream_check_module） - 若用开源版，至少强化被动机制：每个
server配max_fails=2 fail_timeout=10s，并确保proxy_next_upstream error timeout http_500 http_502; -
proxy_read_timeout设为略高于后端 P99 耗时（如 120 秒），配合重试，让卡住的请求及时失败并释放连接槽位
按业务分离长/短连接路径
长耗时请求和短平快接口混跑，会互相污染。least_conn 在专用路径上才能精准发力：
- 为报表、AI 推理等单独定义
upstream，启用least_conn+max_conns=50–100，严格限制单节点并发 - 普通 API 请求走另一组 upstream，可用轮询或一致性哈希，避免被长连接干扰
- 幂等查询类接口可结合
hash $arg_id做局部亲和，但不要和 least_conn 混用在同一 upstream 中
配置改完不是终点，要验证效果：开启 stub_status 查看各后端 Active connections 是否均衡；用 ss -s | grep 'estab' 对比后端真实连接数；压测时观察 P95 延迟是否下降、有无单点连接数持续偏高。不复杂但容易忽略。
