nginx主域名和子域名配置冲突如何解决，常见原因有哪些？

当nginx主域名和子域名配置冲突时，本质上是server_name匹配规则与server块优先级的问题，最直接的解决方法是严格区分精确匹配与通配符匹配，并将子域名配置放在主域名配置之前。很多站长在配置Nginx时，会遇到主域名正常访问但子域名跳转错误，或子域名始终指向主站点的问题，这通常不是Nginx坏了，而是配置文件里的server块被“顺序”或“匹配长度”干扰了。

nginx主域名和子域名配置冲突怎么解决？先理清匹配顺序

Nginx处理请求时，根据HTTP请求头中的Host字段去匹配server_name，匹配规则并非简单的自上而下，而是遵循精确匹配 > 前置通配符 > 后置通配符 > 正则表达式的优先级顺序，如果主域名和子域名都使用了同样的匹配方式，比如都写成.example.com，那么Nginx会默认选择先加载的server块。

加载中

Nginx代理避坑指南！彻底搞懂proxy_pass路径规则

史努比会点运维

4650189-

原视频地址

用“精准域名”阻断通配符的干扰

最典型的冲突场景是：主域名配置了server_name example.com，子域名配置了server_name .example.com，同时还有一个默认server块，此时请求blog.example.com时，如果.example.com没有被命中，它可能会落到主域名的server块里，原因是Nginx的server_name匹配中，精确名字永远高于通配符，但如果你的主域名配置写的是server_name example.com .example.com，这就等于把主域名和所有子域名混在一起,导致子域名请求优先匹配到了主站。

解决办法很简单： 将主域名和子域名拆分成独立的server块，主域名块只写server_name example.com，子域名块单独写server_name blog.example.com，如果子域名数量固定，逐一列出即可，如果子域名数量很多，用.example.com但需要确保没有更宽泛的server_name与之冲突。

常见冲突场景：主域名指向了子域名目录

有些朋友发现访问www.example.com时，页面内容显示的是blog.example.com，这是典型的server块内部root指令错位，比如你在子域名的配置里使用了root /var/www/blog;，但主域名的server块没有单独指定root，结果Nginx沿用了全局的root或者上一个server块的设置，这不属于server_name冲突，而是配置上下文混乱。

排查方法是执行nginx -T查看完整配置，重点看每个server块内的root和index指令，建议每个server块都显式指定root,避免依赖外部include的默认值。

nginx子域名配置不生效原因：最常见的是这三点

如果你确认server_name没有冲突，但子域名还是无法访问,可以按以下顺序检查。

第一：DNS解析还没生效

子域名能不能访问，第一步不是Nginx，而是DNS，必须将子域名解析记录（A记录或CNAME）指向你的服务器IP，很多人在本地修改了hosts测试，其他设备仍然反馈不通，这就是DNS缓存问题，业内专家指出，DNS传播时间通常在几分钟到24小时之间，如果配置完立即测试,极易误判为Nginx冲突。

验证命令： 在服务器上执行dig blog.example.com或nslookup blog.example.com,看返回的IP是否与主域名一致。

第二：配置文件包含顺序导致的覆盖错误

Nginx加载配置的默认路径是/etc/nginx/nginx.conf，其中通常会有include /etc/nginx/conf.d/.conf;，如果你在conf.d下同时创建了example.com.conf和blog.example.com.conf，且两个文件里都定义了同名server块，Nginx会按照文件名字母顺序依次加载，假设b开头的文件先加载，e开头的文件后加载，如果两者有冲突的指令，后加载的会覆盖前者，这不是server_name的冲突，而是配置文件加载顺序导致变量覆盖。

解决方法是：将主域名和子域名放在同一个conf文件里，或者使用明确的include顺序，避免依赖字母序，建议将example.com和blog.example.com放在一个server块中并列写两个server块,这样逻辑更清晰。

第三：listen指令的default_server陷阱

很多默认配置里有listen 80 default_server;，这个default_server意味着当请求的Host没有匹配到任何server_name时，Nginx会将请求交给这个server块，如果你将主域名配置为default_server，而子域名请求因为某种原因没有被精确匹配,就会落到主域名块。

检查方法： 在子域名配置中，将listen 80;修改为listen 80 default_server;可以暂时强制子域名成为默认站点，但这不是长久之计，正确的做法是确保子域名的server_name完全匹配,不要依赖default_server做路由。

主域名和子域名配置冲突：用rewrite规则解决跳转异常

还有一种冲突表现为“子域名访问时被强制跳转到主域名”，通常是因为使用了含server_name跳转的rewrite规则。

rewrite中的变量匹配陷阱

