DNS 已经改了，为什么还访问旧 IP？

域名改成新 IP，在线检测也正常，一台电脑却仍打开旧站。先查那台电脑走的解析过程，区分权威记录、递归缓存和客户端设置。另一条网络正常，不能说明问题已经解决。

检查时使用真正失败的完整域名。根域、www 和其他子域可以拥有不同记录；HTTPS 能否打开还涉及证书与源站服务，DNS 正确只是其中一步。

先问权威服务器，而不是反复清缓存

用安装了 dig 的终端查看 NS，再逐台查询。example.com 和权威服务器名称替换为实际值：

dig example.com NS +short
dig @ns1.example.net www.example.com A +norecurse
dig @ns1.example.net www.example.com AAAA +norecurse

观察 Answer、CNAME 链和权威标记。所有返回的权威 NS 都要核对；若子域已单独委派，沿它的实际委派查询，不能把父区域无答案当作域名不存在。

若权威答案仍旧或不同 NS 结果不一致，先查是否编辑了错误的 DNS 区域、注册商 NS 是否匹配，以及区域同步。缓存过期以后仍可能收到错误权威答案，刷新电脑解决不了这个配置问题。

Cloudflare 代理记录公开返回的是代理地址，不能期待它直接展示源站 IP。先确认代理状态，再判断答案是否符合预期；代理记录与 DNS only 的 TTL 规则也不同，见 Cloudflare TTL 文档。

记录本机默认解析器与公共解析器的答案，不要只截一张在线检测图：

dig www.example.com A
dig @1.1.1.1 www.example.com A
dig @8.8.8.8 www.example.com A
dig www.example.com AAAA

默认解析器仍旧、公共解析器已新时，查当前网络 DNS 配置、VPN 或公司内部解析规则。Answer 中的 TTL 可提供缓存剩余时间线索；CNAME 链每段也可能有自己的缓存。

把 TTL 现在改小，不会追溯缩短此前已缓存的旧记录。也没有所有变更统一等待 24 或 48 小时的规则，具体受旧 TTL、委派及客户端缓存影响。

别遗漏 AAAA。新 A 已正确而旧 IPv6 地址仍指向旧机，具备 IPv6 的客户端可能走另一条路径。只有新服务器确实提供并配置了 IPv6，才填写相应 AAAA；不能为凑齐记录随便加一个地址。

hosts 文件、操作系统缓存、安全 DNS、VPN 分流都可能影响客户端。dig、ping 和浏览器未必使用同一套解析路径，不能看到 dig 新地址就断定页面应该相同。

先查看浏览器实际连接信息和系统配置，核对是否确实访问了旧服务器。如果连接的是 CDN，而页面内容旧，还需另查 CDN 或应用缓存，这与 DNS 缓存不是一回事。刷新本机缓存只能影响相应本机路径，不能替 ISP 清缓存。

要单独检查新源站是否已经服务这个域名，可以保留域名和证书校验，指定连接地址。下面 IP 是文档示例：

curl -v --resolve www.example.com:443:203.0.113.20 \
  https://www.example.com/

它帮助区分新源站部署与普通解析问题，不证明其他用户已切换。源站只允许 CDN 访问时，直连失败还要结合访问策略；不要为验证临时关闭全部保护，也不要把忽略证书错误后的成功当成正常 HTTPS。

迁移前降低 TTL，并给此前旧 TTL 足够时间到期。切换后保留旧入口在过渡期提供正确内容或受控转发，连接失败不保证客户端立即重新查询 DNS。

动态应用尤其要安排数据库与写入方向，避免新旧入口各自写一份数据。回退记录也会被缓存，不能把改回旧 IP 理解为全体客户端瞬间回退。

需要换服务器时，先比较建站 VPS 的备份与迁移条件，把旧机保留期和两边并行费用算进预算。换了 IP 不会自动解决 NS 错误、旧 AAAA 或证书问题。

迁移目标优先按原应用、数据库与恢复包选资源，保留新旧实例同时运行的预算。小博客可比较 RackNerd 的建站 VPS；需要中文 IP 与系统文档可看雨云 RCS 的地域与公网选项。购买后先验证新源站的域名和 HTTPS，再切记录，旧 TTL、AAAA 或权威记录有问题，重新购买服务器也解决不了。

恢复检查至少包含各权威答案、受影响网络递归答案，以及那个网络上的实际页面内容。只确认新源站能访问，可以证明源站这一层正常；旧入口何时关闭，还要结合旧 TTL、访问记录和数据一致性安排。