least_conn未生效最常见原因是语法错误或位置错误——拼写错误（如lest_conn）、符号错误（如least-conn）、位置错误（不在upstream块内）均被Nginx静默忽略而回退至round-robin；同时需排除ip_hash等冲突指令、验证配置真实加载及运行时连接分布。
least_conn 配置未生效，最常见原因不是逻辑错，而是语法写错了——Nginx 遇到不认识的指令会静默忽略，然后自动回退到默认的 round-robin（轮询），表面看“还在工作”，实际已失去最小连接数调度能力。
检查 least_conn 拼写是否正确
Nginx 对指令名严格区分大小写和字符。以下写法都会导致失效：
- lest_conn（少了一个 e）
- least_con（漏掉 n）
- least-conn（用了短横线，应为下划线）
- least_conn; 写在了 upstream 外部（如放在 http 或 server 块里）
只要拼错或位置错，Nginx 启动时不会报错，error_log 里也完全不提示，只会跳过该行，按默认策略走。
确认 upstream 块中没有其他冲突指令
least_conn 和某些指令不能共存，否则会被覆盖或降级：
- 同一 upstream 中同时出现 ip_hash、hash $arg_xxx 或 random —— 这些会直接覆盖 least_conn，优先执行自身逻辑
- 配置了 weight 但没配 least_conn（权重只对加权轮询生效，对 least_conn 仅作备用：当多个后端连接数相同时才启用加权轮询）
- 误把 least_conn 当成 location 级指令，在 proxy_pass 前单独写了一行（它只能出现在 upstream 块内）
验证配置是否真正加载成功
别只信配置文件内容，要确认 Nginx 实际运行时读取的是哪个 upstream 块：
- 用 nginx -t 检查语法：它只校验格式，不校验指令语义是否有效
- 执行 nginx -T | grep -A5 -B5 "upstream.*backend"（替换 backend 为你的 upstream 名），确认输出中确实包含
least_conn;且无拼写变形 - 重启后查看 nginx -V 2>&1 | grep -o with-http-upstream-，确保编译时启用了 upstream 模块（几乎默认都有，但自定义编译可能裁剪）
观察日志与行为反推是否生效
如果以上都对，但分发仍明显轮转而非避让高连接节点，就需行为验证：
- 压测时用 ss -tn state established '( dport = :8080 )' | wc -l 在每台后端上实时统计连接数，再对比请求日志中的 $upstream_addr 分布
- 若连接数差异大（如 A 有 80 个、B 有 12 个），但新请求仍持续打向 A，说明 least_conn 没起作用
- 临时注释掉所有 health_check / max_fails 配置，排除健康状态干扰；再试一次，看是否回归预期行为
