Nginx include通配符匹配错乱的关键是确认实际加载的文件、顺序及权限，而非是否报错；需用nginx -T查看真实加载路径，排除引号、空格、多参数等语法错误，并验证绝对路径与进程读取权限。
排查 include 路径通配符匹配错乱，关键不是“文件有没有被读到”，而是“哪些文件被读了、按什么顺序读、有没有被重复或遗漏”。Nginx 不会报错说“这个 conf 没加载”，它只会静默跳过不存在的路径或权限不足的文件——而这正是故障最隐蔽的地方。
确认 include 语句语法是否合规
常见写法错误直接导致通配符失效：
- 带多余引号：
include "/etc/nginx/conf.d/*.conf";→ 应去掉引号，写成include /etc/nginx/conf.d/*.conf; - 路径末尾多空格：
include /etc/nginx/conf.d/*.conf ;→ 分号前不能有空格，否则 Nginx 解析失败 - 通配符路径不存在或为空目录：Nginx 不报错也不警告，该
include行直接被忽略 - 用了多个参数：
include /a.conf /b.conf;→include只接受一个参数（单文件或通配符），多参数必报 invalid number of arguments
验证实际加载了哪些配置文件
Nginx 启动时会把所有成功加载的配置文件路径打印在 nginx -T 输出中（注意是大写 T）：
- 运行
nginx -T 2>&1 | grep -E "^\s*include|\.conf"，查看输出里是否出现你预期的 conf 文件路径 - 若某站点配置如
/www/server/panel/vhost/nginx/example.com.conf没出现在结果里，说明主配置中的include没覆盖到它 - 注意：
nginx -t只校验语法，不显示加载路径；nginx -T才会展开全部包含关系
检查文件系统权限与路径有效性
即使路径写对了，Nginx 工作进程（如 www-data 或 nginx 用户）没权限读取，也会静默跳过：
- 执行
ls -l /etc/nginx/conf.d/，确认目录和 *.conf 文件属主/属组可读（至少rw-r--r--） - 用 Nginx 进程用户测试读取：
sudo -u www-data cat /etc/nginx/conf.d/test.conf，看是否报 Permission denied - 通配符路径必须是绝对路径，相对路径（如
include conf.d/*.conf）只在当前配置文件所在目录下查找，极易出错
识别加载顺序与覆盖冲突
多个 include 行或嵌套 include 可能导致规则被后加载的配置覆盖：
- 同一个
server块内，若先后include两个文件，且都定义了location /api，后者的配置生效 - 宝塔等面板常在主配置末尾
include站点配置，但若你在http块顶部又写了include common/*.conf，里面含全局 rewrite，则可能干扰站点级规则 - 用
nginx -T输出按文本顺序观察 location 块实际位置，确认你的规则没被更靠后的同名块覆盖