比如你在主域名server块里写了if ($host = 'example.com') { rewrite ^(.)$ https://www.example.com$1 permanent; }

，这个$host变量是所有请求都有的，如果子域名请求的Host恰好被解析到了这个server块,就会触发跳转。

更严谨的写法是： 不要在主域名块内判断子域名，而是单独为子域名设置server块,然后在子域名块内做跳转。

server {
    listen 80;
    server_name blog.example.com;
    return 301 https://$host$request_uri;
}

这样只匹配子域名,不影响主域名。

严格区分主域名和子域名，避免使用通配符正则

有些配置为了省事，使用server_name ~^(?<sub>.+).example.com$，这种正则匹配方式会捕获blog、news等任意子域名，如果同时存在精确的主域名server块，请求example.com会走精确块，而blog.example.com会走正则块，但正则匹配很容易与后续的server_name顺序产生冲突，特别是当你有多个正则时,Nginx会按顺序匹配第一个符合条件的。

建议： 非必要不要用正则server_name，直接列出具体子域名，如果你确实需要泛解析，使用.example.com而不是正则,并确保主域名单独配置精确名称。

实际操作：标准配置模板参考

以下是一个经过验证的、主域名和子域名无冲突的配置结构，可直接对照修改你的/etc/nginx/conf.d/example.conf。

# 主域名配置
server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/main;
    index index.html;
}
# 子域名配置
server {
    listen 80;
    server_name blog.example.com;
    root /var/www/blog;
    index index.html;
}

在这个结构里，example.com和blog.example.com是完全独立的server块，各自指定root，访问任意一个域名都会命中自己的server块,不存在互相干扰。

如果还有https证书冲突

启用SSL后，主域名和子域名通常使用不同证书，你需要为每个域名配置独立的listen 443 ssl;和ssl_certificate路径，不少人会碰到“子域名用主域名证书也能访问，但浏览器报错”的情况，这是因为server_name匹配正确但证书不匹配。正确的做法是使用Let’s Encrypt的SAN证书，一个证书包含多个域名,或为每个子域名单独签发证书。

如何验证修改是否生效

修改配置后必须执行nginx -t检查语法，然后systemctl reload nginx重载，之后用curl -H "Host: blog.example.com" http://你的服务器IP测试，确认返回的是子域名页面，如果需要测试HTTPS，用

curl -k https://blog.example.com -I查看HTTP状态码。

防止冲突的长期策略：配置结构整理

多数情况下，配置冲突源于文件目录规划混乱，行业共识认为，对于一个小型站点，主域名加两三个子域名的规模，最佳实践是将每个站点的server块单独放在独立文件中，并在nginx.conf里使用显式include，而不是conf.d/.conf的隐式通配。

一个推荐的目录结构是：

• /etc/nginx/sites-available/example.com
• /etc/nginx/sites-available/blog.example.com
• /etc/nginx/sites-enabled/ 下创建软链接

这样可以通过启用/停用软链接来控制生效顺序，也方便查看哪个域名加载了哪个配置，如果使用conf.d，务必在每个文件顶部加注释，并统一命名规则，比如01-main.conf、02-blog.conf,这样加载顺序一目了然。

Q&A：nginx主域名和子域名配置冲突常见问题

为什么子域名访问时显示的是主站内容？

这是因为子域名的请求Host没有匹配到对应的server_name，被Nginx的default_server或主域名的server块接收了，请检查子域名配置是否单独存在，以及listen指令是否使用了default_server，如果子域名和主域名在同一个server块里，且server_name写为example.com .example.com，此时子域名大概率会进入该块，建议将主域名和子域名拆分为两个独立server块,并各自指定root。

设置子域名后需要重启nginx吗？

不需要重启，只需执行nginx -t检查配置无误后，使用systemctl reload nginx即可平滑重载，reload不会中断现有连接，但会应用新配置，如果配置有语法错误，reload会失败并保留旧配置，某些情况下修改了证书文件，可能需要执行nginx -s reload,但同样不需要完整重启进程。

主域名和子域名都用https，证书怎么配置不冲突？

如果证书是单域名证书，必须为每个域名单独配置listen 443的server块，并且ssl_certificate路径不能混用，如果使用多域名SAN证书，可以在同一个server块里通过ssl_certificate指向包含多个域名的证书文件，配置时需注意：Nginx的SSL握手发生在server_name匹配之前，因此对于443端口，先根据IP和SNI（Server Name Indication）选择证书，再进行HTTP层的server_name匹配，所以证书配置错误时，即使server_name正确，也会因SSL握手失败而无法访问，建议使用泛域名证书覆盖主域名及所有子域名,彻底解决证书冲突。