Nginx配置中缩进无影响，关键要确保upstream块内least_conn位于首行、大括号和分号匹配正确，并通过nginx -t和error.log中的[emerg]错误精确定位语法问题。
缩进对 Nginx 配置完全无影响，真正要排查的是大括号 `{` `}` 和分号 `;` 的匹配问题。least_conn 本身不涉及缩进逻辑，但若其所在的 upstream 块因括号缺失或错位而解析失败，Nginx 就根本不会加载该配置，更谈不上调度行为。
看 error.log 中的 [emerg] 错误行
Nginx 遇到括号或语法错误时，一定会在错误日志中记录一条 [emerg] 级别日志，并附带具体文件路径和行号。这不是警告，是致命错误，会导致 reload 失败或服务无法启动。
- 典型提示如：
2026/09/16 21:20:15 [emerg] 1234#0: unexpected "}" in /etc/nginx/conf.d/ai.conf:52——说明第 52 行多了一个}，真实问题大概率出在它前面某处漏了{或分号 - 另一常见提示：
"upstream" directive is not allowed here——往往因为外层http {或stream {没闭合，导致 Nginx 已退出合法作用域 - 日志路径依部署方式而异：
/var/log/nginx/error.log（系统包）、/www/wwwlogs/nginx_error.log（宝塔）、/usr/local/var/log/nginx/error.log（macOS Homebrew）
用 nginx -t 快速验证并交叉定位
nginx -t 是唯一能即时反馈语法是否合法的官方命令，输出必须与 error.log 中的 [emerg] 记录一致。
- 运行
sudo nginx -t，若报错，会直接指出哪个文件哪一行有问题，例如：nginx: [emerg] "least_conn" directive is not allowed here in /etc/nginx/conf.d/app.conf:8 - 这个报错说明
least_conn;写错了位置：它只能出现在upstream {块的第一行，不能放在http、server或location块里 - 注意：
nginx -t不检查include的子文件是否存在，但会检查其语法；[emerg] 日志里报的路径，常是某个被 include 进来的站点配置文件，而非主nginx.conf
重点检查 least_conn 所在 upstream 的结构完整性
least_conn 生效的前提是 upstream 块本身能被正确解析。以下是最容易出错的三类写法：
-
upstream ai_cluster {后直接跟least_conn;，而不是先写其他指令；若漏掉开头的{或结尾的}，整个块就失效 -
least_conn;后的server行结尾必须有分号，例如：server 10.0.1.10:8080 max_conns=800;；缺分号会导致下一行被误读为同一指令的一部分 - 禁止在同一个 upstream 块中混用互斥策略，比如同时写
least_conn;和ip_hash;，Nginx 会直接拒绝加载
