摘要

  • Fastly 的无版本域名可以独立于服务版本管理。代码发布、域名关联和跨账户委派因此不再是同一项工作，但各自仍有验证与权限条件。
  • 客户能否更换运维团队，取决于谁能控制 DNS、完成证书证明、管理相关账户并安排流量去向，不能仅靠一份源码交付清单判断。
  • 自助委派并不适用于全部产品形态；经典域名和 Platform TLS 有不同限制。平台内换服务、跨账户交接和离开 Fastly，也不是同一种迁移。

交出后台，未必交出了入口

假设一家企业更换网站运维服务商。新团队已经拿到源码，能构建应用，也知道源站在哪里。采购部门据此认定交接接近结束。可如果网站面向公众的域名仍由另一套账户、DNS 权限和证书安排支配，新团队掌握的只是入口后面的设施。它能够修改应用，却未必能够让既有用户从熟悉的网址抵达这个应用。

这不是某宗 Fastly 客户纠纷的复述，而是一种可以从产品规则推演的交接难题。代码的可移交性与入口的可支配性，本来就不是同一件事。前者可以通过仓库和部署产物体现，后者涉及谁有资格证明域名控制、由哪个账户管理它，以及请求最终被交给哪项服务。运维外包越顺手，企业越容易把这些差别留到更换服务商时才讨论。

Fastly 的无版本域名把这条边界显露了出来。官方域名说明允许域名脱离某个具体服务版本管理：可以先把域名加入平台，暂不关联服务；也可以调整域名，而不必为此递增服务版本。过去绑定在一次发布里的工作，被拆成了可以分别安排的管理动作。

这种拆分的价值不只在于少做一次发布。客户可以先安排公共入口，再决定由哪套服务承接；应用团队也不必为了每次域名管理都改动部署版本。与此同时，一份只列“已交付最新版本”的验收单，会更明显地漏掉另一组仍然能够改变用户去向的权限。

自助委派改变了哪一方需要等待

Fastly 将传统形态称为经典域名。它们创建在服务配置内，与服务及服务版本关联，改变域名和服务的关系需要创建新版本。官方文档说明，这项经典功能仅面向在 2025 年 9 月 16 日之前创建账户的客户。域名如果被另一 Fastly 账户的服务使用，跨账户委派要联系支持团队处理。

无版本域名提供另一条路径。同一份说明明确列出，可以将域名委派给另一个账户，甚至另一个客户，并以测试账户转向生产账户为例。其证明方式包括：通过 DNS 验证取得 Fastly 托管证书，并在 DNS 中设置令牌；或者提供可信公共证书机构签发的有效证书及匹配私钥。这是产品对控制证明的要求，不是要求企业在服务商之间随意传递生产私钥。

商业上的变化，是部分交接不再必然从一个支持工单开始。具备适当权限与证明条件的一方，有了更直接的办理方式。但自助只是减少中介步骤，并没有消除前提。如果企业把 DNS 管理、证书处理和平台账户都留给即将退出的团队，界面上的自助功能不会自动把这些能力交还企业。

反过来，企业若保留必要的账户治理和域名控制能力，就可以将运维服务与公共入口的长期支配分开采购。服务商仍能负责日常工作，但更换它不必从重新寻找整个证明链条开始。这是一种选择权，而不是已经测得的成本节省；公开文档没有披露客户交接成功率、平均所需时间或具体收费。

还必须保留一个产品例外。无版本域名操作指南指出，使用 Platform TLS 的客户在统一域名管理中只有只读权限，要管理域名或迁移产品，需要联系支持团队。不能把某种账户形态的自助能力写成全部 Fastly 客户都能使用的通道。接手之前，先识别正在运行的产品安排，比假定所有域名都遵循同一流程更重要。

一张证书并不包办整个交接

Fastly 的域名管理 API把几个条件分开记录。verified 表示客户通过托管证书或符合条件的自有证书证明了域名控制；activated 表示至少存在一个 TLS 启用关系；服务关联和请求路由配置又是另外的字段，可以各自为空。

这种表达提醒买方：证书证明、加密服务和应用承接各有对象。证书可以证明平台要求的控制条件，却不能解决域名注册权争议，也不能证明公司或品牌归谁所有。TLS 已启用，也不能独自说明某条业务路径会进入新团队期望的服务。把所有状态压成一个“域名已迁移”的内部标签，会丢失谁仍能执行下一步的信息。

自有证书尤其容易被当成方便的交付物。自管证书指南说明，上传有效证书和匹配私钥之后，还要设置 TLS 配置、启用相应域名，并将 DNS 指向合适位置。证书覆盖多个名称，不代表每个计划使用的域名都自动完成了显式启用。企业交接的是一组持续关系，不是一个可以归档后就不再过问的文件。

