域名已经换到新服务器，执行 ipconfig /flushdns 后，浏览器仍然打开旧IP。继续清理本机缓存往往没有意义，因为DNS答案可能同时存在于权威服务器、递归DNS、操作系统和浏览器中；即使名称已经解析到新IP，浏览器还可能复用此前建立的HTTP/2或HTTP/3连接，CDN也可能继续返回旧缓存内容。
排查“DNS缓存清了还是旧IP”，第一步是确认你看到的究竟是旧的解析地址，还是新服务器返回了旧内容。
域名解析经过哪些缓存层
| 层级 | 它保存什么 | 本机flush是否能清掉 |
|---|---|---|
| 权威DNS | 站长实际配置的A、AAAA、CNAME等记录 | 不能 |
| 递归DNS | 根据TTL缓存权威答案 | 不能 |
| 路由器或企业DNS | 局域网查询结果或转发缓存 | 通常不能 |
| 操作系统 | 本机解析器缓存的正向和负向结果 | 可以清理 |
| 浏览器/应用 | 主机缓存、连接池和应用内部状态 | 不一定 |
| CDN/页面缓存 | HTTP响应内容，不是DNS答案 | 不能 |
ipconfig /flushdns只处理Windows DNS客户端缓存。它不会命令运营商DNS提前丢弃记录，也不会刷新CDN或浏览器已经建立的连接。
TTL应该看修改前还是修改后
递归DNS在拿到一条记录时，会按当时响应里的TTL开始倒计时。假设旧A记录的TTL是86400秒，递归DNS在切换前刚缓存过它；你切换IP后再把TTL改成300秒，那份已有缓存仍可能按原来的剩余时间保留旧答案。新的300秒只会影响之后重新获取的记录。
因此，计划迁移时要提前至少一个旧TTL周期降低TTL。比如旧值为24小时，可以提前一天以上降到300或600秒，等待各递归缓存自然到期后再切换IP。迁移稳定后再恢复到适合业务的值，避免长期产生不必要的权威查询压力。
先查权威DNS是否已经正确
- 确认域名使用的权威服务器。查看当前NS记录，排除注册商后台改了A记录，但域名实际委派给另一家DNS服务的情况。
- 直接向权威服务器查询。分别查看A、AAAA和CNAME，记录响应值、TTL及服务器名称。若多个权威节点答案不一致，先修复同步问题。
- 检查CNAME完整链。别名本身已更新，不代表最终目标的A/AAAA已更新；CDN提供商的解析层也可能决定最终地址。
- 检查负缓存。域名此前不存在时，递归DNS可能缓存NXDOMAIN。其时长与区域SOA相关，本机刷新同样无法清掉远端负缓存。
只有权威答案已经正确，“等待缓存”才有意义。若权威服务器仍返回旧IP，等待再久也不会自动切换。
比较不同递归DNS时要记录服务器
用运营商默认DNS和一到两个公共递归DNS分别查询，记录查询时间、服务器地址、返回记录和剩余TTL。不同递归结果短时间并存，是DNS缓存机制下可能出现的正常过渡；如果超过原TTL仍持续错误，就需要检查权威同步、DNS转发链或服务商异常。
不要只把多地工具上的城市名称截图下来。应确认工具查询的是哪个递归服务、是否使用IPv4或IPv6、是否跟随CNAME，以及结果是不是缓存。相关入口可以从极跃圈网址导航查找。
解析已经是新IP，页面为什么还像旧站
浏览器仍在复用旧连接
HTTP/2和HTTP/3允许一条连接承载多个请求。DNS变化后，现有标签页可能继续沿用已经连接的旧服务器。完全退出浏览器进程、重新打开后再查开发者工具里的远程地址，比只按F5更有价值。
CDN缓存还没有刷新
DNS已经把用户送到新CDN节点，但该节点的页面缓存仍是旧内容。DNS TTL与HTTP缓存时间是两套机制。此时要查CDN缓存命中状态、缓存键、刷新记录和回源地址。
新服务器部署了旧内容
迁移时文件、数据库、对象缓存或应用配置没有同步，访问新IP也会呈现旧页面。给新旧环境加一个内部可见的版本号，并核对两边访问日志，能比肉眼看首页更快区分。
IPv4与IPv6切到了不同服务器
A记录已经更新，AAAA仍指向旧环境时，双栈客户端可能优先访问IPv6。查询和日志都要同时检查两种地址。暂时删除AAAA之前应评估业务影响，不能把IPv6问题简单掩盖掉。
一条完整的诊断链
- 记录当前NS并直接查询所有权威服务器；
- 比较两个递归DNS的A、AAAA、CNAME和剩余TTL；
- 清理操作系统缓存并彻底退出浏览器；
- 用开发者工具或
curl确认实际连接IP、TLS证书、状态码和响应头； - 查看新旧服务器及CDN日志，确认请求最终落点；
- 在迁移窗口内保留旧服务器，直到旧TTL和业务观察期结束。
不要通过反复重启路由器、频繁切换DNS来掩盖证据。把权威答案、递归答案、客户端解析、实际连接地址和服务器日志按时间排好，就能确定旧IP停留在哪一层。
