least_conn不生效通常因未正确加载或被覆盖：必须置于upstream块首行，不可与ip_hash等混用，且需被proxy_pass引用；需通过nginx -t验证语法、nginx -T确认配置加载、error_log或journalctl查[emerg]错误，并排除max_fails过严、连接复用缺失等干扰。
当配置了 least_conn 但热重载后不生效，问题通常不在策略本身，而在于它是否被真正加载、上下文是否合法、或是否被其他逻辑覆盖。排查要聚焦“Nginx 是否承认这个指令”和“它是否实际参与了请求分发”。
确认 least_conn 出现在正确的上下文
least_conn 只能用在 upstream 块内，且必须是该块的第一条指令（不能和 round_robin、ip_hash 等混用）。常见错误包括：
- 把它写在
server或location块里，Nginx 直接报[emerg] "least_conn" directive is not allowed here - 同一
upstream块中同时写了least_conn和ip_hash，后者会覆盖前者，Nginx 不报错但忽略least_conn -
upstream块没被任何proxy_pass引用，等于定义了却没用上
验证 upstream 配置是否被正确加载
热重载失败时，least_conn 往往根本没进内存。先做基础检查：
- 运行
nginx -t：如果提示语法错误或路径不可读，least_conn就不会生效；即使通过，也不代表上下文完全合规（比如ssl_certificate文件权限不对，-t可能不报，但reload会卡住） - 执行
nginx -T | grep -A5 "upstream backend"（把backend换成你实际的 upstream 名），确认输出里确实包含least_conn;，且没有被注释或拼写错误（如写成least_conn;后多了一个空格或中文分号） - 检查
error.log路径是否真实存在：打开nginx.conf找error_log指令，确认日志目录可写、SELinux 未拦截；否则[emerg]报错根本看不到，得查journalctl -u nginx -n 30
观察 worker 进程行为，确认 least_conn 是否起作用
配置加载成功 ≠ 策略生效。长连接可能让旧 worker 持续服务，新策略只对新连接生效：
- 用
ss -tnp | grep :80 | grep nginx查看当前 ESTABLISHED 连接归属的 worker PID - 执行
nginx -s reload后，再查一次，应看到旧 worker 标记为is shutting down，新 worker 启动 - 等旧连接自然断开（或主动 kill 掉老 worker），再发起新请求，用
curl -v http://your-domain并观察后端日志——多次请求应逐步落到连接数更少的节点上，而非轮询
排除隐性干扰项
有些配置会让 least_conn “看起来失效”：
-
max_fails和fail_timeout设置过严，导致某台后端被临时摘除，只剩一台可用，自然谈不上“最少连接” - 后端服务器响应极快（毫秒级），连接建立后立刻关闭，worker 统计的“当前连接数”几乎恒为 0，
least_conn退化为轮询 - 客户端使用 HTTP/1.0 或禁用 keepalive，每次请求都新建连接，无法体现连接数差异
