计划晚上切换CDN，切换前一分钟才把DNS TTL改短，能否让所有用户立即走新入口？不能这样保证。已经缓存旧回答的解析路径，未必会因权威端刚修改TTL就提前重新查询。迁移方案应考虑旧缓存仍然存在的阶段。
TTL是缓存信息，不是远程清除按钮
Cloudflare的TTL文档说明，TTL影响记录缓存与变更到达用户的时间，并提醒本地缓存也可能影响实际观察。不同DNS产品对可设范围和代理记录有各自限制，应核对当前服务规则。
降低权威回答中的TTL，主要影响之后取得该回答的缓存。已经保存的记录仍需按其状态处理，所以调整应安排在迁移准备阶段，而不是把它当成故障发生后的立即切流工具。
安排四个阶段
| 阶段 | 要完成的动作 | 进入下一阶段的证据 |
|---|---|---|
| 准备 | 记录旧值，按需求提前调整TTL | 权威已发布，代表解析路径得到预期值 |
| 预验证 | 检查新入口证书、路由和业务 | 新路径具备接流条件 |
| 切换 | 变更目标并观察新旧访问 | 关键业务正常、异常有明确范围 |
| 收尾 | 确认旧入口退役条件并恢复合适TTL | 遗留访问已调查，回退安排结束 |
表格没有给出固定分钟数，因为等待时间应结合原TTL、别名链、用户环境和业务要求确定。迁移中涉及NS或DNSSEC变化时，还要单独处理对应依赖。
新旧入口并存时确保业务一致
迁移窗口内，有的用户可能走新CDN，有的仍走旧入口。两者的证书、登录、回源和内容版本应满足同一业务要求。不能只验证新入口，再立即关闭旧入口造成仍使用旧缓存的用户失败。
涉及写入业务时，还要确认两条路径连接到正确的数据系统。切流不是数据迁移方案，不能让新旧入口各自产生无法对账的独立状态。
回滚也要接受缓存现实
把DNS改回旧值之后，并非所有用户马上回到旧路径。因此回滚需要检查新入口是否仍能安全处理残余访问，必要时采用应用或平台支持的恢复方式，而不是只修改一次记录就宣布完成。
记录触发回滚的具体条件、操作人和观察方法。若失败原因在源站或共享依赖，单纯回到旧CDN可能没有帮助，应先确认回滚针对的是哪一类问题。
如何判断可以关闭旧入口
结合访问日志、业务监控和已知客户端行为确认遗留访问来源。少量持续访问可能来自写死地址、独立解析器或旧集成，应逐一识别，而不是无限期保留未知入口。
最终保存变更时间线、权威与递归样本、业务测试及退役记录。可将这些内容并入边缘灰度上线流程。使用安全加速SCDN时，提前确定切换和回滚能力，有助于让DNS变更与实际接流节奏一致。
资料核对日期：2026年10月30日。本文由AI辅助整理，技术事实依据文内原始资料核对。示例与操作清单供实施参考；产品配置和软件维护状态以实施时的官方资料为准。
涉及漏洞与安全事件的文章，请结合文中来源、发布时间和厂商最新公告核对。产品配置与防护效果以实际业务验证为准；资料纠错可联系 support@waf.pro。
