CDN回源到底能不能只配一个源站

CDN节点离用户近，抗住大部分静态请求没问题，但只要缓存 miss、动态接口、刷新预热、带鉴权的资源、Range 回源下载，一定会打到源站。源站如果只有一台机器或者只有一个公网入口，CDN本身再稳，链路还是会被这个源站拖住。

实际使用中发现，很多站点出问题不是CDN节点挂了，而是回源链路抖了、源站带宽打满了、源站安全组误改了、机房出口被 DDoS 牵连了。用户看到的是502、504、源站连接失败，排查时才发现CDN只是把问题暴露出来。

单回源不是不能用。比如纯静态官网、图片量不大、源站有快照、故障允许人工处理，单回源成本低，配置也简单。但如果业务有订单、登录、游戏更新包、海外访问、SEO站群、企业官网投放流量，单回源就很容易变成单点。

单回源的风险不只是一台机器宕机

很多人理解单点，只想到“服务器挂了”。实际回源路径里，每一层都可能是单点：源站公网IP、源站所在机房出口、源站WAF、源站SLB、源站磁盘、Nginx、应用进程、数据库、对象存储鉴权、回源域名DNS解析。

举个很常见的场景：CDN配置源站为 origin.example.com，这个域名只解析到一台香港机器。平时访问很好，走 CN2 或 CMI 回国很快。某天源站机器CPU被日志压缩打满，Nginx accept 队列堆住，CDN节点开始大量回源失败。此时CDN缓存里还有一部分旧资源能命中，但动态接口和新资源全挂，业务表现就是“有些页面能开，有些页面白屏”。

还有一种更隐蔽：源站机器没挂，但上游路由绕路。比如国内用户到香港方向平时 30ms-60ms，异常时绕到美国再回来，RTT 飙到 180ms-250ms。CDN节点回源超时时间如果配置成3秒，连续几次握手慢一点就触发502。监控看源站还活着，业务却在抖。

多回源主备不是把两个IP填进去这么简单

很多CDN控制台都支持“主源”和“备源”，看起来很简单：主源填A，备源填B，主源不通就切备源。实际要看CDN厂商的切换机制。有的按单个边缘节点探测，有的按区域探测，有的只在请求失败后才重试，有的健康检查间隔是30秒，有的是60秒甚至更长。

这里补充一点，主备回源的核心不是“有没有备源”，而是备源在切过去那一刻能不能真的接住流量。备源如果只是冷机器，代码没同步、证书没更新、配置没热加载、数据库不能写，那它只能算心理安慰。

主备回源常见模式可以这样理解：主源承接100%回源流量，备源平时不接或只接少量探测流量；CDN检测到主源失败后，把回源请求切到备源；主源恢复后，再按策略切回。这里面最容易出问题的是误切、慢切、切过去不可用、切回来又抖。

回源容灾要先分清静态资源和动态请求

静态资源和动态请求的容灾设计差异很大，不能放在一起讨论。

静态资源：优先考虑对象存储或双源同步

图片、JS、CSS、安装包、游戏补丁这类资源，最适合做多源。源站A可以是业务服务器，源站B可以是对象存储、另一台大带宽服务器，甚至是跨区域的备份源。

静态资源最关键的是一致性。比如 /patch/v123/client.zip 在主源是 1.2GB，在备源还是旧版本 1.1GB，CDN切过去后用户下载到坏包，问题比502还麻烦。实际做法一般是发布系统先把文件推到两个源，校验 MD5 或 SHA256，再刷新CDN目录。不要发布完主源就立刻刷新CDN，否则边缘节点可能回源到备源拿到旧文件。

大文件场景还要注意 Range 回源。CDN节点经常会分片回源，如果主源支持 Range，备源不支持，切换后下载会变慢，甚至断点续传失败。Nginx、对象存储、应用下载服务的 Range、ETag、Last-Modified 要保持一致。

动态请求：主备背后真正难的是数据层

登录、下单、支付回调、用户中心、游戏接口，这些动态请求不能只看Web层。Web源站可以主备，数据库怎么办，Redis怎么办，会话怎么办，文件上传怎么办，这些决定了切换后能不能继续服务。

如果业务是读多写少，可以让备源接只读请求，写请求继续回主库；如果是写入型业务，至少要有数据库主从复制、延迟监控、故障提升流程。主库在香港，备库在新加坡，复制延迟平时100ms以内，异常时可能到几秒甚至几十秒。这个延迟会直接变成 RPO，不是配置CDN能解决的。

