least_conn必须置于upstream块首行，不接受参数、不可与ip_hash等策略共存；需搭配max_fails/fail_timeout、max_conns、keepalive及HTTP/1.1长连接配置才能真实生效。
直接在 upstream 块开头写 least_conn;，这是唯一合法位置。它不接受参数，不能和 ip_hash、hash、least_time 等策略共存，也不支持 weight。
必须放对位置
该指令只能出现在 upstream 块的第一行，紧跟在 upstream 名称之后：
- ✅ 正确：
upstream api_backend {<br> least_conn;<br> server 192.168.1.10:8000;<br> server 192.168.1.11:8000;<br>} - ❌ 错误：放在
http、server或location块里 → 启动报错 “directive is not allowed here” - ❌ 错误：写在
server行后面 → 被忽略或校验失败 - ❌ 错误：与
ip_hash同时出现 → 配置无法通过
必须搭配的关键配置
least_conn 单独存在效果有限，需组合以下设置才能真实反映后端压力：
- 每个
server行加上max_fails=2 fail_timeout=15s：启用被动健康检查，避免调度到假空闲节点 - 为每个
server显式设置max_conns=800（数值按机器性能调整）：代替 weight 实现容量感知，连接数达上限即跳过 - 新上线节点建议加
slow_start=30s：防止冷启动时流量突增引发雪崩
必须启用长连接支持
Nginx 统计的是活跃 TCP 连接数。若后端用短连接，连接数瞬间归零，least_conn 就退化为随机分配：
- 在
upstream块中加：keepalive 32;（每个 worker 最多缓存 32 条空闲连接） - 在
location中加：proxy_http_version 1.1;和proxy_set_header Connection ''; - 后端服务需支持 keep-alive：如 FastAPI/Uvicorn 设置
--keep-alive 5，Tomcat 调大keepAliveTimeout
验证是否真正生效
别只看配置能否加载，重点观察运行时行为是否符合预期：
- 开启
stub_status模块，在server块中添加location /nginx_status { stub_status; }，访问后查看各后端 Active connections 是否随压测趋于均衡 - 用
curl -I或 Nginx access 日志确认请求确实落在连接数更少的节点上 - 监控响应时间 P95 和连接堆积趋势：若某节点连接数低但延迟飙升，说明健康检查滞后，需加强主动探测
