least_conn通过将新请求导向连接数最少的实例来均衡负载，需配合keepalive、健康检查、分路径调度及实时验证才能真正生效。
least_conn 不直接加快接口响应，但它能显著改善微服务架构中因请求堆积导致的响应不均问题——核心是把新请求导向“当前手头活儿最少”的服务实例，避免慢接口拖垮整个链路。
确保连接数真实反映处理压力
如果活跃连接数不准，least_conn 就会失效。关键在复用连接：
- upstream 中配置 keepalive 32（按并发量调整，常见值 16–64）
- location 块里强制 HTTP/1.1：proxy_http_version 1.1; 并清空 Connection 头：proxy_set_header Connection '';
- 后端必须开启 keep-alive：Spring Boot 调大
server.tomcat.connection-timeout，FastAPI 加--keep-alive 5，Node.js 默认支持但需确认反向代理未中断
否则每次请求新建 TCP 连接，连接数始终接近请求数，least_conn 退化为近似轮询。
防止慢节点或故障节点干扰调度
least_conn 本身不识别卡死、超时或宕机节点，必须叠加保护：
- 每个 server 设置 max_conns=600（普通实例）或 max_conns=2000（高性能实例），硬性隔离单点过载
- 启用主动健康检查：health_check interval=3 fails=2 passes=2 match=status_ok;，配合 match 块校验 HTTP 状态和关键响应头
- 兜底被动探测：proxy_next_upstream error timeout http_500 http_502; + max_fails=2 fail_timeout=15s
按业务特征分路径调度
长耗时接口（如报表导出、AI 推理）和短平快接口（如用户查询）混跑，会互相污染：
- 单独定义 upstream 处理长任务：least_conn; max_conns=50–100;，限制单实例并发上限
- 普通 API 请求走另一组 upstream，可用 round_robin 或 hash $arg_user_id（幂等查询场景）
- 避免将 ip_hash 或 hash 与 least_conn 混用，会导致连接数统计失真
验证是否真正生效
改完配置不能只看 Nginx 启动成功，要观察实际行为：
- 开启 stub_status，访问
/nginx_status查看各 backend 的 Active connections 是否趋于均衡 - 在后端机器执行 ss -tn | grep :8080 | grep ESTAB | wc -l，比对与 Nginx 统计是否一致
- 压测时关注 P95/P99 响应时间波动幅度，理想情况是各节点响应曲线重合度高、无明显单点毛刺
