发布日期：2026 年 9 月 19 日 · RootGS 技术编辑
网站已经迁到新服务器，管理员访问正常，客户却仍看到旧页面；也有人能打开首页，但邮件突然收不到。这类问题往往不是一句“等待解析生效”就能解释。DNS 迁移同时涉及权威记录、递归缓存、客户端状态和业务数据一致性。本文把改 IP 与更换 DNS 服务商分开讨论，给出可记录、可验证的迁移方法。示例域名和地址仅用于说明，请替换为自己的实际值。
一、先分清这次迁移究竟改变了什么
仅修改 A 或 AAAA 记录，是把某个名称指向新地址；更换域名的 NS，则改变谁负责回答该域名的权威查询。两者可以一起发生，但排错时必须分别核对。若前方还有 CDN，公网查询得到的可能是边缘地址，修改源站配置并不要求公网 A 记录直接显示新服务器 IP。
开始前制作记录清单：根域名、www、业务子域名、A、AAAA、CNAME、MX、TXT、CAA，以及当前权威服务器和 DNSSEC 状态。邮箱的 SPF、DKIM 与 DMARC 也不能漏掉。导出记录后检查是否包含服务商特有的代理状态、别名展平或转发设置；这些能力未必随标准区域文件一起迁移。
二、TTL 要提前调整，不能追溯修改旧缓存
TTL 告诉缓存某条记录可以保留多久。假设旧记录 TTL 是 3600 秒，切换时才改成 300 秒，已经拿到旧答案的缓存不会因此自动缩短到五分钟。更稳妥的做法是提前调低可调整的记录 TTL，并给旧缓存足够时间自然过期，然后再安排正式切换。
也不要把所有失败归为同一种缓存。浏览器、操作系统和递归解析器可能分别保留结果；此前查询过不存在的名称，还可能缓存否定答案。负缓存的时间涉及权威响应中的 SOA 信息，并不等于后来新增 A 记录的 TTL。变更记录、清空自己电脑的缓存，也无法清掉所有客户网络中的缓存。
三、先问权威服务器，再比较客户实际使用的解析器
下面的查询用于观察，不会修改解析。第一步看名称当前的 NS，第二步直接询问实际权威服务器，第三步分别看 IPv4 和 IPv6。示例中的 ns1.example.net 必须换成你刚确认的权威服务器。
dig NS example.com +short
dig @ns1.example.net example.com A +noall +answer
dig @ns1.example.net example.com AAAA +noall +answer
dig example.com A
dig example.com AAAA记录查询时间、解析器地址、响应状态、答案和剩余 TTL。仅看 +short 容易遗漏错误状态，因此诊断失败时应保留完整响应。如果权威答案仍旧，先检查发布的区域或委派，而不是反复刷新浏览器；如果权威已新而某些递归仍旧，则继续核对缓存和委派链。公共解析器的成功结果不能代表客户所在网络的结果。
四、同时检查 AAAA、DNSSEC 和证书
A 已指向新站而 AAAA 仍指向旧站，会造成支持 IPv6 的用户走另一条路径。新服务器尚未具备 IPv6 服务时，应按迁移方案处理 AAAA，而不是为了让查询看起来完整而填写不可达地址。还需核对 CNAME 链的最终目标，以及新站是否识别正确的主机名。
更换 DNS 服务商时，DNSSEC 的父区 DS 与新权威的签名必须协调。如果注册商仍发布旧 DS，新权威却没有对应密钥和有效签名，启用验证的解析器可能返回 SERVFAIL。不要看到 SERVFAIL 就随意关闭验证：先核实委派、DS、DNSKEY 及签名，再按新旧服务商的迁移流程安排变更。涉及移除或更换 DS 时，同样要考虑缓存窗口。
五、切换前用指定地址验证新站
在支持该参数的 curl 中，可以保留目标域名，同时将连接定向到待验收地址。这样能够检查正确的 Host 和 TLS 名称是否被新服务器接受。下面的地址属于文档示例地址，不能用于真实验收。
curl --resolve example.com:443:192.0.2.10 -I https://example.com/不要增加跳过证书验证的选项来掩盖证书问题。此命令只验证指定连接的响应头；HEAD 与真实 GET 可能经过不同业务逻辑，首页成功也不代表登录、表单和订单可用。应另外用测试账号完成关键流程，并核对附件、跳转目标和后台任务。直连源站测试不能替代对 CDN 公网入口的测试。
六、保留旧入口，但先解决双边写入
缓存逐步更新期间，新旧入口可能同时收到流量。静态页面可以同步保留，但带订单、会员和上传功能的系统必须确定唯一写入位置。不能让新旧数据库各自接单，再期望靠改 DNS 自动合并数据。可根据架构选择维护窗口、经过验证的数据同步，或让旧入口安全地转发到新的应用入口。
回退也不仅是把 A 改回去。若新站已经产生订单，直接退回旧数据库会让新数据消失在业务视野中。迁移前应记录数据切换点、旧站保留时间、异常阈值和回退负责人；出现问题时先判断是解析、应用还是数据层故障，再决定恢复哪一层。
七、怎样确认迁移真的结束
验收应覆盖主要域名、IPv4 与 IPv6、不同客户网络、HTTPS、邮件收发和核心交易流程。记录新旧入口的请求趋势，但不要把旧站零访问当作唯一标准，因为监控、爬虫或固定 IP 客户端可能继续访问旧地址。确认无重要业务依赖后，再安排下线旧资源。
建议保留一份包含变更前后记录、查询证据、业务验收结果及恢复步骤的迁移单。用户仍访问旧站时，这份记录能帮助判断具体停在哪一层，而不是每次都从“再等几个小时”开始。DNS 缓存没有对所有网络同时生效的统一倒计时，可靠的结论来自分层证据。
