nginx -t 会自动递归检查主配置中所有 include 的子配置文件语法，报错时明确指出具体文件名和行号；而 nginx -t 则用于展开并输出实际加载的完整配置树，含行号与构建信息。

nginx -t 命令会自动检查所有被 include 的文件，不需要单独测试每个子配置——只要主配置中写了 include 指令，-t 就会递归解析并校验其指向的所有文件语法是否合法。

include 文件的语法检查是自动连带的

执行 nginx -t 时，Nginx 不只检查 nginx.conf 本身，还会按实际加载顺序：

• 展开所有 include 指令（如 include /etc/nginx/conf.d/*.conf）
• 逐个读取匹配到的 .conf 文件
• 对每个被包含文件做完整语法解析（指令拼写、分号、括号匹配、上下文合法性等）
• 一旦任一文件出错，就立即报错，并明确标出具体文件名和行号

常见报错位置其实就在 include 文件里

例如错误提示：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

nginx: [emerg] unknown directive "proxy_set_header" in /etc/nginx/conf.d/api.conf:5

说明问题不在主配置，而在 /etc/nginx/conf.d/api.conf 第 5 行。这时应直接打开该文件检查，而不是反复看 nginx.conf。

• 用 grep -n "proxy_set_header" /etc/nginx/conf.d/api.conf 定位行
• 确认该指令是否写在允许的位置（比如不能在 http 块外、location 块内才有效）
• 检查前后是否有漏掉的分号或未闭合的大括号

确保 include 路径能被正确访问

如果报错是 "open() ... failed (2: No such file or directory)"，说明路径不存在或权限不足——这虽不是语法错误，但会导致 -t 失败：

• 复制报错中的完整路径，用 ls -l "路径" 验证文件是否存在
• 若路径含通配符（如 *.conf），运行 ls /etc/nginx/conf.d/*.conf 看是否真有匹配文件
• 检查目录是否有 x 权限（ls -ld /etc/nginx/conf.d/），文件是否有 r 权限
• Nginx 工作用户（如 www-data 或 nginx）必须对路径有 r-x 权限

想确认哪些文件被实际 include 进来了？用 -T 看展开结果

nginx -T 不是语法检查命令，但它能帮你验证 include 是否按预期生效：

• 它会输出 Nginx 实际加载的完整配置树，包括所有被展开的 include 文件内容
• 每段配置都标注原始文件名和行号，一眼就能看出某个 server 块来自哪个 conf 文件
• 如果某文件没出现在 -T 输出里，说明它没被 include 匹配到（可能是命名不合规、不在通配范围内、或路径写错）