CDN迁移往往不是技术难度最高的项目，却是最容易出事故的项目之一。原因很直接：DNS 切走之后，用户请求会在几分钟内涌向新平台，而缓存是空的、回源链路是新的、源站可能还没做好承接突增回源的准备。

一次看似简单的服务商更换，可能在切换当天演变成源站带宽打满、5xx 错误飙升、静态资源大面积回源的事故。

要避免这种情况，核心在于把迁移拆成三件可控的事：缓存刷新策略决定切换瞬间的负载峰值，回源配置决定新平台能否稳定取到内容，灰度切流决定犯错时的爆炸半径。

本文按实操顺序梳理这三件事的关键动作与常见坑，适合正在评估或已经启动 CDN 迁移的技术负责人参考。

一、迁移前先把缓存策略算清楚

很多团队把缓存刷新当成切换后的补救动作，实际上它应该是迁移设计的第一步。切换瞬间最危险的不是新 CDN 节点没有内容，而是所有节点同时没有内容。假设站点日均请求 2000 万次，静态资源缓存命中率 95%，那么切换后缓存全空意味着源站要承接接近 2000 万次回源请求，即便按 10 分钟均匀分布，也是每秒 3 万次以上的回源压力，绝大多数源站扛不住。

第一，先盘点缓存命中率分层。把资源分成三类：高命中长缓存（图片、JS/CSS 带 hash 的构建产物）、中命中中缓存（HTML 页面、接口聚合数据）、低命中不可缓存（登录态、下单、支付回调）。迁移只对前两类做预热，第三类必须显式配置不缓存并确认新平台尊重源站的 Cache-Control 与 Vary 头。

第二，设计预热清单而不是全站刷新。全站刷新既慢又会把回源压力集中释放，正确做法是按访问量排序取前 500 到 2000 个 URL 做主动预热，通常能覆盖 70% 以上的静态请求量。预热要在切流前 2 到 4 小时完成，给回源失败留出重试窗口。

第三，明确刷新与预热的执行顺序。常见错误是先刷 CDN 再改源站，导致用户短时间拿到旧内容。正确顺序是：源站发布完成并验证、执行 URL 刷新或目录刷新、再执行预热、最后才开始切流。刷新接口一般有配额限制，目录刷新通常按天限额，要提前估算条数并申请提额。

第四，确认 TTL 与浏览器缓存的联动。CDN 的 TTL 改了，但用户浏览器里缓存的旧文件还在，仍然会指向旧逻辑。带 hash 的静态资源可以放心设长 TTL，HTML 入口文件必须设短 TTL（建议 60 到 300 秒），否则迁移后用户端表现会与预期严重不符。

二、回源配置决定新平台的稳定性

回源是 CDN 迁移中最容易被低估的环节。新平台对源站的回源 IP 段、协议支持、超时策略、重试次数都有自己的默认值，这些默认值往往和原平台不同，直接沿用旧配置会出现回源 403、回源超时、SNI 握手失败等问题。

第一，先放行新平台的回源 IP 段。源站如果有 WAF 或 IP 白名单，必须在新平台开通后第一时间导入其回源 IP 列表，否则切流后会出现大面积 403。建议同时保留旧平台回源段，直到灰度结束再清理，避免回滚时再次踩坑。

第二，配置回源协议与端口对齐。源站是否支持 HTTPS 回源、是否使用 443 或自定义端口、证书是否为自签或私有 CA，这些都要逐一验证。尤其要注意回源 Host 头：新平台默认可能用加速域名回源，而源站虚拟主机是按内网域名配置的，Host 不匹配会直接返回默认站点内容。

第三，设置合理的回源超时与重试。超时太短会导致正常慢请求被判定失败并触发重试，放大源站压力；太长则会让用户端长时间挂起。建议连接超时 5 秒、读取超时 30 到 60 秒，重试次数控制在 1 到 2 次，并对 5xx 与超时分别设置不同策略。

第四，打通回源监控与日志。切流前就要在新平台配置回源状态码分布、回源带宽、回源 RT 的监控面板，并把 CDN 日志接入自有日志系统。没有回源侧的可观测性，灰度阶段的问题定位会非常被动。

三、灰度切流控制爆炸半径

