least_conn必须置于upstream块首行，不支持参数及与其他策略共存；需搭配max_fails/fail_timeout健康检查、max_conns容量限制和keepalive长连接支持才能真实生效。
直接在 upstream 块第一行写 least_conn;，这是唯一合法位置；它不接受参数，也不能和 ip_hash、hash 等其他调度策略共存。真正起效还需配套连接复用、健康检查和容量限制。
least_conn 的位置与语法要求
必须作为 upstream 块内的首条指令，紧跟在块名之后：
- ✅ 正确：
upstream api_cluster {
least_conn;
server 10.0.1.10:8000;
server 10.0.1.11:8000;
} - ❌ 错误：写在
http、server或location块里 → 启动报错 “directive is not allowed here”
❌ 写在server行后面 → 被忽略或校验失败
❌ 和ip_hash或hash $arg_id同时出现 → 配置无法加载
必须搭配的 server 属性
仅写 least_conn; 不足以稳定工作。每个 server 至少要配三项关键属性，否则连接数统计失真、节点故障无法及时剔除：
- max_fails=2 fail_timeout=15s：启用被动健康检查，连续失败 2 次后 15 秒内不再调度，避免请求发到“假空闲”节点
-
max_conns=1000（按实际调整）：替代
weight实现容量感知，连接数达上限即跳过，防止单节点过载 - slow_start=30s（新上线节点建议加）：冷启动时流量线性增加，避免瞬间压垮服务
示例：
server 10.0.1.10:8000 max_fails=2 fail_timeout=15s max_conns=2000 slow_start=30s;
必须启用的长连接支持
least_conn 统计的是 Nginx 到后端的活跃 TCP 连接数。如果后端总是短连接，连接秒建秒断，算法就退化为随机分配：
- 在
upstream块中加：keepalive 32;（每个 worker 最多缓存 32 条空闲连接） - 在
location中加：proxy_http_version 1.1;和proxy_set_header Connection ''; - 后端服务需支持 HTTP/1.1 keep-alive，例如：
• FastAPI/Uvicorn 开启--keep-alive
• Tomcat 设置maxKeepAliveRequests > 0
验证是否真实生效
不能只看配置能否 reload，重点观察运行时行为：
- 开启
stub_status模块，访问/nginx_status查看各后端的Active connections是否随压测趋于均衡 - 用
curl -I或 Nginx access 日志确认请求确实落在当前连接数更少的节点上 - 监控 P95 响应时间和连接堆积趋势——若某节点连接数低但延迟飙升，说明健康检查滞后，需补充主动探测（如
health_check指令）
