least_conn是Nginx基于实时活跃连接数分配请求的负载均衡策略，适用于长连接、响应时间差异大或后端性能不均场景，需在upstream块首行配置，配合keepalive、max_conns及健康检查使用。
least_conn 是 API 网关层应对长耗时、高并发、性能不均后端服务最实用的负载均衡策略之一。它不看响应时间，也不依赖权重，只盯住每个后端当前“还连着多少请求”，天然适合 AI 推理、模型打分、报表生成等卡顿几秒甚至几十秒的接口。
必须放在 upstream 块首行，且独立定义网关专用 upstream
API 网关要精准控制不同业务路径的调度逻辑，不能复用全局 upstream。为 /api/ai、/api/report 等关键路径单独建 upstream，并把 least_conn 放在第一行：
- 正确写法：
upstream ai_backend {
least_conn;
server 10.0.2.10:8000 max_conns=1600;
server 10.0.2.11:8000 max_conns=800;
} - 错误写法：把 least_conn 写进 location 或 server 块；或和 ip_hash 混用；或漏掉大括号直接写在 http 块顶层
- 每个业务路径配一个 upstream，例如 report_backend、search_backend，互不影响
配合 keepalive 和 HTTP/1.1 长连接，让连接数真实反映压力
如果每次请求都新建 TCP 连接，活跃连接数永远≈1，least_conn 就退化成随机分配。网关层必须启用连接复用：
- 在 upstream 块中加 keepalive 32（每 worker 最多缓存 32 条空闲连接）
- 在 proxy_pass 所在的 location 中加两行：
proxy_http_version 1.1;
proxy_set_header Connection ''; - 确认后端支持长连接：FastAPI/Uvicorn 要设 --keep-alive 5；Spring Boot 默认开启；Node.js 无需额外配置
用 max_conns 替代 weight，体现节点真实承载力
weight 在 least_conn 下被忽略，但硬件差异必须表达。max_conns 是唯一推荐方式：
- GPU 节点设 max_conns=2000（显存足、算力强）
- CPU 节点设 max_conns=600（内存小、并发低）
- 一旦某节点活跃连接 ≥ max_conns，Nginx 自动跳过，不参与本轮 least_conn 比较
- 避免强节点长期满载、弱节点因连接数略少被持续压垮
叠加健康检查与超时控制，防“假空闲”拖垮整组
连接数为 0 不代表可用——可能是进程僵死、显存 OOM 卡住、或网络中间件拦截。网关必须主动防御：
- 每个 server 行加健康探测参数：
server 10.0.2.10:8000 max_conns=1600 max_fails=2 fail_timeout=10s; - 在 location 中设合理超时：
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 120s;（略高于后端 P99 耗时） - 开启 stub_status，访问 /nginx_status 查看各 server 的 active 连接数是否随压测动态均衡
