least_conn是Nginx基于实时活跃TCP连接数调度的负载均衡算法，仅将新请求发给连接数最少的后端，适用于AI推理等长耗时高算力接口；必须置于upstream首行，禁用weight改用max_conns，配合keepalive、健康检查及超时参数确保连接数真实反映负载。
least_conn 不是“优化耗时”的算法，它只看连接数——哪个后端当前连着的请求最少，就把新请求发给它。对长耗时、高算力接口（比如 AI 推理、大模型打分、复杂报表生成），这个逻辑反而特别有效：请求一进来就卡住几秒甚至几十秒，连接长期不释放，轮询会继续往它身上派活，而 least_conn 自动绕开，把新请求导给真正空闲的节点。
必须写对位置和基础结构
least_conn 只能出现在 upstream 块的第一行，不能放错地方：
- 正确写法：upstream ai_cluster { least_conn; 后面紧跟 server 行
- 错误写法：放在 http、server 或 location 里，Nginx 直接报错 “directive is not allowed here”
- weight 参数会被静默忽略，别写 server ... weight=2；想体现节点能力差异，改用 max_conns=1200（高性能）或 max_conns=600（普通）
- 同一 upstream 中禁止混用 ip_hash、hash、least_time 等互斥策略
让连接数真实反映手头活儿多少
如果后端每次请求都新建再断开连接，活跃连接数永远接近 0，least_conn 就退化成随机分配。必须让连接“活”起来：
- 在 upstream 块中加 keepalive 32（每个 worker 最多缓存 32 条空闲长连接）
- 在 proxy_pass 所在的 location 中加：proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 后端服务要支持长连接：FastAPI 需调 Uvicorn 的 keep-alive timeout，PyTorch Serving 默认支持 HTTP/1.1 复用
- 对纯计算型接口（无流式响应），可设 keepalive_timeout 5s，避免空闲连接长期占位干扰统计
防“假空闲”和单点拖垮
长耗时接口容易出现长尾请求（比如某次推理卡在显存不足），导致节点连接数低但实际不可用，或连接数爆满却还在收新请求：
- 必须配健康检查：max_fails=2 fail_timeout=10s，快速摘除异常节点
- 为每个 server 设置 max_conns=800（举例），一旦达到即剔出调度池，防止慢请求锁死整条连接队列
- 在 location 中加 proxy_read_timeout 120（略高于后端 P99 处理时间），避免超长等待阻塞连接复用
验证是否真正在按压力调度
别只看配置有没有报错，重点看行为是否符合预期：
- 开启 stub_status，在 server 块中加 location /nginx_status { stub_status; }，访问后查看各 server 的 active 连接数是否随压测趋于均衡
- 采集 $upstream_connect_time 和 $upstream_header_time，识别“连接建立快但业务处理慢”的异常节点
- 绘制 active connections vs response time 散点图，定位“连接数低但延迟高”的离群点（常见于内存泄漏、本地缓存失效或磁盘 I/O 阻塞）
