香港服务器挂在 CDN 后面，CDN 出问题怎么办：降级切换实操

8 月有两件事挨得挺近。一件是 Cloudflare 状态页在 8 月 7 日到 14 日之间接连记录了十几起彼此独立的事件，涉及 R2、Workers KV、Durable Objects，以及科威特、曼谷、雅加达几个方向的区域性 5xx；另一件是 Bluesky 从 8 月 16 日起被 DDoS 打了将近一天，第二天才缓过来。

两件事本身没什么关联，但对把源站放在香港、前面挂一层 CDN 或高防的人来说，暴露的是同一件事：出问题的是前置层，你的香港服务器好端端跑着，用户就是打不开。

这种时候最没用的动作，是重启源站。

先分清是哪一种失效，再决定动不动手

前置层失效大致三种，处置动作完全不同，甚至互相矛盾。

第一种，前置层整体不可用。 节点连不上、DNS 不解析、或者大面积 5xx。源站入口日志请求量归零，负载曲线一条直线掉到底。

第二种，前置层还活着，但回源被掐断或者被打穿。 高防节点扛不住、触发限流、回源链路中断。源站看到的现象是——请求量归零，负载正常。

看出问题了吗：第一种和第二种在源站那一侧看起来几乎一模一样。 但第一种该切直连，第二种切直连等于把没有防护的机器直接推到攻击流量面前，几分钟就真的挂了。所以判断的关键点不在源站，在前置层那一侧：

• curl -v 直接打 CDN 节点 IP。TCP 都握不上手，偏向第一种；能连上但回 5xx/52x，说明前置层进程还在，问题出在回源或清洗环节，偏向第二种。
• 翻高防或 CDN 控制台的攻击态势与清洗流量曲线，看有没有异常峰值。这一步最能定性。
• 看第三方状态页和社群里有没有别人同时在报。是别人也挂了，还是只有你挂了，指向完全不同。

第三种是误伤。 WAF 规则更新、Bot 策略变化把正常用户挡在外面。这种最隐蔽——所有监控都是绿的，只有转化率在掉。它不需要切换，需要去翻规则变更记录。

判断顺序我建议固定成：源站入口日志 → 源站带宽与连接数曲线 → 前置层节点连通性 → 前置层控制台攻击数据。前两步确认源站是好的，后两步决定能不能切。

别让健康探测替你做这个判断

这一条要单独拎出来说，因为它和很多人配好的自动化是直接冲突的。

常见做法是健康检查 + DNS 故障转移，连续 N 次探测失败自动切到备用记录。听着很美，问题在于探测器只知道"这条路不通"，它区分不了上面的第一种和第二种。 真赶上被打穿，自动切换会非常敬业地把源站送出去。

我的取舍是：切到有防护的备用通道，可以自动；切到裸源站，必须有人点头。如果一定要开自动，就限定在能明确排除攻击的特征上（比如探测到的是连接被拒、DNS 解析失败这类），并且把自动切换的目标设成第二条清洗通道，而不是源站真实 IP。剩下的情况，宁可留一个一条命令能跑完、也能一条命令回滚的手动脚本。半夜三点被叫醒执行一条脚本，比让系统自己乱动要稳。

平时要备好的三样东西

一条不经过 CDN 的直连入口。 给香港服务器准备一个备用主机名或一段备用 IP，A 记录直接指向源站。证书要提前签好并保持自动续期——切过去满屏证书告警，等于没切，这个坑在演练时踩过的人不少。

权威 DNS 和 CDN 不放在同一家。 DNS、主机、邮件全挤在一个供应商的篮子里，一处失效就全线失联，Namecheap 那次长时间宕机就是这个模式。权威 DNS 托管在独立第三方、并开启多组 NS，成本极低。

源站要有独立扛住全量的余量，而且这个数能算，别拍。 平时 CDN 帮你挡掉的那部分，切直连后全压回香港服务器。去控制台把过去 30 天的字节命中率拉出来：命中率 80%，切直连后源站出口带宽大致要涨到原来的 5 倍（1 ÷ (1−0.8)）；命中率 90%，就是 10 倍。请求数的涨幅会小一些，因为动态请求本来就在回源。所以"留够两倍余量"这种说法基本没意义，先算再定。

顺带纠正一个常见的 TTL 误区：真正决定切换生效速度的，是主域名那条记录的 TTL，不是你备用域名的 TTL——切换时改的是主域名的指向。而且 60 秒只是理想值，不少递归解析器会把过短的 TTL 抬到 300 秒，浏览器和某些运行时还有自己一套 DNS 缓存。实测从改解析到大部分用户切过去，通常要 10 到 30 分钟。预案里写"几分钟恢复"，演练当天会很难看。

切成直连之后，会跟着一起掉的东西

这部分原本最容易被忽略，也最容易在切换后半小时才爆出来。

