DNS改记录后仍访问旧站：逐层定位缓存与权威解析差异

🌐 DNS改记录后仍访问旧站：定位缓存与流量路径

域名记录更新后仍看到旧站，不能简单归因于“全球DNS还没刷新”。域名解析会经过权威DNS、递归解析器、操作系统和浏览器等层次；随后请求还可能经过代理、CDN、负载均衡或应用缓存。解析到旧地址与解析到新地址却返回旧内容是两类故障，诊断时应先区分。

🧭 解析层：从权威记录向客户端比较

先确认实际访问的完整主机名和记录类型，例如根域名与www.example.test可能由不同记录控制。查询权威DNS，核对答案、TTL、记录目标及托管区；再查询递归解析器。如果权威答案仍是旧值，重点检查修改是否落在正确DNS服务和记录名上。如果权威已新、递归仍旧，则缓存是首要方向。

1. 权威端：查权威服务器返回的地址和TTL，确认变更已发布。
2. 递归端：比较不同解析器的答案；剩余TTL不断下降且地址未变，符合缓存行为。
3. 客户端：换网络、清理本机解析缓存或使用另一台设备复测，避免把单机现象当作全网状态。

可用dig example.test A检查A记录，用dig example.test CNAME核对别名链。查询输出中的权威标志、应答记录和TTL应一起阅读；只看命令是否“成功”没有判断价值。🧩

🔬 连接层：绕过DNS确认新站行为

将域名固定到目标地址发起请求，可以保留HTTP Host与TLS SNI，同时跳过普通DNS解析。例如：curl -I --resolve example.test:443:203.0.113.10 https://example.test/。这里的文档示例地址需替换为实际目标。检查状态码、证书主体、响应头和页面版本标记。固定地址访问正常、普通访问异常，说明解析路径值得继续追；两者都返回旧页面，则转向代理缓存、虚拟主机、后端池或应用发布核验。

若浏览器仍显示旧页面，也要排除HTTP缓存、Service Worker和已复用连接。用新隐私窗口或命令行取证，并将请求时间、解析结果和响应标识对应起来。不要为了验证而清空所有缓存后失去原始证据；先保存查询结果和响应头。🔎

🛠️ 变更期间的操作顺序与误区

迁移前可提前调低TTL，让尚未过期的旧记录更快退出缓存；但已被递归器缓存的记录仍按原TTL存活。切换时先确认新站能以目标Host正确响应，再更新权威记录，并保留旧站一段过渡时间。对有多条A记录、CNAME链或不同线路策略的域名，逐条核对，避免只修改其中一个答案。

✅ 验收：覆盖解析、响应和时间

验收至少覆盖两个不同网络：记录权威答案、递归答案及TTL；固定目标地址请求应命中新站，普通域名请求在缓存过期后也应命中新站。核对证书、状态码和可辨识的版本标记，并重复查询确认结果稳定。只有解析答案和实际页面都符合预期，才算迁移验证完成。保留变更前后输出，发生回退时可据此判断是缓存延迟还是服务端路径仍指向旧环境。