防护服务已经切换，部分访问者却仍到达旧目标，往往不是新记录没有生效，而是查询链路上仍有人使用缓存答案。处理DNS解析缓存导致防护切换延迟的解决办法，要先找到缓存所在层，再判断 TTL 是否到期；盲目反复修改记录，反而可能让排查更复杂。
先分清哪些环节会缓存
域名解析通常经过权威 DNS、递归解析器，再到操作系统或应用自身的缓存。浏览器或应用可能复用已有解析结果；企业网络、公共递归服务也可能各自保留缓存。因此，同一时刻不同设备解析到不同目标，并不一定代表权威记录配置错误。
TTL 是记录建议缓存的时间，单位为秒。例如 TTL 为 300，递归解析器通常可在约 5 分钟内继续使用该答案；但客户端缓存策略、解析器的缓存上限或“过期后继续提供旧答案”等行为，可能使实际切换更久。TTL 不是全网统一刷新倒计时，也不能保证每个用户在到点瞬间更新。
按解析链路定位旧答案
- 检查权威记录。在 DNS 管理平台核对记录名称、类型、目标值和 TTL，并确认变更已保存。A、AAAA、CNAME 记录不要混为一谈。
- 从不同递归解析器查询。使用 dig 或 nslookup 分别查询域名，记录返回结果和 TTL。也可通过网络环境不同的设备复核；若权威查询已是新值而递归结果仍旧，优先等待对应缓存到期。
- 逐段核对 CNAME。如果域名指向别名，沿着每一段别名继续查询。链路中的每条记录都有自己的 TTL，最终目标的旧答案也可能被缓存；只缩短最前端记录未必足够。
- 检查缓存与负缓存。本机可清理操作系统 DNS 缓存，关闭并重开相关应用后复测。若之前查询时域名不存在，递归解析器还可能依据权威区的 SOA 信息缓存“无此记录”的结果，需留出负缓存时间。
- 记录验证时间和结果。分别保存权威查询、递归查询和客户端复测结果。这样能区分配置未生效、缓存未到期，以及应用仍复用旧连接或旧解析结果。
切换前降低等待风险
提前调低 TTL
计划中的切换应先降低相关记录 TTL，再等待原有较长 TTL 走完，之后才改目标。许多管理平台允许设置几十秒至数百秒的 TTL，但实际可选范围取决于 DNS 服务商；常见的 60 至 300 秒可作为评估区间，并非所有场景都适用。切换稳定后，可恢复较长 TTL，减少重复查询。
安排变更顺序
先确认新防护目标已准备好并能正常响应，再修改 DNS 记录。若有多层 CNAME，应先检查整条链路及各层 TTL。切换时保留旧目标一段观察期，有助于承接仍持有旧缓存的请求；具体时长应结合原 TTL、业务容忍度和服务端安排确定。
切换后仍不一致时怎么处理
如果少数设备仍解析到旧目标，先比较它们使用的递归解析器和记录 TTL，不要频繁改回再改新。若权威记录本身不正确，修正后重新核对；若只有本机异常，可清理本机缓存。外部递归解析器的缓存通常无法由域名所有者远程清除，只能等待其缓存策略更新。
在 DNS 记录更新后，部分连接还可能沿用已有会话，解析刷新不一定会立即中断并重建连接。应分别检查新解析结果和新建连接的实际去向，避免把连接复用误判为 DNS 未切换。采用托管 DNS 或防护平台的自动切换功能时，也要确认其健康检查、切换条件及回切规则；这些功能不能消除客户端缓存。
总体上，DNS解析缓存导致防护切换延迟的解决办法不是单纯把 TTL 设到最低，而是提前降 TTL、逐层核对解析链路，并为缓存到期和客户端复测留出窗口。需要应急切换时，先验证权威答案，再按递归解析器和终端逐步定位，通常比反复编辑记录更有效。
常见问题
改完记录后，多久能切换完成？
没有统一时长。可先参考变更前的 TTL，再考虑解析器和客户端缓存策略；查询结果与实际连接也应分别验证。
把 TTL 改成 60 秒，旧缓存会立即消失吗？
不会。新 TTL 主要影响后续获取的记录，已经缓存的旧答案通常要等原有缓存时间到期。
清理自己电脑的 DNS 缓存能解决所有用户的问题吗？
不能。它只影响本机缓存，无法清除运营商、企业网络或公共递归解析器中的缓存。
为什么 CNAME 改了，访问仍像是旧目标？
别名链后续记录可能仍有缓存，客户端也可能复用已有连接。应逐段查询 CNAME，并测试新建连接的访问结果。