域名已经改到新地址，部分用户却仍访问旧服务器，先检查记录与缓存的层次。DNS 托管平台显示保存成功，不代表每个递归解析器都已更新；反过来，不同地区返回不同地址，也可能是正常的线路调度。
记录实际访问的完整主机名、修改时间、记录类型和原 TTL。根域名与 www 子域名、A 与 AAAA 记录需要分别核对，别只改了 IPv4，就忽略仍指向旧入口的 IPv6。
Windows 可用 nslookup 查询 NS，再向对应权威服务器查询。下面是格式示例：将域名以及 ns1.example.net 换成真实查询结果中的权威服务器；它不是通用 DNS 地址。
nslookup -type=NS example.com
nslookup -type=A www.example.com ns1.example.net
存在子域委派时，应使用负责该子域的权威服务器。若不同权威服务器仍提供不一致的记录，先核对 DNS 托管和同步状态；此时只等待用户缓存到期并不能修正权威配置。
权威数据正确后，在 FB4 的 DNS 查询中选择同一个主机名和记录类型，分别查看运营商 DNS 与指定 DNS 的结果，记录查询时间及返回地址。需要观察 TTL 时，再用支持显示详细记录的 DNS 工具查询；不要把界面没有显示的字段当成零。
TTL 以秒计，是缓存使用记录的重要时间依据。提前降低 TTL 可以缩短之后的切换窗口，但已经缓存的旧记录不会因为后台刚改小 TTL 就立即收到通知。迁移前应预留原缓存的消退时间，迁移后再按实际查询结果复测。
如果曾经查询到域名不存在，后来才补上记录，递归解析器还可能保留负缓存。它与正常 A 记录缓存不同，需要结合权威回复中的 SOA 信息和负缓存时间判断。此时不断删除、重建记录，反而会增加排查难度。
使用 CDN 时，多个返回地址不必然异常；应按 DNS 服务商的调度设计判断。若解析已经正确而浏览器仍访问旧入口，再查看浏览器连接复用、代理及 HTTP 缓存，最后验证实际网页和证书。提交问题时整理“哪个解析器、何时、返回什么”，比只说“还没生效”更容易定位。
参考：DNS 记录与 TTL https://www.rfc-editor.org/rfc/rfc1034.html
负缓存 https://www.rfc-editor.org/rfc/rfc2308.html
Windows nslookup https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nslookup
