防护网络切换期间避免域名解析中断的操作，重点不在于一次性把域名指向新服务，而在于让旧链路在解析缓存逐步更新时继续可用。先盘点域名、证书和源站配置，再测试新链路，最后分阶段迁流；这样既能减少访问失败，也能把新旧服务重叠产生的费用控制在必要范围内。
先确认切换边界，别把解析和防护配置混为一谈
列出需要迁移的主机名，例如网站的 www 子域名、API 子域名及邮件相关记录。标明每条记录目前由谁管理、指向哪里、TTL（缓存有效时间）是多少，以及是否经过代理或防护节点。邮件记录通常不应随网站流量一起改动；只切换网站业务时，避免误改 MX、SPF 等邮件配置。
同时核对新防护网络所需的源站地址、证书、访问控制规则和健康检查条件。若业务使用 CNAME，确认目标域名及其解析链可正常工作；根域名是否支持直接使用 CNAME，取决于权威 DNS 服务商提供的具体机制，不要照搬其他平台的设置。
按顺序迁移：测试、降低缓存影响、分阶段切换
- 准备配置副本。保存现有解析记录、代理模式、证书信息和关键规则。记录旧服务的续费周期及取消条件，避免迁移完成前误停服务。
- 先搭好新链路。在不改变正式域名解析的前提下，按新服务商要求配置源站和防护策略。通过测试域名或供应商提供的验证方式检查首页、登录、文件上传、API 等关键路径，并确认异常时能查到请求日志。
- 提前调整 TTL。若计划修改记录，可在切换前至少经过当前 TTL 的一个有效周期后再操作；具体等待时间还要考虑递归解析器的缓存行为。把 TTL 调低并不能立即清除已有缓存，因此不要把它当作即时切流开关。切换稳定后，再将 TTL 调回适合日常运维的值。
- 小范围验证，再扩大流量。支持加权解析的服务可先给新链路少量权重，再逐步提高；例如 Amazon Route 53 提供加权路由功能，但可用方式取决于记录类型和配置。若服务不支持权重，可先切一个低风险子域名，验证无误后再改主要业务记录。
- 观察并准备回退。持续查看新旧两侧的请求错误、延迟和源站负载。出现明显异常时，将解析恢复到旧目标，并保留旧防护配置，直到缓存与业务表现稳定。回滚可能不会对所有用户同时生效，因为解析缓存更新时间不同。
控制迁移成本：把重叠运行设成有期限的安排
新旧服务短期并行通常能降低切换风险，但并行越久，固定套餐、流量计费和额外运维投入越可能叠加。迁移前先确认计费是按月、按量还是有最低使用期，再估算测试流量和正式流量分别会产生哪些费用；各服务商的计费规则不同，应以合同和控制台显示为准。
可以把并行期分成验证期和观察期：前者用于测试配置与业务功能，后者用于确认解析缓存更新后没有持续异常。设定明确的结束条件，例如主要业务路径通过检查、错误率回到团队认可的范围、旧链路已不再承接有效请求。达到条件后再按合同规则停止旧服务，不要仅凭某一台电脑访问正常就立即退订。
因此，防护网络切换期间避免域名解析中断的操作，实际上是用有限的重叠成本换取可验证的迁移过程。提前排查配置、控制流量比例、设置回滚期限，通常比临时故障后同时排查解析与防护规则更省时间，也更容易限制额外支出。
常见问题
降低 TTL 后，所有用户会立刻访问新服务吗？
不会。已有缓存可能仍按先前的有效时间保留记录，递归解析器的处理也可能不同，因此应预留更新和观察时间。
切换期间可以关闭旧防护网络吗？
不建议在主要解析缓存尚未更新、回滚方案尚未验证时关闭。先确认旧链路已无实际流量，再依照服务合同安排停用。
如何判断可以结束双边运行？
检查关键业务路径、新服务日志和旧链路流量，并确认异常时能够回退。观察周期应结合 TTL、业务访问规律和服务商计费周期确定。