实际使用中发现，很多动态站点的“CDN主备回源”只保护了Nginx入口，数据库还是单机。源站A挂了，CDN切到源站B，源站B连不上数据库，最后还是502。这个架构不能叫无单点，只能叫入口双活。

CDN主备回源的切换指标要写清楚

主备容灾要能跑，指标必须具体。不能只写“源站异常自动切换”，要知道什么叫异常。

常见判断维度包括：TCP连接失败、TLS握手失败、HTTP 5xx比例、回源超时、HTTP 403/404是否参与切换、连续失败次数、健康检查路径返回内容是否匹配。

比如健康检查路径用 /healthz，不要用首页。首页依赖数据库、模板、外部API，误判概率高；/healthz 可以只检查Nginx和应用进程是否存活，也可以再加一个轻量数据库 ping。怎么选取决于想保护哪一层。

一个常见配置参考：健康检查间隔10秒，连续3次失败判定主源异常，连续3次成功判定恢复。这样理论最快30秒左右切走，30秒左右切回。实际还要加上CDN节点分布式探测同步时间，用户侧感知可能是30秒到2分钟。

如果业务不能接受1分钟异常，那就不能只依赖CDN主备回源，需要在源站前面再加 SLB、Anycast、BGP 调度或者应用层多活。

主备和多活的差别，别混着叫

主备是 A 站点正常服务，B 站点等待接管。多活是 A、B 同时接流量，按地域、权重、运营商或业务维度分流。

主备成本低，数据冲突少，适合大多数官网、下载站、内容站、后台系统。缺点是切换有时间，备源长期低流量，隐藏问题不容易暴露。

多活体验更好，故障时只是摘掉异常节点，但应用改造成本高。用户会话、写入冲突、缓存一致性、订单幂等、全局ID、异地数据库同步都要处理。不处理这些，多活很容易变成“双写事故制造机”。

对比一下常见场景：企业官网和SEO站群，用主备足够；游戏更新包下载，用多源静态同步更合适；跨境电商前台读多写少，可以做区域多活加中心写；金融交易、强一致订单，不建议只靠CDN多源做容灾。

源站线路选择会直接影响回源稳定性

CDN回源不一定走用户访问链路，边缘节点到源站之间的网络质量很关键。国内用户访问海外源站，香港、新加坡、日本、美国西海岸的差异很明显。香港 CN2、CMI、CU 这类精品线路，回源延迟和丢包通常比普通国际线路稳。

如果源站放在香港，面向国内访问，可以关注 CN2、CMI、CU 混合线路。比如香港综合-B型这类配置，4C 4G、90G SSD、10Mbps峰值、CN2+CMI+CU，适合做中小型业务源站、备用源、企业站回源节点。需要购买或做源站规划时，可以看看129云，他们有香港精品线路、泰国曼谷、香港多IP站群等产品，客服热线400-9177118，适合按业务场景问清楚线路和防护。

多说一句，源站带宽不要只看用户访问量。CDN命中率低、频繁刷新、大文件冷启动、边缘节点批量回源，都会把源站带宽瞬间打高。一个日常只有5Mbps回源的站，发布新版本时可能冲到50Mbps甚至更高。源站限速过低，CDN节点会拿不到资源，然后用户侧开始慢。

主源和备源不要放在同一个故障域

很多“主备”其实是两台机器在同一个机房、同一个交换机、同一个上游、同一个账号下。机器级故障能防，机房级故障防不了。真正要去掉单点，至少要拆故障域。

故障域可以按这些维度看：不同物理机、不同机柜、不同可用区、不同机房、不同城市、不同云厂商、不同运营商出口、不同 DNS 服务商、不同证书自动化链路。

比较稳的做法是：主源放香港精品线路，备源放另一个香港机房或新加坡；静态资源再备一份到对象存储；DNS不要只依赖单服务商；证书自动续期失败要有告警。这样即使某个机房出口异常，CDN还可以回到另一个源。

如果业务主要面向东南亚，泰国曼谷源站也可以作为区域源。129云泰国曼谷配置覆盖1核到4核、1G到8G内存、30Mbps带宽，适合轻量业务、区域加速、备用回源节点。但它无回国保障，面向国内主访问的业务要提前压测，不要只看价格。