真实客户端 IP 没了。 应用如果是从 CF-Connecting-IP 或 CDN 注入的 X-Forwarded-For 取客户端 IP，直连之后这个头没人填了，取到的会是空值，或者是客户端可以随便伪造的值。依赖它的风控、限流、登录地校验、日志统计会一起出错，而且大多不报错，只是默默算错。

WAF、Bot 管理、速率限制全部失效。 源站上如果没有本地兜底（nginx 的 limit_req、fail2ban 之类），这段时间是门户大开的状态。

边缘上那些优化没了。 Brotli 压缩、图片自动格式转换、HTTP/3、边缘缓存，源站自己做不了的部分就只能慢下来。用户能进来，但体验不是一回事。

按 IP 白名单放行的第三方回调会断。 支付回调、短信、OAuth 回调里有不少是绑 IP 的，源站 IP 一换就失败。这一条几乎只有在演练时才会被发现，线上第一次遇到通常已经是订单掉了才反查出来。

所以切直连的定位要清楚：它是止血，不是恢复常态。能撑住业务跑，不代表能长期跑。

备用入口"不对外宣传"，并不等于藏得住

这一点值得单独提醒。只要你给 direct.yourdomain.com 签过一张公开信任的证书，这个主机名就会进入证书透明度（CT）日志，而 CT 日志是完全公开可查的。找源站真实 IP 的人，第一件事就是去翻这个。指望"起一个不告诉别人的二级域名"来保护源站，防护力基本约等于零。

务实一点的做法有三条：用泛域名证书，具体主机名不会单独出现在 CT 记录里；或者把备用入口放到一个和主业务无关的域名下；或者干脆接受它会暴露，把重心放在源站自身的防护上。我更倾向第三条——藏 IP 是一次性的，藏住了就不能再用错，一旦漏了就得重来；防护是长期有效的。

第二条通道，以及事后收尾

要避免"前置层被打穿、又不敢切直连"的两难，思路是别把所有防护押在同一层。源站本身也要有基础的抗打能力：香港高防服务器 内置 DDoS 防护，L3-4 的量在源站这一层就能挡掉相当一部分；不想动现有机器的话，单独挂一个 香港高防IP 也可以，把它当成独立于 CDN 的第二条清洗通道。关键在于两条通道最好分属不同厂商、走不同网络，同时失效的概率才会真的降下来。

另外，切过直连就意味着源站 IP 已经暴露，业务恢复之后还有三步收尾：更换源站 IP、在防火墙上把回源来源重新收回到 CDN 的 IP 段、删掉临时加的解析记录。这三步经常在"业务好了"之后就没人管，过一两周被针对性打一次，才想起来 IP 早漏出去了。

每季度跑一遍，比写十页预案管用

挑一个低峰时段，走完整流程：主域名切到备用入口 → 验证登录、下单、回调这些关键链路 → 观察源站负载 → 切回来 → 收尾。每一步的真实耗时记下来，加起来那个数字才是你的 RTO，写在预案里的那个不是。

第一次跑基本都会翻车，高频的是证书没续期、脚本里路径写死、某个内部服务硬编码了 CDN 域名。还有一点容易被跳过：别只演练"切出去"，"切回来"往往更容易出问题——缓存要重新回填，回源白名单要恢复，这半程被省略的次数比想象中多。

 

头部边缘网络的可用性已经远高于绝大多数自建方案，该用还是要用。只是任何一层都有失效的时候，差别在于失效那天你有没有第二条路，以及那条路是不是真的走得通。后半句往往才是真正出问题的地方。

SellBGP 的香港服务器部署于香港 HGC、WTT 数据中心，接入 CTGNet/CN2 GIA、HGC、HKBN 等多条回国线路，华南方向直连时延通常在十毫秒上下，华东、华北会高一些。配合高防服务器与高防 IP，可以把"前置层"和"源站层"拆成两条相互独立的链路，避免一处失效就全线中断。

FAQ

备用直连入口会不会被搜索引擎抓到，影响 SEO？

有这个风险，但可控。在备用主机名上加 X-Robots-Tag: noindex 响应头，或用 robots.txt 禁止抓取，同时主域名保持规范的 canonical 标签。真正切换期间改的是主域名的解析指向，用户和搜索引擎访问的仍然是主域名，不会产生重复内容问题。

切成直连之后，回国速度会不会变慢？

要分开看。静态资源大概率变慢，因为丢了边缘缓存；动态接口反而常常更快——动态请求本来就要回源，走 CDN 多一跳中转本身就有开销，而香港到内地物理距离短，CN2 GIA 这类优化线路直连的时延通常优于绕行海外节点。真正需要提前评估的是源站带宽够不够，而不是速度。

能不能同时挂两家 CDN 做冗余？

技术上可以，但别当成默认答案。两家 CDN 的缓存策略、真实 IP 头字段、WAF 规则往往不一致，日常维护是双份的，排障时还要先确认用户走的是哪一家，成本和复杂度都会明显上去。对中小站点，更划算的组合通常是"一家 CDN + 源站自身具备防护能力"，也就是把冗余做在层与层之间，而不是在同一层里堆两家。