解析结果经过多级缓存
一次域名访问的解析结果会依次经过「权威服务器 -> 递归服务器（公共或运营商 DNS）-> 操作系统缓存 -> 应用或浏览器缓存」。改完解析却「不生效」，绝大多数是某一级缓存还没过期。定位方法是看 dig 输出里的剩余 TTL：递减说明仍在缓存期内；清理顺序只能从本机到浏览器，递归层的缓存只能等过期。
基本信息
| 缓存层级 | 权威 TTL 到递归缓存、系统缓存、应用缓存 |
|---|---|
| 清理顺序 | 本机缓存、浏览器缓存，递归层不可直接清理 |
| 判断依据 | 响应中的剩余 TTL 递减说明仍处于缓存期 |
| 控制手段 | 变更前先调低 TTL，缩短切换窗口 |
| 常见误判 | 把递归缓存当成可以主动清理的对象 |
典型使用场景
- 解析切换后部分用户仍访问旧地址，确认缓存未过期
- 变更前把 TTL 调低，等旧记录过期再切，缩短生效时间
- 排查「本机查是新的、业务机器查是旧的」这类差异
- 容器或虚拟机内 DNS 配置与宿主机不一致，导致结果不同
- 应用内自建 DNS 缓存导致长连接指向旧地址
对照权威与递归结果
对照权威与递归结果
dig www.example.com +noall +answer # 看本机递归结果的剩余 TTL
dig +short www.example.com @8.8.8.8 # 对照公共 DNS 的结果
# 直接问权威服务器，绕过递归缓存
dig +short www.example.com @ns1.example.com
# 清本机缓存（systemd-resolved 环境）
sudo resolvectl flush-caches缓存层级与可控性
| 层级 | 谁在缓存 | 能否清理 |
|---|---|---|
| 权威服务器 | 记录的所有者 | 修改记录本身 |
| 递归服务器 | 公共或运营商 DNS | 不可直接清理 |
| 操作系统 | 本机 resolver | 可用命令清理 |
| 浏览器与应用 | 客户端进程 | 重启或刷新可清理 |
运营商与公共递归缓存无法直接清理，切换类变更要靠提前调低 TTL 来控制窗口，这是唯一可靠的手段。
变更前没有预降 TTL，等于把生效时间交给未知的递归缓存；遇到故障回滚时同样会被缓存拖慢。