least_conn必须置于upstream块首行且无参数，不可与ip_hash等混用；需配合keepalive、健康检查及max_conns才能生效，否则将静默降级为轮询。
直接检查配置语法和启动日志是最有效的排查方式。Nginx 对 least_conn 的位置、上下文和共存策略有硬性限制，写错就会报错或静默降级，不会“部分生效”。
看 nginx -t 是否通过
运行 nginx -t 是第一道关卡。常见报错及含义：
-
directive "least_conn" is not allowed here：说明least_conn;没放在upstream {块的第一行，可能嵌在server、location或http块顶层； -
conflicting parameter "least_conn" in upstream：同一upstream块里混用了ip_hash、hash、least_time等互斥指令； - 无报错但实际没生效：检查是否误写成
least_conn on;或加了参数如least_conn timeout=30;—— 它不接受任何参数，只允许光秃秃的least_conn;。
查 error.log 中的加载行为
即使 nginx -t 通过，也要翻 error.log（默认在 /var/log/nginx/error.log）。关键线索包括：
- 出现
upstream "xxx" has no servers：说明least_conn后面没跟有效的server行，或者所有server因max_fails被标记为down且未恢复； - 没有
least_conn相关提示，但压测时连接分布完全均匀或固定打某台：大概率是least_conn被忽略，退回到默认轮询——回头再确认它是否真在upstream块首行； - 反复出现
connect() failed (111: Connection refused)却没触发摘除：说明max_fails/fail_timeout没配在server行后，被动健康检查未启用。
验证 upstream 是否真按 least\_conn 工作
语法没错 ≠ 效果到位。需交叉验证连接分布是否符合预期：
- 开启
stub_status，访问/nginx_status，观察各server的Active connections是否随请求流入动态变化、彼此差距明显； - 在
log_format中加入$upstream_addr和$upstream_connect_time，用awk统计不同后端的连接建立频次与耗时，确认低连接数节点是否确实承接了更多新请求； - 在后端机器上执行
ss -tan | grep :port | grep ESTAB | wc -l，对比 Nginx 统计值。若 Nginx 显示某节点Active: 5，而真实 ESTABLISHED 连接有 80 条，说明keepalive未生效或后端未复用连接，least_conn失去判断依据。
崩溃场景重点盯这些配置组合
真正导致 Nginx worker 崩溃（core dump）的情况极少由 least_conn 单独引发，但以下组合高危：
-
upstream内启用了health_check（非官方模块），但未打对应 patch 或版本不匹配； - 混用第三方模块（如 Lua）与自定义
upstream指令，尤其在init_worker_by_lua*中操作 upstream 变量； -
keepalive值设得极大（如keepalive 1000），又搭配大量后端server，导致连接池内存超限——错误日志会出现malloc() failed或too many open files。