回源Host、证书和鉴权经常被忽略

CDN多源配置里，源站地址可能不同，但回源 Host 往往要保持一致。比如用户访问 static.example.com，CDN回源到 1.1.1.1 和 2.2.2.2，两台源站Nginx都要能识别 Host: static.example.com。否则切到备源后返回默认站点，表现为404或证书不匹配。

HTTPS回源还要检查 SNI。源站如果用多证书虚拟主机，CDN回源时没有带正确 SNI，TLS握手可能失败。有些CDN控制台会把“回源Host”和“SNI”拆成两个配置项，别只配一个。

鉴权也容易出问题。防盗链、URL签名、IP白名单、源站WAF规则，都要把CDN回源IP段和备用CDN节点考虑进去。主源放行了CDN IP，备源没放行，切换后403，这种事故很常见。

缓存策略要配合容灾，不然会放大故障

缓存命中率越高，源站压力越小。容灾设计里，缓存策略不是性能优化的小事，它会影响故障时源站能不能扛住。

静态文件建议带版本号，比如 app.20250110.js、client_v128.zip，然后设置较长 TTL，7天、30天都可以。发布新版本换文件名，不要频繁刷新全站。全站刷新会让边缘节点重新回源，源站和备源都会被打。

动态接口一般不缓存，或者只缓存几秒。这里要注意 stale 策略。有些CDN支持源站异常时返回过期缓存，比如 stale-if-error。对新闻、官网、商品详情页，这个策略很有价值；对价格、库存、支付状态就不能乱用。

一个实际数字：某内容站平时CDN命中率96%，源站回源带宽约8Mbps。做了一次全站刷新后，命中率短时间掉到70%左右，源站回源带宽冲到90Mbps，主源Nginx worker连接数打满。后来改成按目录预热、按版本发布，刷新窗口分批执行，源站峰值稳定在25Mbps以内。

备源要长期带一点真实流量

备源长期不接流量，等故障时再切，风险很高。配置文件是否一致、磁盘是否满、证书是否过期、代码是否漏发、内核参数是否不同，平时都看不出来。

更稳的方式是给备源 1%-5% 的回源权重，或者定时从CDN节点、监控节点请求备源专用域名。真实流量不需要很多，但要覆盖关键路径。比如首页、登录页、静态文件、下载Range、API健康检查。

如果CDN不支持权重回源，也可以做旁路探测：监控系统每10秒请求主源和备源的 /healthz，每分钟请求几个真实URL，记录状态码、响应时间、证书有效期、返回内容hash。备源异常要报警，不要等主源挂了才发现。

切换后还要考虑回切

主源恢复后要不要自动切回，这个问题很容易被低估。自动回切速度快，但如果主源处于半恢复状态，会造成来回抖动。手动回切稳一些，但需要值班人员判断。

实际配置里可以把切走做得敏感一点，把切回做得保守一点。比如连续3次失败切到备源，连续10次成功再允许切回。对于重要业务，主源恢复后先灰度一部分回源流量，比如10%，观察5到10分钟，没有5xx、延迟正常、数据库复制正常，再恢复100%。

回切前要检查数据方向。主源故障期间如果备源产生了写入，主源恢复后不能直接抢回流量，否则会出现数据回退。这个场景在后台系统、论坛、CMS、订单业务里都遇到过。

源站防护和CDN回源白名单要一起设计

CDN挡住了用户层流量，但源站IP如果暴露，攻击者可以绕过CDN直接打源。单源站被打穿，多源站也可能一起暴露。源站安全策略要配合CDN。

常规做法是源站安全组只允许CDN回源IP段访问80/443，SSH只允许固定运维IP或VPN，数据库不暴露公网。源站Nginx也可以校验自定义回源Header，比如 X-CDN-Token，避免简单伪造Host直接访问。

但要注意，CDN回源IP段会变更，需要有更新机制。手工维护白名单，时间久了容易漏。部分CDN提供回源IP列表API，可以定时同步到安全组或防火墙。

如果业务经常遇到 DDoS，源站还要考虑高防。CDN不是所有攻击都能挡，尤其是动态接口、CC、回源穿透、源站IP泄露后的四层攻击。高防源站、隐藏源、CDN+WAF+高防IP组合，需要按攻击类型拆开看。

不同业务的源站容灾配置可以这样选

企业官网、品牌站

