least_conn算法通过将新请求分发给活跃连接数最少的后端节点，缓解长连接场景下的隐性过载；它统计含keepalive空闲连接的实时tcp连接数，需配合keepalive、max_conns和健康检查才能生效。
least_conn 算法本身不改变长连接的生命周期，但它能显著改善长连接场景下的请求分发质量——核心是让新连接避开“已卡住”的后端，避免连接数持续堆积。
为什么长连接会让轮询失灵
轮询只按顺序派请求，不感知后端真实负载。比如一台后端正在处理一个 20 秒的文件上传，连接一直开着；另两台刚返回毫秒级响应、连接已释放。轮询仍会继续往第一台派新请求，导致它的活跃连接越堆越多，而其他机器空闲。监控上看到连接数偏高、超时增多，但 CPU 却不高——这正是 least_conn 要解决的“隐性过载”。
least_conn 如何真实反映长连接压力
它统计的是当前所有已建立、尚未关闭的 TCP 连接，包括 keepalive 空闲连接。这意味着：
- 后端维持的长连接（如 WebSocket、HTTP/2 流、大文件上传）会被如实计入，算法能“看见”真实占用
- 如果你在 upstream 中配置了 keepalive 100，每个 worker 维持的 100 条空闲连接也会算进去——所以 keepalive 值不宜过大，否则会虚高账面连接数，干扰判断
- 若后端每请求都新建连接、不复用，活跃连接数始终接近 0，least_conn 就退化为随机分配，失去意义
必须配合的关键配置
单独写 least_conn 不够，需三者协同：
- 启用连接复用：upstream 中加 keepalive 32，location 中设 proxy_http_version 1.1 和 proxy_set_header Connection ''
- 限制单节点容量：用 max_conns=800 等参数软性限流，防止某台机器被长连接撑爆
- 及时剔除异常节点：靠 max_fails/fail_timeout 或主动健康检查，避免慢节点持续吸走新连接
对后端的实际影响
least_conn 不加快单个请求，但能降低整体 P95 延迟：
- 长耗时请求（如报表导出、AI 推理）不会集中打到同一台机器，而是被动态分散
- 后端连接数分布更均衡，减少因连接堆积引发的拒绝服务或超时重试
- 结合业务分离（例如长任务走专用 upstream + max_conns=50），可进一步隔离影响范围
