遇到 unexpected "}" 或 unexpected end of file 报错，大概率是大括号不匹配——不是多了一个 }，就是少了一个 }。排查路径明确：先看 nginx -t 报错行号，往前追溯最近的 server {、location { 等块是否闭合；再用 grep 统计 { 和 } 数量比对；最后用分段注释法缩小范围，并检查 include 文件及指令层级合法性。
遇到 unexpected "}" 或 unexpected end of file 报错，大概率是大括号不匹配——不是多了一个 }，就是少了一个 }。这类错误在嵌套多、文件长的配置里特别难肉眼发现，但排查有明确路径。
看报错行号，先定位可疑块
nginx -t 的提示通常会带具体文件和行号，比如：
nginx: [emerg] unexpected "}" in /www/server/panel/vhost/nginx/example.com.conf:47
这说明第 47 行的 } 没有对应开头的 {。注意：出错位置不一定是错误根源，很可能是前面某个 { 漏了闭合，导致后续所有 } 都被当成“意外”。所以要从报错行往前查，重点看从最近的 server {、location {、if {、upstream { 等开始的块是否完整。
用命令统计括号数量快速判断
进入配置文件所在目录后，执行两行命令比对：
-
grep -n "{" your.conf | wc -l→ 统计所有 { 的个数 -
grep -n "}" your.conf | wc -l→ 统计所有 } 的个数
如果两个数字不相等，就确认存在不匹配。差值为 +1 表示少一个 }，差值为 -1 表示多一个 }。可进一步用 grep -n "{" your.conf 和 grep -n "}" your.conf 分别列出所有位置，人工逐对核对（尤其注意注释里的 { 或 }，它们不算语法括号）。
分段注释法缩小范围
当文件较长或 include 多时，直接看容易漏。稳妥做法是：
- 把整个 http { } 块内除最外层之外的所有子块（如 server、upstream、map）用 # 临时注释掉
- 运行 nginx -t，如果通过，说明问题在被注释的部分；如果仍报错，说明问题在 http 块顶层或主结构
- 逐步放开注释（每次只解一个 server 或一个 upstream），配合 -t 测试，直到复现错误
这个方法能绕过“报错位置飘忽”的干扰，尤其适合宝塔更新后主配置被覆盖、include 逻辑混乱的情况。
留意特殊上下文中的非法块
Nginx 对指令所处层级非常严格。常见陷阱包括：
- 在 http { } 块顶层直接写 location / {...} —— 这是非法的，必须包在 server { } 内
- 在 server { } 外写了 if (...) {...} 或 map $arg_x $y {...}，而没放在合适上下文（如 http 或 server）
- include 引入的文件本身有未闭合块，导致主文件的 } 被提前消耗
检查时不要只盯当前文件，顺藤摸瓜查看所有被 include 的路径，用同样方法逐个验证。
