摘要

  • Cloudflare 明确记录了一种迁移情形：旧 SaaS 供应商配置精确主机名，新供应商只配通配主机名，改过 CNAME 后仍可能显示旧供应商内容。
  • 新供应商可以通过配置精确主机名处理这一优先级问题。完成主机名与证书验证、切换 DNS、确认实际流量进入新区域，然后再清理旧配置，才是一份可验收的交接。

迁移完成的邮件，顾客没收到

设想一家商户换了网站服务商。新合同已经签好，域名记录也改向了新服务。项目经理发出“迁移完成”的邮件，顾客打开熟悉的网址，看到的却还是旧页面。地址栏照样能建立加密连接，运维开始盯着 DNS，供应商各自展示配置截图。每张截图都可能是真的，顾客仍然走错门。

Cloudflare 的官方故障处理文档列出了这个具体组合：旧 SaaS 供应商配了精确的自定义主机名，新供应商配了通配主机名，较旧的配置仍可能获得优先级。因此，更新 CNAME 后出现旧内容，有一种原因就藏在这两份配置的精细程度里。

合同按日期换了人，系统按匹配规则排队。比较谁先签约、谁后收到付款，都找不到队头。

精确的旧门牌压过宽泛的新招牌

精确主机名可以理解为单独登记某一个地址，例如 mystore.example.com；通配配置则用一条较宽的规则覆盖一组地址。后者管理起来省事，却在这个交接场景里碰到了前者的优先权。

Cloudflare 的主机名优先级规则说明，当多个区域里存在同一主机名的代理记录时，只有一条记录控制区域设置和对应源站。适用条件下，精确匹配排在通配匹配之前。文档的例子也指出，旧式精确自定义主机名会压过新配置的通配主机名。

这笔交易的经营含义很小，也很硬：客户可以已经表达更换服务商的意图，实际承接请求的配置却还没有完成交接。负责改 DNS 的人完成了自己的动作，负责新平台入驻的人还得检查自己登记的究竟是哪一种匹配。

通配配置本身有管理价值。大量客户地址可以通过更少的配置来处理。问题出在把这种方便带入迁移时，默认它会替代每一条既有的精确记录。批量入口的省事，需要用逐个地址的验收来结账。

新供应商有一件具体的事可做

故障处理文档推荐让新供应商为客户配置精确主机名，替代通配方式；另一条路径是由账户的超级管理员联系 Cloudflare 支持，请求更新 SaaS 配置。

这给交接会议提供了比互相等待更有用的问题：新供应商是否已经登记这个确切地址？把现象一概归咎于旧供应商拒绝放人，会漏掉官方给出的直接修复方向。材料没有提供具体客户的配置清单、请求日志或中断成本；这些证据才能判断一次真实迁移卡在哪里、损失多少。

新服务商买到客户、部署好应用，还要取得正确的交付位置。客户支付的新服务只有接到真实请求才开始发挥作用。迁移验收若只收集“已创建”“已修改”的通知，就把最后一段交付留给了猜测。

两盏绿灯，另加一次真正的到达

Cloudflare 把主机名验证与证书验证分开。前者确认主机名可以在服务中启用，后者负责证书的签发与部署。配置指南要求用于生产流量时，两项状态都达到 active，而且 DNS 指向对应的 SaaS 目标。

只试一次 HTTPS 握手，还不足以验收新证书。Cloudflare 可能呈现另一张匹配的证书，使握手在新证书状态尚未达到 active 时也能成功。连接被加密，与新供应商的这张证书已经部署完毕，是两个需要分别核对的结果。

同样，备用源站显示 active，指南解释的含义是 Cloudflare 已准备向该 DNS 记录发送流量，实际是否指向正确源站仍须确认。把这项绿色状态当作顾客已经进入新应用的证据，会让验收提前一个环节结束。

技术字段不用塞满采购合同。验收至少应交出几个能对得上的事实：这个确切地址已在新供应商处启用，证书已就绪，DNS 目标正确，测试请求确实由新区域和预期应用处理。顾客需要的是最后一项带来的服务，前面的准备工作负责让它成立。

两家同时准备好，才能从容交棒

主机名验证与迁移说明允许同一个域名在多个 SaaS 供应商处同时拥有 active 的自定义主机名。预先验证一个已经使用 Cloudflare 的主机名，不会单凭这一动作把流量搬走。

文档建议先在新区域创建并完成主机名预验证，再通过 TXT 或委托验证让证书就绪；随后由客户修改 CNAME，确认流量已经转到新区域，旧供应商再删除其自定义主机名。这个普通交接流程，需要结合前述精确与通配优先级检查来执行。

重叠准备有实际好处。它让旧服务在新服务等待验证时仍有位置，也给客户留下核对目的地的机会。若采用改完 DNS 后才进行的实时主机名验证或自动 HTTP 证书验证，配置指南提醒，等待激活或证书完成期间可能出现短暂中断。

因此，清理旧记录的时点应跟随交付证据。过早清理会扔掉仍有用途的准备；一直不清理又让下一次排查面对更多历史配置。交接完成后有序收尾，比一开始就要求谁把门牌摘掉更可靠。

一次服务迁移可以保留原网址，却改变背后接待顾客的人。网址负责延续身份，配置决定当班者。顾客不会替项目团队研究这层分工；他只会记得商户换了系统之后，自己看到了什么。