CNAME 已经改对，网站却仍然打不开，这类情况并不矛盾。DNS 控制台显示的是配置意图，用户真正拿到的是经过递归缓存、网络路径和浏览器处理后的结果。CNAME 切换必须同时验证解析是否生效、请求是否进入新链路、ZuCDN 是否能够回源，以及关键业务是否保持正常。
下面的清单以时间线组织。执行人可以逐项勾选，也可以把结果写入变更记录。ZuCDN 控制台中的目标地址、配置状态和字段名称应以实际界面为准，本文不假设控制台一定提供某个特定选项。
切换前一日，冻结变量
正式变更前应尽量减少无关变化。不要在同一个窗口同时迁移源站、升级 WordPress、更新证书、修改防火墙并切换 CNAME。多个变量一起变化时，即使发现故障，也很难迅速定位责任环节。
- 确认 ZuCDN 中的加速域名和待切换域名完全一致。
- 确认配置已经保存或发布，状态没有明显错误或待处理提示。
- 确认源站地址、协议、端口和回源 Host 与预案一致。
- 确认 HTTPS 所需证书处于有效状态，覆盖待切换的域名。
- 确认源站从预期链路可访问，防火墙和安全组没有阻断回源。
- 导出现有 DNS 记录，至少保存记录类型、主机记录、记录值、TTL 和代理状态。
- 记录切换负责人、观察人、回滚负责人和沟通渠道。
若计划降低 TTL，应提前至少一个原 TTL 周期修改。例如原 TTL 很长，只在切换前几分钟调低，并不能让已经缓存旧记录的递归服务器立刻更新。TTL 调整本身也属于变更，需要记录原值，稳定后再决定是否恢复。
建立切换前基线
基线不是截图首页。它应包含可比较的状态码、响应头、证书和内容特征。至少准备首页、文章页、静态资源、登录入口、一个不存在的地址以及业务实际依赖的接口。对可能产生写操作的接口，只能使用专门的测试账户和测试数据。
以下命令适用于安装了 curl 的 Linux、macOS 或 Windows 环境，作用是只读获取响应头和连接信息。风险在于目标地址会收到真实请求，不能把带删除、支付、提交等副作用的 URL 用作测试。验证完成后没有本地改动，无需回滚。
curl -I https://www.example.com/
curl -I https://www.example.com/example.css
curl -I https://www.example.com/not-found-check保存每个地址的状态码、Location、Content-Type 和缓存相关响应头，但不要仅凭某一个头部判断请求必然经过 ZuCDN，因为实际响应头取决于产品配置和当前实现。更可靠的方法是把 DNS 结果、控制台状态、源站日志和客户端请求表现结合起来判断。
切换前十分钟，做放行检查
- 确认监控没有既有告警，源站 CPU、内存、连接数和错误率处于团队认可的正常范围。
- 确认 DNS 控制台账号能够登录，修改权限正常，并准备好二次验证方式。
- 复制 ZuCDN 实际提供的 CNAME 目标值，避免手工输入造成拼写错误。
- 检查同一主机记录下是否存在与 CNAME 冲突的 A、AAAA 或其他记录。
- 通知相关人员进入观察状态，暂缓可能影响结论的发布。
- 再次读取原记录并与回滚脚本或操作单比较，确保恢复值没有写错。
这里应设置明确的停止条件。若源站在切换前已经异常、证书临近失效、目标 CNAME 无法解析，或者负责回滚的人不在线，应暂停变更，而不是依赖切换后再观察。
执行切换，只改计划中的记录
在 DNS 服务商控制台中，将指定主机记录按 ZuCDN 实际要求修改为对应 CNAME。根域名能否设置 CNAME 或等效记录由 DNS 服务商能力决定，应遵循其说明，不能强行删除必要记录。修改后立即保存变更编号、操作时间和新值。
不要同时删除其他看似无关的 TXT、MX 或验证记录。尤其是邮件、证书验证和第三方服务记录，它们可能与网站访问无关，却承担独立业务。变更单限定哪一条，就只操作哪一条。
切换后零到五分钟，验证权威答案
先查询权威 DNS，而不是马上反复刷新浏览器。以下命令适用于安装了 dig 的 Linux 或 macOS。第一条查询权威服务器名称，第二条需要把 ns1.dns-provider.example 替换为实际权威服务器。作用是确认权威区域已经返回新 CNAME。查询只读、风险低，不修改系统，无需回滚。
dig example.com NS +short
dig @ns1.dns-provider.example www.example.com CNAME +noall +answer验证时检查记录名称、类型、目标值和 TTL。目标尾部是否显示点号通常只是 DNS 完整域名的表示形式，不应擅自删改。若权威服务器仍返回旧值，应回到 DNS 控制台检查记录是否保存到正确区域、主机记录是否正确，以及服务商是否仍在处理变更。
切换后五到三十分钟，观察递归传播
权威答案正确，不代表所有用户已经收到新记录。可以分别查询本地解析器和可信公共解析器，比较结果，但不要把某一家公共 DNS 的返回当成全球状态。
以下命令同样适用于 dig 环境，作用是比较系统默认解析器与两个公共递归解析器的 CNAME 结果。风险是查询会发送给对应 DNS 服务；如果组织政策禁止使用外部解析器，应跳过外部查询并使用批准的企业 DNS。命令不修改配置，无需回滚。
dig www.example.com CNAME +short
dig @1.1.1.1 www.example.com CNAME +short
dig @8.8.8.8 www.example.com CNAME +short若不同解析器结果不一致，应结合 TTL 判断是否处于正常传播期。不要通过连续清理所有用户设备缓存来掩盖问题。必要时可以在受控测试机上刷新本地 DNS 缓存，但不同系统命令和影响范围不同，生产办公环境应遵循组织运维规范。
切换后立即验证 HTTPS 和页面
浏览器能够打开首页只是最低门槛。应检查证书域名、有效期、证书链、HTTP 到 HTTPS 的跳转，以及关键页面是否出现循环重定向。还要确认静态资源没有混合内容、跨域或 403 问题。
下面的 OpenSSL 命令适用于安装了 OpenSSL 的 Linux 或 macOS 环境，作用是读取目标站点实际返回的证书摘要。它只建立 TLS 连接，不修改服务。风险是输出可能包含域名和证书元数据，向外部提交日志前应脱敏。验证完成无需回滚。
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName检查有效期是否覆盖当前时间，Subject Alternative Name 是否包含访问域名，颁发者与证书链是否符合预期。如果命令失败，应分别排查 DNS、TCP 443 端口、SNI 和证书部署，不能直接归因于缓存。
从用户路径逐项验收
- 首页和内容页返回预期状态码，正文没有被替换成源站默认页。
- CSS、JavaScript、图片和字体能够加载，浏览器开发者工具没有大量 4xx 或 5xx。
- 登录页能够建立会话，后台操作使用测试账户验证，避免影响真实内容。
- 不存在的路径保持预期的 404 行为，没有被错误改写到首页。
- HTTP、HTTPS、带 www 和不带 www 的跳转符合站点原有设计，没有来回跳转。
- 接口响应格式、跨域头和鉴权行为符合业务预期。
- 源站访问日志中能够看到测试请求，状态码和 Host 正确。
传播期内，区分缓存问题和配置问题
部分网络正常、部分网络仍访问旧地址，通常先查看 DNS 结果和 TTL。所有网络都解析到新目标但统一返回 502、504 或连接失败，则更应检查回源地址、端口、协议和访问控制。只有某些路径异常时，应查看路径规则、源站重写、权限或应用行为。
页面内容旧也不一定是 DNS 缓存。浏览器缓存、站点缓存、代理缓存和应用生成结果都可能参与。排查时应保留响应头和时间点，使用唯一的只读测试 URL 或已知更新内容进行比较，不要靠不断发布新文章验证。
这些错误最常见
- CNAME 主机记录填成完整域名后，DNS 服务商又自动追加区域名，形成错误名称。
- 复制目标值时带入空格、协议前缀或路径，而 CNAME 只接受域名目标。
- 旧 AAAA 记录未处理，导致支持 IPv6 的客户端仍走旧链路。
- 源站按 Host 区分虚拟主机，但回源 Host 与站点配置不一致。
- 源站强制 HTTPS，代理侧又按错误条件跳回 HTTP，形成重定向循环。
- 只验证自己的办公网络，没有观察外部递归 DNS 和真实监控。
什么时候应该回滚
回滚条件应在变更前约定。关键页面持续不可用、HTTPS 证书不匹配、回源错误无法在窗口内定位、登录或交易类核心流程异常，都可以成为回滚触发点。短暂的 DNS 结果不一致若符合 TTL 预期，不一定需要立即回滚，但要持续监控。
回滚时，把修改过的 DNS 记录恢复为已保存的原类型、原值和计划中的 TTL。不要凭记忆重新填写。恢复后查询权威 DNS 确认旧记录已返回，并继续观察递归缓存。由于一部分解析器可能仍缓存新 CNAME，ZuCDN 配置和源站放行不应立刻删除，应保留到传播窗口结束且确认没有流量依赖。
稳定后再关闭变更
在团队规定的观察周期内，持续查看可用性、状态码、源站负载、应用错误和用户反馈。确认稳定后，再恢复长期 TTL 策略、解除发布冻结并归档记录。归档内容应包括切换时间、DNS 前后值、各解析器验证结果、证书检查、业务验收、异常和处理过程。
CNAME 切换真正完成的标志，不是 DNS 控制台弹出保存成功，而是权威解析正确、主要递归网络逐步收敛、HTTPS 与业务路径通过验证，并且回滚通道仍然清晰可用。
延伸阅读