所有人都怪 Cloudflare，其实是 Zayo 的光缆断了
上周一，2026 年 6 月 22 日，大片网页同时开始超时。X、Zoom 以及 Google 和 Microsoft 的部分服务都被报告出现劣化，原因是北美东部一处光缆中断，位于 Zayo 的网络——那是屈指可数、不向任何人购买传输的 Tier 1 骨干之一。 1
不是软件缺陷，不是网络攻击，是一根被切断的光缆。
无论在报道里还是在社交媒体上，第一反应都是把它称作 Cloudflare 的故障。Cloudflare 的说法正相反，而且相当直白：它没有观察到自身的全球性中断，问题出在 Zayo 的路由上，仅依赖 Zayo 的站点无论是否使用 Cloudflare 都可能无法访问。 1 被报告出来的是错误率上升、延迟升高和间歇性超时，而不是一次干净利落的全球性失效。 1
这个时间点对我们来说有点尴尬：同一天上午，我们刚发了一篇关于物理路径多样性的文章，论点是所谓冗余连接常常并不冗余。而那个下午把这个论点讲得比文章本身还清楚。
没人画进图里的那一层
这件事有一个关于 Cloudflare 的版本，它既是流行版本，也是错误版本。Cloudflare 自己的立场是：问题不在它的网络，而是发生在它下面一层——一家位于许多网络（包括 Cloudflare 自己）之下的骨干运营商。
有意思的版本，是关于为什么所有人都猜错了。
单单一次光缆故障，本不该能够同时拖累 X、Zoom 以及 Google 和 Microsoft 的一部分。那些都是体量庞大、各自独立设计、资金充裕、并且拥有大型工程团队、都做过韧性规划的平台。它们一起劣化，是因为它们暴露在同一个依赖之下——一个位于应用之下、也位于 CDN 之下的依赖，而许多机构并不把它当成单点故障，因为它不是一台服务器，也不在他们的架构图上。
这才是 6 月 22 日真正的教训，而归因错误恰恰是它的证据。Cloudflare 是可见的：你选择它、配置它，它有控制面板和状态页，所以出事时它是第一个被想起的名字。传输是不可见的：几乎没有人选择自己服务商的服务商，也几乎没有人能说出自己的数据包在去往客户的路上跨过了哪条骨干。
反向代理、CDN 和 DDoS 清洗是一个集中的层，DNS 是它旁边另一个集中的层。而在这一切之下，是数量少得多的骨干网络——那一层集中得更彻底。
不是独立，只是不至于束手无策
冗余能解决的事情有限。你无法让一次骨干中断不发生，你也和那家出故障的运营商没有合同关系。目标不是消除依赖，而是在其中之一失效时仍然留有选择。
让你的源站保持可达。如果你的源站只接受来自 CDN IP 段的流量、没有别的入口，那你就无法从 CDN 上切走。请保留一条可用且经过验证的直连路径，哪怕它平时不服务任何人。
把 DNS 放在别处。如果你的 DNS 和你的反向代理是同一家厂商，那么它糟糕的那一天会同时拿走问题本身和你绕开问题的能力。这是可选的分离里价值最高的一项。
在事故之前就弄清楚你的 TTL。24 小时的 TTL 意味着无论你多快发现，你的切换都要花一天。
准备一个静态兜底：在另一个国家、另一家服务商那里放一个简单页面，说明正在发生什么。它几乎不花钱，而且正是客户在事故期间想要的东西。
然后演练它，因为一条从未执行过的切换路径只是一个假设。
我们能扮演的角色
我们是一家小型欧洲 ISP，而不是骨干，而恰恰在这里，一家小型独立服务商真正有用：我们是你兜底方案所在的地方。
在地拉那、斯科普里、阿姆斯特丹或都柏林的一台 €5/月 VPS，足以承载一个静态状态页、一台辅助 DNS 服务器、一条直达源站的路径，或者一套与你主栈既不共享控制平面、也不共享公司和大洲的冷备。完整 KVM 加 root 权限，包含 DDoS 防护，接受加密货币，无需 KYC，几分钟内跑起来。
对于希望把网络层掌握在自己手里的客户，AS210464 提供 €5/月 起的 BGP 会话、RPKI 验证，以及一套 community 集合，让你在我们的各个区域之间自行调度自己的宣告，包括在你需要于我们边缘而不是在你服务器上丢弃流量时的远程触发黑洞路由。
你也可以不用账号，自己通过 looking glass 观察我们的路径。请从你在意的网络分别 traceroute 到我们每一个站点，然后看看哪些网络出现在了每一条路径的中间。traceroute 不会显示 MPLS 跳、不对称回程，也不会显示路由器拒绝回应的部分，所以请把它当作第一眼，而不是一次审计。不过，一家出现在每条路径上的传输运营商，仍然值得在它遇上糟糕的一天之前先认识一下。
没人想要的那个教训
关于互联网韧性的说法一直是：数据包会绕开损坏。当损坏发生在一张网格的中间时，这是对的。当损坏发生在如今几乎一切都要经过的少数几条骨干之一时，这就远没那么对了。
6 月 22 日失效的那一层，没有控制面板，没有你订阅得到的状态页，也没有出现在你架构评审的任何一行里。这不是恐慌的理由，而是一个理由：在下一次断缆之前，先弄清楚你的流量依赖哪些网络——因为这个答案只要十分钟就能查到，而事故当中没有人会去查。
资料来源
- Cloudflare Outage: Fibre Cut in Eastern North America Triggers Internet Disruptions，Latestly，2026 年 6 月 24 日