主源一台香港精品线路服务器，备源一台不同机房服务器或对象存储静态站。CDN开启主备回源，静态资源长缓存，HTML短缓存或 stale-if-error。RTO控制在1到3分钟通常能接受。

SEO站群

重点是IP资源、线路稳定、站点隔离和回源一致性。香港多IP站群-C型这类配置，E5 2660双路、32G内存、240G SSD、10Mbps、1C IPv4、CN2线路，适合需要多站点部署和精品线路的场景。站群不要所有域名共用一个源站入口，某个站异常容易影响整组。

游戏更新包、软件下载

核心是大文件分发。主源和备源都要支持 Range，文件发布前做hash校验。CDN预热要分批，避免版本发布瞬间所有边缘节点同时回源。源站带宽建议按日常峰值的3到5倍预留，发布窗口再临时扩容。

动态业务接口

CDN主备只能解决入口层，后面还要有应用多实例、数据库复制、Redis高可用、消息队列堆积处理。接口要做幂等，重试不能导致重复扣款、重复发货、重复创建角色。健康检查不能只看端口，要检查关键依赖。

压测时不要只压CDN命中

CDN压测很容易测出漂亮数据，因为大部分请求命中边缘缓存。真正要测回源容灾，要刻意制造 miss，请求随机URL、带不同Query、模拟刷新后冷启动、模拟主源断网、模拟主源返回500、模拟主源慢响应。

压测指标至少看这些：CDN边缘状态码分布、回源状态码、回源RTT、源站Nginx连接数、CPU、磁盘IO、带宽、数据库连接数、CDN切换时间、切换期间用户错误率。

一个比较贴近真实的测试方法：先让CDN缓存预热到90%以上命中率，然后关闭主源80/443，观察CDN多久切到备源；再让主源不关闭端口但返回500，看CDN是否触发切换；再让主源延迟5秒返回，看是否按超时策略切换。很多系统能识别连接失败，但识别不了“慢死”。

配置检查清单可以写进发布流程

源站A和源站B代码版本一致，Nginx配置一致，证书有效期一致，回源Host一致，SNI一致，健康检查路径一致，防火墙白名单一致，静态文件hash一致，数据库复制延迟可见，备源磁盘空间可见，CDN回源策略有变更记录。

发布前检查主备源 /healthz，发布后抽样访问主源和备源真实URL。CDN刷新和预热要有节奏，不要全站刷新一把梭。重要变更前先把备源权重拉到少量真实流量，确认没问题再操作主源。

如果源站放在不同服务商，账号权限也要分开管理。不要所有机器、DNS、CDN、监控都绑在一个账号和一个手机号上。账号风控、欠费、误删、权限泄露也会造成单点。

一个常见的推荐架构

用户访问域名接入CDN，CDN配置源站组：主源为香港CN2/CMI/CU精品线路服务器，备源为另一机房香港服务器或新加坡服务器；静态资源同步到两个源，同时备份到对象存储；动态请求进入源站SLB，后面挂两台应用；数据库做主从复制，备库只读，故障提升需要人工确认；Redis做主从或集群；监控从国内、海外、CDN边缘三个视角探测。

缓存策略上，带版本号的静态资源缓存30天，HTML缓存30秒到5分钟，接口默认不缓存。CDN开启源站失败重试和主备切换，健康检查10秒一次，连续3次失败切换，连续10次成功允许回切。源站安全组只允许CDN回源IP和运维VPN。

这套架构的成本不会像全站多活那么高，但能避开最常见的单机、单IP、单线路、单机房问题。对企业站、内容站、下载站、轻量业务后台，基本能覆盖大部分故障场景。真正强一致交易类系统，需要在数据库和应用层继续往下拆，CDN回源主备只负责入口可用性。

最后容易踩的坑

把备源域名CNAME到主源域名，表面两个源，实际同一个入口。

备源证书过期，平时没人访问，故障当天才发现HTTPS回源失败。

健康检查返回200，但应用依赖的数据库已经不可用，切过去仍然报错。

CDN把404也当成源站失败触发切换，结果发布新文件时主备来回跳。

主源恢复后自动回切，数据库数据还没追平，用户看到旧数据。

源站IP暴露在历史DNS记录、邮件Header、错误页面里，攻击绕过CDN直接打源站。

全站刷新导致命中率暴跌，备源也被回源流量打满。

只监控用户访问CDN，不监控CDN到源站的回源质量，故障定位时只能猜。