least_conn算法通过将新请求导向活跃连接数最少的后端来缓解隐性过载，但需确保连接数真实反映实时压力：启用长连接复用、强制http/1.1、后端支持keep-alive；叠加max_conns限流、健康检查与超时重试；按业务分离流量路径；并通过stub_status和连接数监控验证效果。
least_conn 算法本身不加快接口响应，但它能显著减少长耗时请求带来的隐性过载——关键在于把新请求导向“手头活儿最少”的后端，而不是机械轮询。
确保连接数真实反映实时压力
活跃连接数不准，least_conn 就失去意义。重点做两件事： - 在 upstream 块中启用长连接复用：`keepalive 32;`（每个 worker 最多缓存 32 条空闲连接） - 在 proxy_pass 所在的 location 中强制 HTTP/1.1 并清空 Connection 头： `proxy_http_version 1.1;` `proxy_set_header Connection '';` - 后端服务必须支持 keep-alive，例如 Tomcat 调大 `keepAliveTimeout`，FastAPI/Uvicorn 需设置 `--keep-alive 5`，Node.js 默认支持若后端每请求都新建 TCP 连接，活跃连接数始终趋近于 0，least_conn 会退化为随机分配。
防止慢节点拖垮整体调度
least_conn 不感知节点是否健康或是否卡死，必须叠加保护机制： - 设置硬性容量上限：为每个 server 显式声明 `max_conns=800;`（高性能机可设 2000，普通机建议 600–800） - 配置主动健康检查：如 OpenResty 的 `check interval=3 rise=2 fall=3 timeout=1 type=http`，及时剔除僵死节点 - 加兜底超时与重试：`proxy_read_timeout 120;`（略高于后端 P99 耗时），`proxy_next_upstream error timeout http_500;`按业务特性分离流量路径
避免长耗时请求污染短平快接口： - 单独定义专用 upstream 处理报表、AI 推理等长任务，启用 `least_conn` + `max_conns=50–100`（限制单节点并发） - 普通 API 请求走另一组 upstream，可用轮询或一致性哈希 - 若存在幂等查询，可考虑结合 `hash $arg_id` 或 `ip_hash` 做局部缓存亲和，但不与 least_conn 混用验证调度行为是否真正生效
改完配置后，不能只看 Nginx 启动是否成功，要观察实际行为： - 开启 `stub_status` 模块，在 server 块中添加： `location /nginx_status { stub_status; }` 访问后查看各后端 `Active connections` 是否趋于均衡，无明显单点偏高 - 结合后端 `ss -s | grep 'estab'` 或 `netstat -an | grep :8080 | grep ESTAB | wc -l`，确认连接数分布与 Nginx 统计一致 - 压测时比对 access log 时间戳分布——连接数低的节点应更早、更密集地收到新请求不复杂但容易忽略
