凌晨将业务从 10.20.30.40 切到 10.20.30.41 后，新地址正常，旧地址却持续 15 分钟收到数百次访问；用户刷新甚至更换浏览器，仍被导向旧入口。权威 DNS 已更新，不等于递归缓存、旧连接和客户端地址会同时失效。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：liteserver（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
旧地址为何仍在：切换不等于清缓存
权威节点切换只改变后续查询答案，不会向问过域名的递归服务器发送清缓存指令。递归缓存按 TTL 保留旧 A、AAAA 或 CNAME，解析缓存寿命从上次响应起计时，并非切流时重置；运营商递归、区域解析器与终端缓存还会叠加。
最容易漏掉的是负缓存机制。灰度时若新域名返回 NXDOMAIN，或权威节点摘除后返回空结果，递归服务器会按 SOA 的负缓存 TTL 继续回答“不存在”，使刚修复的解析仍然失败。
旧访问也不一定来自 DNS。既有 TCP/TLS 连接、固定地址、兜底 IP 和负载均衡器残留后端都会命中旧入口。排查时应记录 DNS 答案、实际连接对端与连接开始时间；TTL 到期后部分解析器还会短暂返回过期答案，递归缓存残留必须用请求证据确认。
先判来源，再定灰度与回滚
先盘点缓存，再灰度切流。记录各域名的 TTL、A/AAAA/CNAME 链、SOA 最小值和通配符配置，从公司网络、公共递归及异地节点查询旧答案剩余寿命。用于拨测的随身服务器可持续探测新旧入口，但它只代表一个视角。
缩短 TTL 前确认下游能承受更短缓存，避免解析风暴；再按 1%、5%、20% 扩大新入口比例，并保留旧节点。每级观察覆盖多个 TTL 周期，比较新旧 IP 的 QPS、成功率、5xx 与延迟，不能凭单个峰值放量。
回滚要看持续阈值，不看单次抖动。例如，连续三个 5 分钟窗口旧 IP 占比仍高于 5%，且错误率超过基线，应回切权威记录并恢复旧节点。若旧流量下降而错误不降，根因可能是连接池、后端摘除或证书；回滚后仍要等待残留 TTL 衰减。
持续观测应记录解析器、返回地址、实际连接 IP 和耗时，再按地域统计旧地址命中率与切流收敛时间。当旧流量回到基线、多个递归视角均返回新地址，且连续两个观察窗没有旧连接，才可判定收敛；每次 TTL 变更都应留存时间点。
排空时间为何会超过 TTL
旧缓存分散在权威节点、递归解析器、操作系统及业务自建 DNS 中，各层剩余寿命并不一致。部分解析器还会按 RFC 8767 暂用过期答案，导致旧地址在 TTL 到期后仍短暂出现。排空时间不能只按一个 TTL 估算，而应取各层剩余时间的最大值；若旧记录是负缓存，失效后重新查询并缓存新答案，还需串联计算负缓存与新正缓存的寿命。
常见遗漏包括 AAAA、CNAME、NS 记录 以及仅表示“域名存在但没有该类型”的 NODATA。CNAME 链每一层都有独立 TTL，只调整最终 A 记录无法完整排空。删除记录时，递归端还可能依据 SOA 的 TTL 与 MINIMUM 缓存 NXDOMAIN；提前测试或灰度失败留下的负缓存，同样会影响切换结果。
可执行的排空与验收清单
先盘点全部权威节点、托管商和记录类型，以旧 TTL 最大值为基准，至少提前一个完整周期将正、负缓存 TTL 降至 60～300 秒，确认主从同步并递增 SOA serial。随后逐层核对 A、AAAA、CNAME 和不存在域名的响应，避免用本机结果代表公网状态。
切换后使用 dig @1.1.1.1 example.com A 等命令，从多个运营商、地域及真实客户端验证 TTL 和目标地址，同时持续观察旧 IP 的请求量、连接数、错误率及回源比例。旧节点应保持健康，直到旧流量稳定降至阈值以下，并保留可快速回切的配置。
容易踩的坑包括：只修改 A 记录；在旧缓存尚未排空时直接停机；误以为 TTL=0 可以强制所有客户端刷新；只在单台机器执行清缓存命令；把 HTTP、CDN 缓存或长连接误判为 DNS 问题。DNS 失效也不会终止既有 TCP、TLS、QUIC 连接，必须配合优雅下线与连接排空。观察一个完整收敛周期后，再逐项恢复合理 TTL，过早调高会制造新的长缓存。
最终应确认权威结果一致、公网递归结果正确、旧 IP 流量持续下降、负缓存不再复现，并且监控、告警和回滚方案均已就绪。满足这些条件，才意味着 切流收敛时间 已经得到验证，而不只是配置发布完成。
喜欢 
顶
难过
囧
围观
无聊