谁负责后续更新也属于交接范围。托管证书与自管证书把续期工作分配给不同一方；接管文件却没有接管到期提醒、更新流程和账户责任，只是把失败时间推迟了。TLS 前提与限制还规定了权限和账户条件。产品名称相同，并不意味着新团队已继承旧团队可用的全部操作范围。

能提前准备的，是迁移时的谈判余地

域名管理与服务版本分离，为交接创造了一个有用的时间窗口。Fastly 的托管证书指南说明，默认的 ACME DNS 验证只把验证子域指向 Fastly，可以先准备 TLS，再移动生产流量。验证准备与实际用户访问，因而可以分别安排。

这与 HTTP 验证方式存在实际差别。后者会立即把流量引向 Fastly，文档警告，若 TLS 或服务设置尚未完成，用户可能看到安全警告，甚至无法访问。对采购而言，差别不是选项名称，而是交接过程中谁承受尚未完成的工作：是准备环境中的运维团队，还是已经在使用网站的客户。

提前准备还改变了协调方式。新旧团队可以在约定的生产切换之前，确认哪些证明、服务关联和证书配置已具备，哪些仍依赖另一方。这样可以把“请你现在帮忙，否则网站无法切换”的临时请求，改成更早就能发现的交接缺项。它不能保证无中断，却可以降低在最后时刻才暴露控制依赖的机会。

这个收益不应被夸大成永久独立。验证所依赖的 DNS 记录和允许签发证书的 CAA 设置会影响续期。TLS 订阅 API也区分证书取得、续期与重试状态。重试仍在进行，不等于证书仍然有效。一个当初能完成验证的账户，不一定永远保有更新证书所需的条件。

对客户而言，更好的交接成果不是“证书曾经申请成功”，而是明确谁会持续维持这些条件。特别是在同一域名由网站团队、安全团队和外部代理商共同管理时，持续责任比一次操作的熟练程度更有价值。

一个域名背后，可以不止一项服务

域名从发布版本中分离之后，还出现另一种需要交接的安排：公共名称保持不变，名称下面的不同请求却可以交给不同服务。Fastly 的请求路由规则指南允许按路径及请求条件，将流量路由到 Fastly 内部的不同服务，而不必为这层路由编写 VCL 或 Compute 代码。

这对分阶段重建网站有吸引力。某一业务路径可以使用不同服务，其他请求继续由既有服务承担。入口无需为每项内部调整更换名字，应用团队也可以把部分路由决定从代码中拿出来管理。不过，便利意味着交接清单里又多了一项内容：究竟是谁维护这套入口后的分配规则。

文档要求域名已纳入域名管理、拥有有效 TLS 证书并指向活动服务，也要求设置默认规则。路由配置必须部署并关联域名，才能用于实际流量。对一份已经部署的配置，关联动作本身就可能改变请求去向。因此，只移交目标服务的代码，可能遗漏仍决定哪些请求能到达该服务的规则。

这不是说路由规则天然危险。它们可以减少代码改动，让不同团队更清楚地管理各自的业务路径。问题在于，组织是否同步调整了交接责任。如果团队只按代码库划分边界，而域名层还存在共享规则，管理界面上的分工就会与实际流量的分工不一致。

在 Fastly 内部换位置，不等于离开 Fastly

客户可以在一个平台内部改服务、改账户，也可以决定把生产流量交给另一家平台。前两项能够提供管理灵活性，却不能直接证明第三项容易完成。跨账户委派仍然留在 Fastly 的证书和服务模型里；更换平台还需要接收方具备可用的服务、证书、源站连接与相应应用行为。

Fastly 的流量路由说明明确说，在这里描述的配置中，Fastly 不提供托管 DNS 服务。客户选择 DNS 服务商，再安装 Fastly 提供的记录。这个外部管理面有其意义：域名的公共指向并不是只能通过应用发布来改变。但企业是否真正保留这种能力，取决于自己的账户与人员安排，不能从供应商产品架构直接推断。

DNS 变更也有时间条件。旧记录的缓存不会因为交接文件签字就一起消失，新路径需要在真实请求抵达时可用。另一方面，在 Fastly 内部改域名与服务关联，也不等于执行了公共 DNS 迁移。混淆两者，会让企业既高估自己离开供应商的便利，又低估留在供应商内部调整责任的影响。

Fastly 已经是一家规模可观的服务商。其2026 年第二季度业绩公告披露，季度收入为 1.833 亿美元，其中网络服务为 1.339 亿美元。这说明域名管理不是孤立的开发工具，而是大型交付业务的入口环节；这些收入却不能证明无版本域名的采用量，也不能证明客户因此获得了更强议价权。

真正能够改变采购关系的，是一项更窄的能力：企业能否在不重新夺回自己入口的情况下，更换替它运维入口后方设施的人。Fastly 提供了把域名与部署分开处理的工具。谁保留证明，谁负责持续更新，谁有权决定请求去向，仍需要企业在合同开始时安排，而不是等到合同结束时补写。