网站已经迁到新服务器，域名解析也改成了新 IP，但有些人看到的是新站，有些人仍然打开旧页面；自己用手机流量访问正常，办公室网络却一直不变。遇到这种情况，先不要反复修改 DNS 记录，也不要急着删除旧服务器。问题通常不在“解析有没有改”，而在于访问请求究竟经过了哪一层缓存，以及最终连接的是哪台源站。
下面按实际排查顺序处理：先确认旧内容来自哪里，再分别检查权威 DNS、公共递归 DNS、本机 Hosts、浏览器和 CDN 配置。
第一步：确认看到的真是旧服务器内容
页面内容没更新，不一定代表请求到了旧服务器。CDN 页面缓存、WordPress 缓存插件、反向代理缓存，甚至浏览器缓存，都可能继续返回旧页面。
最实用的方法是在新旧服务器上放置一个容易识别、但不会影响访客的标记。例如：
- 在响应头增加
X-Origin: new-server或X-Origin: old-server； - 在站点根目录放置内容不同的
/origin-check.txt； - 检查两台服务器 Web 访问日志，看测试请求出现在哪一台机器上。
可以先查看响应头：
curl -I https://example.com/
如果站点接入了 CDN，响应头里看到的可能只是 CDN 节点信息。这时还要结合源站日志，不能只凭页面外观判断。
第二步：分别查询权威 DNS 和递归 DNS
DNS 查询至少要分成两层看。
权威 DNS 保存域名当前应当返回的记录；递归 DNS 则替用户查询并缓存结果。即使权威记录已经改成新 IP，某个递归解析器仍可能在 TTL 到期前返回旧 IP。
先找出域名使用的权威 DNS：
dig NS example.com +short
然后直接向其中一台权威服务器查询：
dig @ns1.example-dns.com example.com A
dig @ns1.example-dns.com www.example.com A
再查询常见公共递归 DNS：
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @9.9.9.9 example.com A
Windows 没有安装 dig 时，可以用：
nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8
判断结果时重点看三件事：
- 权威 DNS 是否已经返回新 IP；
- 不同递归 DNS 返回的 IP 是否一致；
- 域名是否同时存在
A、AAAA或CNAME，其中某条记录仍指向旧环境。
如果权威 DNS 仍返回旧 IP，问题在 DNS 配置或记录尚未保存成功；如果权威 DNS 返回新 IP，而部分递归 DNS 返回旧 IP，通常是在等待缓存过期。
第三步：正确理解 TTL，不要把它当作切换倒计时
TTL 表示解析结果可以被缓存多长时间，但它不是从你修改记录的那一刻统一开始倒计时。
假设旧记录的 TTL 是 3600 秒。某个递归 DNS 在修改前 5 分钟刚查询并缓存了旧 IP，那么它可能继续使用这条结果约 55 分钟；另一个解析器的缓存恰好到期，则可能立即获取新 IP。因此迁移后的短时间内，不同网络出现不同结果是可能的。
还要注意，迁移时真正影响等待时间的是“修改前旧记录的 TTL”。在切换后才把 TTL 从 3600 秒降到 300 秒，无法让已经存在的旧缓存立刻失效。
比较稳妥的做法是：
- 计划迁移前 24 至 48 小时降低 TTL；
- 切换后至少保留旧服务器一段时间；
- 等主要地区和常用递归 DNS 都稳定返回新 IP，再恢复常规 TTL；
- 不要仅凭自己电脑的一次查询就关停旧服务器。
如果必须紧急切换，可以尝试使用公共 DNS 提供商的缓存刷新工具，但它只能影响对应解析服务，不能清除所有运营商、本地路由器和企业 DNS 的缓存。
第四步：检查本机 Hosts 和本地 DNS 缓存
如果只有某一台电脑访问旧站，优先检查本机。
Windows 的 Hosts 文件通常位于：
C:\Windows\System32\drivers\etc\hosts
Linux 和 macOS 通常位于：
/etc/hosts
搜索域名是否被手动绑定到旧 IP。迁移测试时临时添加的 Hosts 记录很容易被忘记，而且它的优先级通常高于普通 DNS 查询。
Windows 可以清理本机 DNS 解析缓存：
ipconfig /flushdns
清理后重新打开浏览器再测试。若仍异常，还可以依次排查：
- 浏览器自身的 DNS 或连接缓存；
- 系统是否启用了代理软件、VPN 或安全 DNS；
- 路由器是否缓存解析结果；
- 公司网络是否使用内部 DNS；
- 浏览器是否通过 HTTPS DNS 使用了与系统不同的解析器。
最简单的交叉验证方式，是在同一设备上分别使用家庭宽带、手机流量和另一家运营商网络访问。如果只有一个网络异常，问题大概率在该网络使用的递归 DNS 或代理链路。
第五步：别漏查 AAAA、CNAME 和 CDN 回源
迁移时只修改 A 记录还不够。以下几类配置经常导致“部分用户仍访问旧服务器”。
1. AAAA 记录仍指向旧服务器
支持 IPv6 的网络可能优先连接 AAAA 记录，而不支持 IPv6 的网络使用 A 记录。于是两类用户会到达不同服务器。
dig example.com A +short
dig example.com AAAA +short
如果新服务器尚未配置 IPv6，应删除或更新旧的 AAAA 记录，并确认站点、防火墙和证书均支持新的 IPv6 地址。
2. www 与根域名配置不一致
检查 example.com 和 www.example.com，不要默认两者会自动同步。有时根域名已经改到新 IP，而 www 的 CNAME 仍指向旧的 CDN 域名。
3. CDN 的源站地址没有修改
开启代理或 CDN 后，公开 DNS 返回的是节点地址，不会直接显示源站 IP。此时要到 CDN 后台检查：
- 当前回源主机名或回源 IP；
- 是否存在多个源站和故障转移组；
- 边缘缓存是否仍保存旧页面；
- HTTPS 回源的 SNI、Host 请求头是否正确；
- 是否有旧规则只对部分路径或地区生效。
如果 DNS 已正确指向 CDN，但 CDN 仍回源旧服务器，继续刷新本机 DNS 不会解决问题。
第六步：用 curl 直接测试新旧源站
curl --resolve 可以临时指定域名连接到某个 IP，同时保留正确的 Host 和 HTTPS SNI，适合绕过 DNS 直接检查源站：
curl -I --resolve example.com:443:203.0.113.20 https://example.com/
curl -I --resolve example.com:443:198.51.100.10 https://example.com/
第一条填新服务器 IP，第二条填旧服务器 IP。这样可以确认：
- 新服务器是否已经部署完整内容；
- HTTPS 证书和虚拟主机是否正常；
- 新旧服务器返回的响应头是否能区分；
- 问题究竟在 DNS/CDN 链路，还是新源站本身。
如果新 IP 直连正常，而域名访问仍到旧内容，就继续查 DNS、代理和 CDN；如果新 IP 直连也显示旧内容，则应检查新服务器上的站点目录、缓存插件、反向代理或数据库连接。
一套不容易出错的迁移顺序
正式迁移时，可以按下面的顺序执行：
- 提前降低旧 DNS 记录的 TTL；
- 在新服务器完成文件、数据库、证书和重定向测试；
- 给新旧源站增加可识别的响应标记；
- 切换
A、AAAA、CNAME及 CDN 回源配置； - 从多个公共 DNS、地区和网络查询结果；
- 检查新服务器日志中的真实访问量是否持续增加；
- 继续保持旧服务器可用，并避免旧站产生新的写入；
- 确认主要流量全部进入新服务器后，再下线旧环境。
对于有订单、会员、评论或后台写入的网站，迁移窗口还要处理数据一致性。常见做法是临时维护、冻结旧站写入，或者在切换前执行最后一次数据库增量同步。否则即使 DNS 已完全生效，也可能出现部分订单留在旧数据库的问题。
排查结果如何快速归因
- 权威 DNS 返回旧 IP：修改权威记录或检查是否改错 DNS 服务商；
- 权威 DNS 返回新 IP，部分递归 DNS 返回旧 IP：等待 TTL 到期，并保留旧服务器；
- DNS 全部返回新 IP，但页面仍旧：检查 CDN、页面缓存和新服务器内容；
- 只有一台电脑异常：检查 Hosts、本机 DNS、浏览器、代理和 VPN；
- 只有 IPv6 网络异常：检查
AAAA记录和新服务器 IPv6 配置； - 只有部分路径异常：检查 CDN 缓存规则、反向代理和应用缓存；
- 新旧服务器都收到写请求：立即处理数据同步，避免继续产生分叉数据。
网站迁移后的 DNS 问题，最怕靠“再等一会儿”来猜。把权威解析、递归缓存、本机解析、CDN 回源和源站响应逐层拆开，就能明确是哪一层仍保留旧地址，也能判断旧服务器什么时候可以真正释放。
参考资料
- Cloudflare Docs：DNS records – TTL
- Google for Developers：Flush Cache（Google Public DNS）
- Microsoft Learn：ipconfig 命令说明
资料核验日期：2026年9月21日。