DNS 切换是不可精细回退的动作，一旦全量切走，出问题只能再切回来，而 DNS 生效时间从几分钟到几十分钟不等，这段时间足够造成实质业务损失。灰度切流的价值就在于把不可控的全量切换变成可控的小流量验证。

第一，优先用 CNAME 而非 A 记录迁移。保持域名指向一个可控的 CNAME，切换时只改 CNAME 目标，这样回滚只需改回原值，不必等 TTL 过期。切换前把原 DNS 记录的 TTL 提前 24 小时降到 60 到 300 秒，为快速回滚做准备。

第二，用流量比例或地域维度做小流量验证。多数 CDN 平台支持按权重或按省份、运营商维度把 1% 到 5% 的流量导向新平台，观察 30 到 60 分钟。重点看四项指标：5xx 比例、缓存命中率、首字节时间、回源带宽。任一项偏离基线 20% 以上就暂停放量。

第三，准备明确的回滚判定标准。不要靠感觉决定是否回滚，事先写清阈值，例如新平台 5xx 比例连续 5 分钟超过 0.5%、或首字节时间 P95 超过基线 1.5 倍，即触发回滚。回滚动作要提前演练一次，确认改 CNAME 后旧平台仍能正常服务。

第四，分阶段放量并保留观察窗口。建议按 1%、10%、50%、100% 四个阶梯推进，每阶段至少观察 30 分钟，并在业务高峰前完成主体切流，避免在流量最高点承担风险。切流完成后不要立刻拆除旧平台配置，保留 3 到 7 天作为兜底。

四、切换后的验证与收尾

切流完成不等于迁移结束。缓存会逐步自然过期，回源比例会在切换后几小时内先升后降，这个过程中的异常往往被误判为故障。

第一，对照刷新前后的一致性。抽查核心页面与关键静态资源的响应头、内容长度、ETag，确认新平台返回的内容与源站一致，特别注意压缩方式、字符集、跨域头是否被改写。

第二，跟踪 24 小时与 72 小时两个时间点的指标。24 小时看缓存命中率是否回到基线、回源带宽是否回落；72 小时看是否有长尾资源因 TTL 到期集中回源造成的二次峰值。

第三，完成配置与文档收尾。包括旧平台资源下线计划、回源 IP 白名单清理、DNS TTL 恢复常规值（如 600 秒）、以及把本次迁移的刷新清单、灰度阶梯、回滚阈值写入运维文档。这些记录在下一次迁移时价值极高。

FAQ问答

Q1：CDN 迁移需要提前多久准备？

A：中小型站点建议预留 2 到 3 周，包含资源盘点、预热清单整理、回源联调和灰度演练。日请求千万级以上的站点建议留 4 周以上，重点是回源压测和回滚演练。

Q2：切换时缓存全空，源站扛不住怎么办？

A：核心手段是提前预热高访问量 URL 覆盖大部分静态请求，同时给源站设置回源限速和降级开关，必要时对非核心接口临时返回缓存副本。切忌在切流同时做源站发布。

Q3：灰度切流一定要做吗，能不能直接全量切？

A：建议必须做。DNS 切换回退慢，全量切的故障影响面是 100%，而 1% 灰度可以把潜在损失压缩到可接受范围，成本只是多花一两个小时观察。

Q4：回源 403 最常见的原因是什么？

A：多数是源站 WAF 或 IP 白名单没有放行新平台的回源 IP 段，其次是回源 Host 头与源站虚拟主机配置不匹配。排查时先看源站访问日志里的来源 IP 和 Host 字段。

Q5：迁移完成后旧 CDN 配置能立刻删除吗？

A：不建议。至少保留 3 到 7 天，确认新平台指标稳定、无长尾资源异常回源后再下线。删除前先确认 DNS 已完全生效且没有残留的旧 CNAME 解析。

总之，CDN 迁移的关键不在“换平台”，而在把切换瞬间的负载、链路和风险都提前量化。建议按四步推进：先按访问量整理 500 到 2000 条预热清单并把入口文件 TTL 压到 300 秒以内；再逐项验证回源 IP 放行、Host 头、超时与重试；然后用 1%、10%、50%、100% 的阶梯灰度，并写死回滚阈值；最后保留旧平台 3 到 7 天兜底并完成文档归档。把这四件事做扎实，迁移就能从高风险动作变成一次常规运维。