Virtual Host 配置没生效最常见原因是 include 未成功：路径不存在、权限不足或通配符未匹配，需用 nginx -T 验证实际加载结果，而非仅依赖 nginx -t。
Virtual Host 配置没生效，不一定是写错了，很可能是根本没被 Nginx 加载进来——include 未成功是最常被忽略的“隐形断链”。它不会报错，也不会提示文件不存在，只是安静地跳过你的配置。
确认 include 路径是否真实存在且可读
Nginx 不会主动告诉你路径错了，只会默默忽略。重点检查三件事：
- 路径是绝对路径还是相对路径？Nginx 的
include是相对于nginx.conf所在目录解析的（不是当前工作目录）；比如include extra/*.conf;表示在/etc/nginx/extra/下找（假设 nginx.conf 在/etc/nginx/） - 目标目录是否存在？用
ls -l /etc/nginx/conf.d/或你指定的路径，确认目录可访问、非空 - 文件权限是否允许 nginx 主进程用户（通常是
root或nginx）读取？尤其注意 SELinux 或 AppArmor 限制（RHEL/CentOS 上常见）
验证 include 是否实际展开
运行 nginx -T（大写 T），它会输出 Nginx 实际加载的完整配置（含所有 include 展开后的内容）：
- 搜索你的 server 块关键字，比如
server_name example.com，看它是否出现在输出里 - 如果完全找不到，说明 include 没生效；如果找到了，但位置不对（比如被其他 server 块覆盖），就进入匹配优先级排查
- 注意：
nginx -t只校验语法，-T才能看真实加载结果
检查通配符与文件名匹配规则
像 include conf.d/*.conf; 这类写法，依赖 shell 层面的 glob 展开，而 Nginx 自身不解析通配符：
- 确保匹配到的文件名以
.conf结尾，且无隐藏文件干扰（如.backup.conf不会被包含） - Linux 下按字母序加载（
01-site.conf先于99-app.conf），但 Nginx 不保证顺序——多个server块监听同一端口时，第一个出现的块若没设default_server，就会成为隐式兜底 - 临时验证：把你的配置文件重命名为
00-myapp.conf，再跑nginx -T看是否出现在最前面
留意宝塔等面板的“伪 include”陷阱
在 Windows 或宝塔环境，看似写了 include /www/server/panel/vhost/nginx/*.conf;，但实际生效的是符号链接或模板生成逻辑：
- 宝塔修改虚拟主机配置，真正写入的是
/www/server/panel/vhost/nginx/xxx.conf，但主配置中该路径可能被面板动态管理，手动改nginx.conf会被还原 - Windows 下符号链接需管理员权限创建，否则 include 会静默失败
- 建议：直接在面板内增删站点，或确认其生成的最终配置已同步进
nginx.conf的 include 范围内
