least_conn配置错误最直接表现为Nginx启动失败、502频发或负载不按连接数分发；需检查其是否位于upstream块首行、未与ip_hash等策略混用，并通过access_log和压测验证实际生效。
least_conn 配置写错，最直接的表现是 Nginx 启动失败、502 错误频发，或负载完全不按连接数分发——看起来像在轮询甚至随机。排查核心就三点：语法位置是否合法、上下文是否正确、行为是否可验证。
检查 least_conn 是否放在 upstream 块第一行
这是硬性规则，不是建议：
- 必须紧接在
upstream 名称 {后面，且是该块中第一条有效指令 - 写成这样会报错：
upstream backend { server 10.0.1.10:8080; least_conn; } - 写成这样也会报错：
http { least_conn; upstream backend { ... } }（不在 upstream 内） - 运行
nginx -t，若提示directive "least_conn" is not allowed here，基本就是位置错了
确认没有和其他负载策略混用
least_conn 和部分策略互斥，共存即配置加载失败：
- 不能和
ip_hash、hash $arg_id、least_time出现在同一个 upstream 块里 - 即使注释掉其他策略，也要检查是否有隐藏的 include 文件悄悄引入了冲突指令
-
nginx -t报错含conflicting parameter或is duplicate，大概率是策略打架
验证 least_conn 是否真正在生效
不看日志、不测行为，光看配置无法确认它起作用：
- 打开 access log，添加
$upstream_addr和$upstream_connect_time字段，压测时观察不同节点的连接分布是否随实时负载动态偏移 - 手动让某台后端持续处理长请求（如 sleep 10s 接口），再并发发起新请求，看新请求是否明显避开该节点
- 若所有节点连接数长期接近且无波动，或始终只打固定一两台，说明 least_conn 未生效，可能已降级为默认轮询
- 查 error.log 是否有
no live upstreams—— 这往往意味着健康检查把所有节点都标为失效，least_conn 根本没机会选
