解析结果已经指向新地址，页面却打不开，或首页正常、提交请求失败——这类问题说明只看 DNS 查询结果不足以判断切换是否成功。网站防护服务上线前的DNS切换演练清单，应同时覆盖记录变更、回源链路、真实请求和回滚验证，让团队知道故障会出现在哪里、如何处置。
先把切换边界和基线写清楚
演练前记录当前域名、记录类型、旧值、计划新值和修改人。检查根域名、www 子域名及实际使用的 API、静态资源域名；邮件相关记录通常不属于网站防护切换范围，不要顺手改动。若使用 CNAME，确认目标名称及其解析结果符合服务商提供的接入要求。
同时保存切换前的页面状态、关键路径、响应码和应用日志作为对照。提前确认管理后台权限、变更窗口、值班联系人，以及旧记录如何恢复。记录现状能避免出问题后凭记忆判断“原来应该是什么”。
解析正确之后，还要逐段验证回源
解析测试回答的是“域名返回了什么地址”，回源验证回答的是“防护节点能否连到源站并取得正确响应”。这两者不能互相替代。可使用 dig 或 nslookup 分别查询权威 DNS 与常用公共递归解析器；结果不一致时，先区分权威记录配置错误与递归缓存尚未更新。
随后从防护服务的接入检查或监控界面查看回源状态，并核对源站防火墙、访问控制列表是否允许防护节点按要求建立连接。还要检查源站使用的主机名、HTTPS 证书与 SNI 配置，以及健康检查路径是否确实返回预期结果。若有条件，可用 curl 的指定地址解析能力，将测试请求定向到目标 IP，同时保留原域名，以验证指定源站的实际响应。
按真实业务路径做演练
- 准备测试对象：选定可安全访问的页面、静态文件和一条低风险业务流程；确认测试不会重复扣款、发送通知或写入不可逆数据。
- 先测源站：在尚未切换公众解析时，针对新回源目标验证首页、关键路径、重定向和接口响应，记录状态码、耗时及应用日志。
- 执行小范围验证：按接入方案使用受控终端或测试域名访问新路径，核对页面内容、图片与脚本加载，并完成一次可恢复的读写流程。不要仅以浏览器能打开首页作为通过标准。
- 检查防护与访问日志：确认请求确实经过预期防护路径，源站收到的请求与日志记录合理；如访问被拦截，分辨是策略误拦、来源限制还是回源配置错误。
- 切换后复查：变更后分别从不同网络查询解析，并重复关键业务测试。缓存更新所需时间受记录设置、递归解析器和客户端缓存影响，不能据单台设备的结果推断所有用户都已切换。
设置明确的通过条件与回滚条件
演练前就约定判定标准，例如关键页面和接口均返回预期结果、错误率未明显高于切换前基线、回源检查持续正常、核心操作可以完成。具体阈值应根据站点已有监控和业务容忍度确定，不宜套用一个适用于所有网站的固定数字。
出现持续回源失败、关键功能异常、错误率明显上升或无法确认流量路径时，暂停继续扩大变更。按记录恢复旧配置，并持续查看解析结果与业务监控；部分递归解析器仍可能暂时保留旧答案，因此回滚后也要复测，不要把修改成功等同于用户侧已经恢复。
将结果整理成网站防护服务上线前的DNS切换演练清单，至少留存记录快照、测试路径、观察指标、责任人和回滚步骤。下一次变更时即可逐项复核，而不是临场猜测问题出在解析还是回源。
常见问题
只查询公共 DNS 能证明切换成功吗？
不能。查询结果只能说明该解析器当前返回的记录，不能证明防护节点能连接源站，也不能证明页面和业务请求正常。
为什么根域名和 www 要分开测？
它们可能配置为不同记录或经过不同跳转链路。一个正常不代表另一个也正常，应分别核对解析与页面行为。
回源检查通过，用户仍报错怎么办？
继续检查客户端实际解析结果、页面资源和接口请求、证书与重定向，并按时间对照防护日志、源站日志及应用监控。
回滚后是否马上所有人都访问旧地址？
不一定。不同递归解析器和客户端缓存更新时间可能不同，应结合多处解析结果和真实请求持续确认。