随机子域名打开网站的完整问题链：泛解析把任意域名送进服务器，nginx 缺 default_server 又把它递给字典序第一的残留配置

随便编个子域名，都能打开我的站

作者

9 月 28 号下午在清死链。清单上 9 条逐个对完，全是 404，本来就不需要处理——内容真没了，404 就是标准答案。

顺手翻 nginx 配置做检查时，我干了件以前从没干过的事：编一个根本不存在的子域名，拿 curl 实测一下。

它打开了。200，返回的还是一个正经内容页。

先说结论：域名做了泛解析，nginx 又没标 default_server，没登记的域名全被丢给「配置目录里排最前的那一块」——我那恰好是份旧域名时期的残留配置。修法是加一个兜底 server 块，把未知域名全部断开。下面按当时的顺序讲。

编出来的子域名，为什么会打开

第一反应是 DNS 被人动了。查解析记录：不是。*.budingwz.cn 全部指向这台服务器，泛解析，我自己配的，图的就是子域名随开随用。

所以解析层是「通」的，编什么域名都能落到这台服务器。问题在下一层。

nginx 收到请求，拿 Host 头去匹配 server_name。全都匹配不上怎么办——它不会拒绝，必须挑一个「默认 server」来接；你没显式声明 default_server，它就按配置文件的加载顺序取第一个。我到 vhost 目录里按文件名一排序，排最前的正是一份旧域名时期的配置：域名早停用了，配置还在服役，连站点目录都挂在旧域名的目录名下。

实测（在服务器上改 Host 头）：

curl -sk -o /dev/null -w '%{http_code}' -H 'Host: zzztest.budingwz.cn'   https://127.0.0.1/
curl -sk -o /dev/null -w '%{http_code}' -H 'Host: random123.budingwz.cn' https://127.0.0.1/
curl -sk -o /dev/null -w '%{http_code}' -H 'Host: abc.budingwz.cn'       https://127.0.0.1/

三次全是 200，内容是同一套引流页。这些域名我从没创建过。

随机子域名打开网站的完整问题链：泛解析把任意域名送进服务器，nginx 缺 default_server 又把它递给字典序第一的残留配置
随机子域名打开网站的完整问题链：泛解析把任意域名送进服务器，nginx 缺 default_server 又把它递给字典序第一的残留配置

为什么当天就得修

一个域名一个站，十个域名十个站，正常。泛解析坏在：第 101 个域名不用申请，编出来就存在，照样 200 加完整内容。

在搜索引擎眼里，这就是「同一主体挂大量内容相似的站点」——站群判定的典型特征。它不是扣几分的事：单篇文章质量差，最多那篇不收录；判了站群，主站整站降权。子站里恰好还有两组内容一字不差的镜像，连字节数都相同。主站此前被判定低质，有多少是这些子站贡献的，没法拆开量化，但这个口子一天开着，别的优化都白搭。

兜底块：没登记的域名一律 444

思路很直：新建一个 server 块接住所有未匹配的域名，进来就 return 444——nginx 特有状态码，不回任何内容，连接直接关。

# 文件名 0.zz-wildcard-catchall.conf，0. 开头抢字典序第一位
server {
    listen 80 default_server;
    listen 443 ssl http2 default_server;
    server_name _;

    # 证书直接用主站的：444 不返回内容，匹配不匹配没人看得到
    ssl_certificate     /www/server/panel/vhost/cert/www.budingwz.cn/fullchain.pem;
    ssl_certificate_key /www/server/panel/vhost/cert/www.budingwz.cn/privkey.pem;

    # 证书续签验证路径必须放行
    location ^~ /.well-known/acme-challenge/ {
        root /www/wwwroot/$host;
        try_files $uri @acme_main;
    }
    location @acme_main {
        root /www/wwwroot/www_budingwz_cn;
        try_files $uri =404;
    }

    location / {
        return 444;   # 必须在 location 里，写在 server 顶层会绕过上面所有 location
    }
}

两个细节。default_server 显式声明了，文件名又用 0. 开头抢加载顺序的第一位，双保险。正式子站有精确的 server_name，精确匹配优先，碰不到兜底块；随机子域名没有真实用户，444 是最干净的处置。顺带一句：兜底块要是不配证书，TLS 握手那一步就直接失败，效果上也算断——这层我没细究，反正主站证书现成，nginx -t 过了就行。

第一版在这里踩了个坑：return 444 写在了 server 顶层，证书续签路径跟着一起被掐断。这个坑展开值得单独一篇，也确实单独写了：nginx 的 return 写在 server 层，会绕过块内所有 location。

改完测什么

18 项校验一次跑完，四个方向缺一不可：

兜底块上线的四组校验判据：随机子域该断、正式子站该通、主站不能动、证书路径必须可达
兜底块上线的四组校验判据：随机子域该断、正式子站该通、主站不能动、证书路径必须可达
  • 5 个编出来的域名 → 断开（000）
  • 7 个正式子站 → 200 且带 noindex
  • 主站 → 不受任何影响
  • 证书续签路径 → 404 或 403 都行，唯独不能是 000（这条路径被拦过一回，网站突然提示证书不受信任那篇就是它）

跑完 18/18。从那一刻起，编出来的子域名再也打不开任何东西。

那份旧域名的残留配置还原样躺在目录里。域名不解析就闹不了事，可哪天域名被人重新注册，配置立刻复活——这是下一件要清的事。

你的站要是也做了泛解析，现在就可以编个子域名试一下。返回 200 的话，挂在外面的「站」比你以为的多。

发表评论