DNS 已改，为什么有些网络仍访问旧 IP

你已把域名的 A 记录改成新 IP，在线检测显示新地址，自己的电脑或某个运营商网络却仍访问旧服务器。先比较权威 DNS、递归解析器和客户端看到的记录，再判断该等缓存、改记录还是查本机配置。在线检测的一组结果，不能代表所有用户的解析路径。

权威记录有没有全部改对

先确认你修改的是实际域名对应的区域。根域与 www 是不同记录，子域还可能通过 CNAME 指向别处。注册商设置的 NS 与你正在编辑的 DNS 服务商也要对应。

以 www.example.com 为例，先取得 example.com 的 NS，再逐台查询：

dig example.com NS +short
# ns1.example.net 替换为上一步返回的一台权威服务器
dig @ns1.example.net www.example.com A +norecurse
dig @ns1.example.net www.example.com AAAA +norecurse

对返回的每台 NS 重复查询，查看 Answer 中的地址、可能的 CNAME，以及响应是否具有权威标记。若子域已委派到另一组 NS，要沿委派查询，不能把父区域无答案误读为子域不存在。

如果不同权威服务器给出不同记录，优先检查区域同步或服务商配置。递归缓存过期以后仍可能从不同权威服务器拿到不同数据，此时只让用户清缓存不能消除根因。

若使用 Cloudflare 代理，公开解析通常返回 Cloudflare 的代理地址，不能期待 A 记录查询直接显示源站新 IP。要先确定该记录是 DNS only 还是代理状态，再比较预期结果。

权威正确，再比较递归解析器

查询本机默认解析器和两组公共解析器，记录差异：

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

Answer 记录中的 TTL 可以帮助判断缓存剩余时间。公共解析器显示新地址，而本机默认解析器仍给旧地址，通常应检查本机所在网络的递归缓存或 DNS 配置。也要确认 VPN、公司内网或分流规则是否让同一个名字有意返回不同地址。

没有必要规定所有 DNS 变更都必须等固定的 24 或 48 小时。缓存时间与先前收到记录时的 TTL 有关，也可能涉及 CNAME 链或其他缓存层。现在把 TTL 改小，不能追溯缩短已经缓存的旧记录。Cloudflare 代理记录使用自动 TTL，DNS only 记录则可配置 TTL。

不要只查询 A 记录。如果旧的 AAAA 仍指向另一台服务器，具有 IPv6 的客户端可能通过它连接，导致部分网络正常、部分网络异常。修正 AAAA 时先确认新服务器是否确实提供 IPv6，不能随意填一个地址。

dig 已正确，浏览器仍访问旧站

这时要查客户端实际使用的解析路径。hosts 文件可能覆盖域名；操作系统有本地缓存；浏览器还可能使用独立的安全 DNS。dig、ping 和浏览器未必经过完全相同的路径。

在 Windows 上，本地 DNS 缓存相关命令是：

ipconfig /displaydns
ipconfig /flushdns

它们只针对本机相关缓存，不会替 ISP 或远程递归服务器刷新记录。刷新后仍应重新查看解析结果，不要把命令正常退出当作网站已经恢复。Linux 的解析组件和 macOS 的处理方式不同，应按实际系统选择命令，不把 Windows 命令复制过去。

如果要暂时绕过 DNS，检查新源站是否能正确处理该域名，可使用下面的诊断方式；IP 为示例：

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

这个请求保留域名、SNI 和证书校验，同时指定连接地址。它能帮助区分“新源站部署异常”与“正常请求仍解析到旧地址”，但不能证明普通用户的 DNS 已经更新。若网站源站只允许 CDN 访问，直连被拒绝还应结合这项访问策略判断。

迁移时保留旧入口比强迫用户刷新可靠

关掉旧服务器不会普遍触发浏览器或 ISP 重新查询 DNS。客户端仍可能使用缓存的旧地址，直接得到连接错误。

更稳妥的安排是提前降低 TTL，并给此前的旧 TTL 足够时间到期；切换时让旧入口在过渡期继续提供正确服务或受控转发。动态应用要同时规划会话、数据库和写入流向，避免两个入口分别写入互不一致的数据。

保留旧 DNS 记录值和旧源站配置。发现新站异常时按预定方案恢复记录及服务，但也要考虑回退记录仍会被缓存，不能把 DNS 回退视为所有客户端瞬时切换。

用分层结果确认恢复

验收分别记录各权威服务器的答案、受影响网络使用的递归服务器答案，以及浏览器实际访问的新站内容。对于原来失败的网络，重新检查它自己的解析器和访问结果；只测另一条已经正常的网络，不能替它完成验收。

这些结果可以说明已检查路径恢复，不能据此宣布全网缓存全部清空。旧入口何时关闭，应结合旧 TTL、访问记录和迁移数据一致性决定。