域名注册改版或迁移时应核对什么:一份可执行检查清单

📍 WDQWDWQD987AAAAA:216.73.216.23
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /765cdf9bee70.html
📄

域名注册改版或迁移时应核对什么:一份可执行检查清单

域名注册信息在改版或迁移时最容易出问题的不是“域名能不能打开”,而是注册商、DNS、解析记录和证书之间的对应关系是否仍然一致。核对的目标是收集可复现的证据:用whois、dig、curl等命令分别确认注册状态、权威解析和实际响应,而不是只看浏览器能否访问。下面按检查项给出要查什么、怎么查、结果说明什么。

核对注册商与域名状态,确认控制权没有断档

要查的是域名当前注册商、到期时间、状态码和注册人联系方式是否仍由你方掌握。查询方法是使用注册局或注册商的公开查询入口,或命令行执行whois example.com,重点看 Registrar、Expiry Date、Status 三类字段。如果状态里出现 clientHold 或 serverHold,说明域名已被暂停解析,迁移中出现的访问中断很可能来自这里,而不是服务器故障。若注册商或注册邮箱已经不是你方人员,需要先走转移或联系人变更流程,再继续后面的解析核对。

核对 DNS 托管位置与权威服务器是否指向预期

要查的是域名使用的权威 DNS 服务器是哪一组,以及这些服务器是否由你预期的服务商托管。查询方法是执行dig NS example.com +short,再对每个权威服务器执行dig @ns1.example.com example.com A,对比不同权威服务器返回的结果是否一致。如果 NS 记录还指向旧服务商,而你在新服务商处修改了记录,实际生效的仍是旧记录;如果多台权威服务器返回不一致,说明区域文件未同步,迁移期间会出现间歇性解析异常。这一步能区分“记录填错了”和“记录填对了但没生效”两种情况。

核对 A、AAAA、CNAME 与 MX 记录,逐条比对迁移前后

要查的是关键主机记录在迁移前后是否被完整复制。查询方法是迁移前导出记录清单,迁移后逐条执行dig example.com A、dig www.example.com CNAME、dig example.com MX,把返回值与清单比对。常见遗漏包括:只改了主域 A 记录,忘了 www 的 CNAME;只改了网站解析,忘了邮件 MX 和 SPF、DKIM 相关的 TXT 记录,导致迁移后邮件收发异常。结果判断标准是每一条记录的记录类型、主机名、目标值和 TTL 都能与迁移前清单对应;TTL 在迁移前适当调低,可以减少切换期间的缓存等待。

核对 HTTPS 证书覆盖范围与实际响应

要查的是证书是否覆盖迁移后使用的所有主机名,以及服务器返回的状态码和跳转链路。查询方法是执行curl -I https://example.com和curl -I https://www.example.com,观察证书主体、有效期和 HTTP 状态码;也可用openssl s_client -connect example.com:443 -servername example.com查看证书链。如果证书只签了主域,www 子域会报证书不匹配;如果返回 301 指向一个已不存在的路径,说明跳转规则没有随迁移更新。需要说明的是,HTTPS 只表示传输加密,不代表站点没有漏洞,也不构成排名保证,它只是迁移后必须可用的基础项。

核对抓取与索引相关文件,区分限制与移除

要查的是 robots.txt、站点地图和页面 canonical 是否与迁移后的结构一致。查询方法是直接访问https://example.com/robots.txt和站点地图地址,确认其中引用的主机名和路径没有指向旧域名;再抽查若干页面源码中的 canonical 是否指向自身而非旧地址。这里有两个容易误判的点:robots.txt 中的 Disallow 只是限制抓取,不等于把已收录页面从索引中移除;站点地图提交也不保证收录,它只是帮助发现 URL。如果迁移后希望旧地址不再出现在结果中,应使用对应的移除或重定向手段,并分别在不同搜索引擎中核查支持情况,不能假设一处设置对所有引擎同时生效。

用一份最小验证清单收尾

下一步建议先做一次迁移前的记录导出和 TTL 调整,把上述命令的输出保存为文本,迁移完成后用同一组命令重新执行并逐项比对。出现不一致时,先定位是注册层、解析层还是应用层的问题,再决定回滚或修正,避免在多个层面同时改动而无法判断原因。

图1 图2

nginx