子域名解析：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /548559628091.html
📄
子域名解析：多层缓存返回不同版本时怎样定位一致性问题
先承认一个事实：多层缓存返回不同版本，通常不是解析本身出错，而是不同缓存层对同一名称保存了不同时间的应答。要定位一致性，先固定观察点：从权威解析、递归缓存、本地缓存三层分别取结果，比较 TTL 剩余值和记录内容，而不是只看浏览器最终显示的那一个版本。
先分清三种不一致，再决定保留还是改写
多层缓存场景下，不一致大致分三类。第一类是记录内容不同，比如 A 记录指向不同 IP；第二类是记录类型不同，比如一处返回 CNAME、另一处返回 A；第三类是内容相同但 TTL 剩余差异很大。三类问题的处理方向完全不同。
如果只有 TTL 剩余不同、内容一致，通常属于正常的缓存衰减，不需要改写权威记录，等待过期即可。如果内容不同，才需要判断是权威侧被改过、还是某层缓存保留了旧应答。这个判断会直接影响下一步：是继续等，还是立即处理。
用固定观察点取三层结果，而不是反复刷新
反复刷新同一个客户端，只会命中同一层缓存，拿不到可比较的证据。更有效的动作是选三个固定观察点：
- 直接向该子域名的权威服务器查询，看当前真实发布内容；
- 向一个你无法控制的公共递归解析器查询，看它缓存了什么；
- 在受影响客户端本地查询，看本机或本地网络缓存保留了什么。
把三处结果并排记录，包括记录内容、TTL 剩余、查询时间。这个动作的结果会告诉你不一致发生在哪一层：三层都不同，问题多半在发布流程；只有本地不同，问题在客户端或本地网络；权威与递归不同，问题在递归缓存的过期节奏。
权威侧刚改过时，保留旧缓存往往是更稳的选择
如果确认权威记录最近被修改，而递归缓存仍返回旧值，先判断旧值是否仍在正常服务。假设一个场景：某子域名从旧 IP 切到新 IP，旧 IP 仍能响应一段时间。此时保留旧缓存、让 TTL 自然过期，比强制清缓存更稳，因为强制清理可能让部分客户端在新旧之间反复切换。
适用前提是旧值仍可用、且切换窗口可以接受。若旧值已经停止服务，保留就不再成立，必须转向缩短 TTL、修正权威发布，并接受一段时间的混合返回。
本地缓存造成的假象，不要用权威侧改动去修
如果权威和公共递归返回一致，只有本地客户端不同，那么改权威记录不会解决本地问题，反而可能引入新的不一致。此时应把范围收窄到本地解析缓存、操作系统缓存或本地网络设备。
一个可区分的证据是：同一网络下不同设备结果是否一致。若只有单台设备异常，问题在本机；若整个本地网络一致异常，问题在本地出口设备。这个区分决定了你接下来是清理本机缓存，还是检查本地网络设备。
退出旧记录前，先确认没有依赖它的服务
当决定彻底退出旧记录时，前提是确认没有其他服务仍依赖旧值。检查方式不是看解析结果，而是看依赖该子域名的调用方是否已经切换。若无法确认，贸然退出会让部分请求落到已失效地址。
可执行的动作是：先保留旧记录但降低其权重或优先级，观察一段时间内是否还有请求命中旧值；确认没有后再移除。这个动作的结果决定了退出是否可以立即执行，还是需要延长观察窗口。
需要注意，抓取限制、站点地图提交或启用 HTTPS 都不能替代对解析一致性的判断，它们解决的是不同层面的问题。定位多层缓存不一致，核心始终是分层取样、比较内容和 TTL，再根据不一致发生在哪一层决定保留、改写还是退出。
