先区分“CDN 挂了”到底是什么
社区里常见的说法是“某 CDN 完蛋了”，但这句话通常把多个故障层级混在了一起。S5 中的讨论同时提到台湾节点被屏蔽、DNS 解析不正常、测试时无法访问，以及“可能全网中断”等现象。它们看起来都像访问失败，实际对应的根因可能完全不同：节点路径不可达、权威 DNS 或递归 DNS 异常、区域网络策略变化、源站故障，或者 CDN 控制面不可用。
这一区分很重要，因为每一类故障的切换方式不同。如果只是某个 POP 到用户的路径异常，把所有流量切到另一家 CDN 可能有效；如果权威 DNS 本身失效，继续依赖同一套 DNS 控制面做切换就没有意义；如果源站返回 5xx，多 CDN 只会让多个入口一起把错误缓存或转发出去。
因此，故障处理的第一原则不是“准备一个备用域名”，而是建立从用户到内容源的故障分层：
- 解析层：域名是否得到预期记录，递归解析是否超时或返回异常结果。
- 连接层：TCP、TLS、HTTP/3 或 HTTP/2 是否能够建立。
- 边缘层：请求是否命中正确的 CDN，响应头、缓存状态和回源状态是否符合预期。
- 源站层：源站是否健康，回源链路是否出现超时、限流或证书问题。
- 控制面：域名、证书、缓存规则和调度配置是否仍可修改。
只有把这些层级分开，备用 CDN 才不是一张“供应商名单”，而是一条可执行的故障路径。
多 CDN 的核心不是堆供应商，而是隔离故障域
多 CDN 架构通常有三种入口设计。
第一种是由 DNS 根据地域、运营商或健康状态返回不同的 CDN 地址。它的优点是架构简单，切换范围大；缺点是 DNS 缓存会让切换存在时间窗口，而且当 DNS 服务本身发生故障时，调度逻辑也无法执行。TTL 写得很短并不等于所有递归解析器和客户端都会立刻刷新，因此不能把“设置 60 秒 TTL”当成秒级故障切换的证明。
第二种是在统一域名下使用应用层网关或反向代理，由网关选择不同的 CDN 或源站。这种方式可以获得更细粒度的健康检查、重试和熔断能力，但网关本身会成为新的容量、证书、带宽与安全边界。若所有请求都必须先经过单一网关，所谓多 CDN 可能只是网关后的多源站，并没有真正隔离入口故障。
第三种是让不同业务使用不同的 CDN 域名，例如静态资源、下载文件、图片和 API 分别拥有独立入口。它不一定提供自动切换，却能把故障半径限制在单个业务面。对于个人站点或中小型服务，这种“按业务拆分”的方案经常比一开始就建设复杂的全局调度平台更容易验证。
Fastly 官方页面将其定位为可编程的边缘云平台，覆盖 CDN、边缘代码、安全与可观测能力，并在页面中展示了全球网络容量和延迟方面的厂商声明。这些信息可以帮助我们理解其产品方向，但不能直接推导出“在你的用户网络中一定更快”或“发生区域故障时一定可用”。供应商的全球指标、产品能力和本地用户体验，属于三个不同的证据层级。
多 CDN 的价值也不只是平均延迟更低。更准确的收益是：当某个供应商、区域、线路或控制面进入异常状态时，系统仍保留一条可验证的替代路径。代价则包括缓存预热、规则同步、证书管理、日志聚合、计费监控和故障时的决策复杂度。
先做可复现检查，再决定是否切换
切换前应保存当前入口的基线。以下命令只依赖常见工具，适合在多个网络位置执行；结果应记录时间、出口网络、解析结果、HTTP 状态、响应头和总耗时，而不是只截取一条“能打开”的结论。
DOMAIN=static.example.comURL=https://$DOMAIN/health.txt
# 记录解析链路 dig +time=3 +tries=1 $DOMAIN A dig +time=3 +tries=1 $DOMAIN AAAA
# 检查状态、重定向、缓存与边缘标识 curl -sS -o /dev/null -D - \ -w 'code=%{http_code} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} start=%{time_starttransfer} total=%{time_total}\n' \ "$URL"
# 检查证书主体、有效期和协议协商 openssl s_client -connect "$DOMAIN:443" -servername "$DOMAIN" </dev/null 2>/dev/null \ | openssl x509 -noout -subject -issuer -dateshealth.txt 应是一个小而稳定的对象，内容可以包含版本或构建标识，但不要依赖数据库、用户登录或复杂业务。它的用途是区分“入口可达”和“整个应用正常”。对静态资源，还应额外检查一个不可缓存的测试对象和一个实际的大文件，因为小对象命中缓存并不能证明回源、分片下载或长连接都正常。
检查清单至少包括以下项目：
- 从主网络、移动网络和至少一个异地出口执行解析与 HTTPS 请求；
- 比较 A、AAAA 记录，避免 IPv6 路径单独失败却被误判为 CDN 故障；
- 记录响应头中的缓存命中、边缘节点或请求追踪标识；
- 分别测试不存在对象、刚发布对象、长缓存对象和大文件；
- 使用固定 URL 进行连续采样，而不是只测试首页；
- 将 DNS、TLS、首字节和完整下载耗时分开统计；
- 检查源站日志，确认请求是否真的到达 CDN，而不是在解析或连接阶段失败。
如果供应商提供测试域名或临时 CNAME，应先在不影响生产流量的情况下验证。验证目标不是证明“备用 CDN 能打开”，而是确认它能完成完整链路：解析、证书、缓存策略、回源、压缩、跨域头、范围请求和错误响应。
切换策略：把自动化和人工决策分开
自动故障切换适合处理可明确判定的故障，例如连续多个采样窗口出现 DNS 超时、TLS 建连失败或固定健康对象返回 5xx。但自动化不应只依赖单个探针，也不应因为某个地区短暂丢包就立刻把全球流量切走。一个更稳妥的判定模型是“多地点、连续窗口、同一层级的失败”：至少两个独立出口在连续若干次采样中观察到同类错误，才触发候选切换；切换后继续保留原入口的探测，以便判断是否恢复。
人工切换则适合处理证据不完整或影响范围不清的事件。人工操作的关键不是“有人值班”，而是提前准备无歧义的步骤：修改哪条记录、期望 TTL 是多少、如何确认新入口生效、多久观察一次、何时回滚、谁负责宣布结束。所有操作都应保留变更前后的配置快照。
切换时不要同时修改 DNS、缓存规则、源站地址、证书和应用版本。一次改变太多变量，最终即使恢复访问，也无法知道真正起作用的因素。优先只改变流量入口；若备用 CDN 的缓存键、压缩或回源规则不同，再单独处理功能差异。
回滚条件应在切换前写好。例如：新入口在两个以上网络位置持续返回证书错误；核心对象命中率明显下降并造成源站负载升高；API 出现跨域或鉴权头丢失；或者错误率没有下降。回滚不是承认方案失败，而是把一次不可控事故变成可逆操作。
性能、成本与一致性的取舍
多 CDN 不会自动提高性能。不同供应商可能拥有不同的节点布局、运营商覆盖和协议支持；同一用户在不同时间经过的路径也会变化。比较时不能只看一次 curl 的总耗时，应按地区和网络类型统计首字节、完整下载、错误率、缓存命中率以及源站回源量。
缓存一致性是另一个容易被忽视的边界。若主 CDN 已缓存旧版本，而备用 CDN 刚开始接流量，它可能大量回源；如果两个供应商的缓存键、忽略查询参数或刷新接口行为不同，同一个 URL 可能在不同入口返回不同内容。解决方法不是简单缩短所有缓存时间，而是为静态资源使用内容哈希文件名，并为发布流程定义版本可见性检查。
成本也需要按照故障场景计算。备用 CDN 平时没有流量，不代表没有最低套餐、请求、日志、证书或回源费用；一旦发生切换，备用入口的回源容量、带宽上限和速率限制才会真正暴露。若备用供应商只在故障时启用，至少应定期发送小比例探测流量，否则它很容易在真正需要时才发现配置已经过期。
安全边界同样不能复制粘贴。WAF 规则、源站白名单、访问令牌、跨域策略和防盗链配置必须在备用入口逐项核对。如果源站只信任主 CDN 的回源地址，切换后备用 CDN 可能全部得到 403；如果为了让备用入口快速上线而临时放开源站，则又扩大了攻击面。故障预案必须同时包含可用性和最小权限检查。
原创结论：备用 CDN 首先是一种“可验证能力”
从 S5 的社区讨论可以看到，用户真正担心的不是某家供应商在宣传页上的全球覆盖，而是当区域访问异常、DNS 中断或节点路径失效时，自己是否有证据判断问题在哪里。Fastly 官方页面展示了可编程边缘、CDN、安全和可观测能力，但供应商能力只有被映射到你的域名、源站、用户网络和运维流程中，才会变成实际的可靠性。
因此，多 CDN 的最低可用标准可以压缩成四句话：备用入口必须独立验证，故障必须分层判定，切换必须可回滚，恢复必须有证据确认。 做不到这四点时，新增一个供应商往往只是在 DNS、证书、缓存和权限系统中增加更多未验证的变量。
对于规模有限的站点，建议先从一个稳定健康对象、两套独立入口、三类网络探测和一份人工回滚清单开始；对于有全球业务的系统，再逐步引入按区域调度、自动熔断和统一观测。架构复杂度应当由故障半径和恢复目标驱动，而不是由供应商数量驱动。
参考资料
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时