18 个月内 4 次重大故障，中心化困局为何难解？

来源：rekt news

编译：Saoirse，Foresight News

2025 年 11 月 18 日，美国东部时间上午 6 点 20 分。我们中的许多人都遭遇了网络中断。

并非渐进式中断，也没有任何预警信号。前一秒你还在刷手机、进行交易、与人工智能聊天，下一秒，目光所及之处，几乎全是 500 错误页面。

推特在发推途中突然陷入瘫痪，ChatGPT 在对话到一半时停止响应，Claude 则直接卡住。

就连 Downdetector—— 那个当所有平台都出故障时，你会去查询故障情况的网站 —— 也无法加载，无法告诉你「所有服务都已瘫痪」。

全球 20% 的网络就这样凭空消失，只因本应保护互联网免受攻击的 Cloudflare，意外「攻击」了它自己。

一次常规的配置变更（数据库权限更新）触发了其机器人防护系统中的一个隐藏漏洞，转瞬之间，这位「守门人」竟将所有人都拒之门外。

10 月份，当亚马逊云服务（AWS）导致 Coinbase 下线时，加密货币领域的推特用户还在大肆嘲讽「中心化」的弊端。

可到了 11 月 Cloudflare 故障爆发时呢？至少在最初的几个小时里，整个加密圈鸦雀无声。

毕竟，当推特所依赖的基础设施都已瘫痪时，你根本没法在推特上讨论「基础设施脆弱性」这个话题。

多项关键服务陷入停滞（交通站点系统瘫痪），部分企业的网络界面出现故障，Arbiscan、DeFiLlama 等区块链浏览器也接连弹出 500 错误—— 但区块链本身并未出现任何共识中断的迹象。

当你所标榜的「去中心化」革命，竟会因为一家公司的配置文件体积过大而无法运转时，真正掌控全局的究竟是谁？

故障时间线：从「配置变更」到「全网瘫痪」

UTC 时间 11:05：数据库访问控制变更部署完成。

23 分钟后，即 UTC 时间 11:28，变更覆盖至用户环境，用户的 HTTP 流量中首次出现错误记录。

换句话说：故障已经发生，只是当时没人知道问题出在哪。

截至 UTC 时间 11:48，Cloudflare 官方状态页面终于承认「内部服务出现故障」—— 这种企业话术的真实含义是：「一切都乱套了，而且所有人都看得出来。」

连锁反应来得猝不及防：此次变更破坏了 Cloudflare 的机器人管理层，当系统加载一个体积翻倍的功能文件时，其代理服务直接「宕机」。

下游系统随之崩溃：Workers KV（键值存储服务）与 Access（访问控制服务）无法连接到代理；全网错误率飙升，随着监控工具负载骤增，CPU 使用率也突破峰值。

流量仍在不断涌入 Cloudflare 的边缘节点—— 但代理服务已无法做出任何响应。

Cloudflare 起初以为自己正遭受攻击，而且是一场超大规模的分布式拒绝服务（DDoS）攻击。

更诡异的是，就连完全托管在 Cloudflare 基础设施之外的官方状态页面，也同步陷入瘫痪，工程师们因此怀疑：这是一场针对其核心系统与监控体系的协同攻击。

但事实并非如此。他们没有遭到外部攻击，问题出在自己身上。

服务恢复后不久，Cloudflare 首席技术官（CTO）Dane Knecht 便发布了公开道歉声明，称此次事件「完全不可接受」，并将故障原因归咎于一次常规配置变更 —— 正是这次变更触发了机器人防护层的崩溃。

「我们辜负了客户，也辜负了更广泛的互联网用户，」Knecht 在声明中写道，「支撑我们机器人防护功能的某项服务中存在一个潜在漏洞，在一次常规配置变更后突然崩溃，并引发了我们的网络及其他服务的大面积故障。这并非一次外部攻击。」

故障高峰期，Downdetector 平台收到的故障报告多达 11183 份。

这场「数字黑暗」持续了超过 5 个半小时，直至 UTC 时间 17:06，服务才完全恢复；不过早在 14:30，全球部署正确的机器人管理配置文件后，最严重的影响已得到缓解。

故障冲击：从 Web2 到加密领域，无一幸免

Web2 平台首当其冲

X 平台收到了 9706 份故障报告。

用户没有看到熟悉的时间线，取而代之的是「哎呀，出了点问题」的错误提示。

ChatGPT 在对话中途突然「沉默」，不再响应任何指令。

Spotify 流媒体服务中断，Canva 设计平台将设计师拒之门外，Uber 与 Door Dash（外卖平台）也相继出现功能异常。

就连游戏玩家也未能幸免，《英雄联盟》玩家在游戏中途遭遇强制断线。

甚至有消息称，麦当劳的自助点餐机也弹出了错误界面—— 午餐高峰期与基础设施故障撞个正着。

加密货币领域同样未能「独善其身」。

加密平台大面积停摆

Coinbase 前端彻底崩溃，用户面对的只有无法加载的登录页面。

Kraken 的网页端与移动应用双双「阵亡」—— 这正是 Cloudflare 全球故障的直接后果。

BitMEX 在其状态页面发布公告：「正在调查故障原因，平台性能下降，但用户资金安全无虞。」—— 同样的剧本，只是换了一家交易所。

Etherscan 无法加载，Arbiscan 直接宕机。

DeFiLlama 的数据分析面板间歇性出现内部服务器错误。

甚至 Ledger 也发布公告称，受 Cloudflare 故障影响，部分服务的可用性下降。

唯一的「例外」：区块链协议本身

但以下系统并未受到影响：

据报道，币安、OKX、Bybit、Crypto.com、KuCoin 等主要交易所未出现前端故障，链上交易正常进行 —— 与此同时，区块链本身保持完全正常运转，没有任何共识中断的迹象。

区块链协议始终独立运行 —— 问题并非出在链上，而是出在人们用于访问区块链的 Web2 基础设施上。

如果区块链仍在运转，却没人能访问它，那么加密货币真的还「在线」吗？

深度解析：一个数据库查询，为何搞瘫 20% 的网络？

Cloudflare 并不托管网站，也不像 AWS 那样提供云服务器服务。

它的角色是「中间人」—— 介于用户与互联网之间，为 2400 万个网站提供服务，通过遍布 120 个国家、330 座城市的节点，处理着全球 20% 的网络流量。

Cloudflare 的宣传话术 是这样的：它将自己定位为「互联网的防护盾与加速器」，提供全天候 DDoS 防护、机器人防护、流量路由、全球 Web 应用防火墙（WAF）、TLS 终止、基于 Workers 的边缘计算以及 DNS 服务 —— 所有功能均运行在统一的「安全 - 性能」网络上。

而实际情况是：它在 DDoS 防护领域占据 82% 的市场份额，边缘节点总带宽达 449 太比特 / 秒（Tbps），与全球众多主流互联网服务提供商（ISP）及云服务商相连。

问题的核心在于：当中介机构失效时，其背后的所有服务会同时变得「触不可及」。

Cloudflare 首席技术官 Dane Knecht 在 X 平台上直言不讳地表示：

「我就直说了：今天早些时候，由于 Cloudflare 网络出现问题，大量依赖我们的流量受到影响，我们辜负了客户，也辜负了更广泛的互联网用户。」

CEO Matthew Prince 的表述则更为直接：

「今天是 Cloudflare 自 2019 年以来最严重的一次故障…… 过去 6 年多里，我们从未发生过能导致大部分核心流量无法通过我们网络传输的故障。」

故障的技术根源

一切始于一次常规的数据库权限更新。UTC 时间 11:05，Cloudflare 对其 ClickHouse 数据库集群进行了一次变更，目的是提升安全性与可靠性 —— 让原本拥有「隐式访问权限」的用户，能够「显式」看到表元数据。

问题出在哪？生成 Cloudflare 机器人防护服务配置文件的数据库查询，没有对「数据库名称」进行过滤。

负责管理威胁流量的查询语句开始返回重复条目 —— 一份来自默认数据库，另一份来自底层的 r0 存储数据库。这导致功能文件的体积翻倍，从原本约 60 个特征，增至 200 多个特征。

Cloudflare 曾为内存预分配设置了 200 个特征的硬编码上限，并认为「这远高于我们当前约 60 个特征的实际使用量」。这是典型的工程思维：设置一个自认为「足够宽松」的安全边际，直到意外发生。

体积超标的文件触发了这一上限，Rust 代码直接崩溃，报错信息为：「thread fl2_worker_thread panicked: called Result::unwrap () on an Err value」（fl2_worker_thread 线程崩溃：在错误值上调用了 Result::unwrap () 方法）。

机器人防护系统是 Cloudflare 控制层的核心组件。它一旦崩溃，用于告知负载均衡器「哪些服务器正常运行」的健康检查系统也随之「失灵」。

更糟的是：这份配置文件每 5 分钟会重新生成一次。

只有当查询语句在「已更新的集群节点」上运行时，才会生成错误数据。因此，每 5 分钟，Cloudflare 的网络就会在「正常」与「故障」之间反复切换 —— 时而能加载正确文件，时而加载错误文件。

这种「反复横跳」让工程师们误以为正遭受 DDoS 攻击 —— 内部错误通常不会导致系统「恢复又崩溃」的循环。

最终，所有 ClickHouse 节点都完成了更新，每次生成的文件都是错误的。「反复横跳」停止了，取而代之的是「彻底、稳定的故障」。

没有准确的系统信号，系统便默认进入「保守模式」，将大部分服务器判定为「不健康」。流量不断涌入，却无法被正确路由。

Cloudflare 的边缘节点能接收到用户的请求 —— 却无法对请求做任何处理。

「这并非一次外部攻击，」Knecht 特反复强调，「没有恶意行为，也不是 DDoS 攻击。只是一次数据库查询遗漏了过滤条件，恰好与权限更新撞在了一起，最终引发了故障。」

Cloudflare 曾承诺「99.99% 的可用性」—— 但这一次，承诺并未兑现。

事实确实如此。

历史重演：18 个月内 4 次重大故障，中心化困局为何难解？

2025 年 10 月 20 日——AWS 故障持续 15 小时。美国东部 1 区的 DynamoDB 数据库 DNS 解析失败，导致 Coinbase 冻结、Robinhood 卡顿、Infura 服务中断（进而影响 MetaMask），Base、Polygon、Optimism、Arbitrum、Linea、Scroll 等区块链网络全部下线。尽管用户资金在链上安全无虞，但很多人看到的账户余额却是「零」。

2025 年 10 月 29 日—— 微软 Azure 故障。Azure Front Door（前端门户）出现配置同步问题，导致 Microsoft 365 办公套件下线、Xbox Live 服务瘫痪、企业服务中断。

2024 年 7 月——CrowdStrike（安全公司）的 Windows 更新包存在漏洞。此次故障导致航班停飞、医院医疗流程延误、金融服务冻结，完全恢复耗时数日。

2022 年 6 月——Cloudflare 上一次重大故障。多家加密交易所被迫暂停服务 —— 同样的模式，只是换了一年。

2019 年 7 月——Cloudflare 更早的一次故障。Coinbase 下线，CoinMarketCap 无法访问 —— 这是第一个被所有人忽视的「警告信号」。

短短 18 个月内，就发生了 4 次重大基础设施故障。

四次故障，传递的是同一个教训：中心化基础设施，必然导致「中心化故障」。

四次故障，本可以让加密行业加速向去中心化转型 —— 但它至今仍依赖三家公司提供的基础设施。

要经历多少次警告，行业才会从「假设故障可能发生」，转变为「按故障必然发生的标准来构建系统」？

去中心化的「谎言」：协议去中心化，不代表访问去中心化

他们曾向你描绘这样一幅蓝图：

「去中心化金融、抗审查货币、无需信任的系统、无单点故障、「不是你的私钥，就不是你的币」、代码即法律。」

11 月 18 日的现实却给了一记重击：Cloudflare 一个上午的故障，就让加密行业的部分服务停摆了数小时。

技术层面的真相：

没有任何区块链协议被报道出现故障。比特币网络正常运行，以太坊网络也正常运行 —— 链本身没有任何问题。

实际使用中的现实：

交易所界面崩溃、区块链浏览器瘫痪、钱包接口失效、数据分析平台宕机、交易界面弹出 500 错误。

用户无法访问自己本应「拥有」的「去中心化」区块链。协议本身运转正常 —— 前提是你能「触达」它。

以下这些言论，或许会让很多人感到刺耳……

SovereignAI 首席运营官（COO）David Schwed 毫不留情地指出：

「如今 Cloudflare 故障，几周前 AWS 故障，这充分说明：我们不能简单地将基础设施的『抗故障能力』外包给单一供应商。如果你的机构需要 24 小时不间断运行，就必须按照『故障必然发生』的标准来构建基础设施。如果你的业务连续性计划只有『等待供应商恢复服务』这一条，那就是纯粹的疏忽。」

「纯粹的疏忽」—— 不是意外，不是疏漏，而是疏忽。

Jameson Lopp 的评价一针见血：

「我们拥有一项出色的去中心化技术，却因为将大部分服务集中在少数几家供应商手中，让它变得极度脆弱。」

Ben Schiller 在 AWS 上次故障时说过的话，如今同样适用：

「如果你的区块链会因为 AWS 故障而下线，那它根本不够去中心化。」

把「AWS」换成「Cloudflare」，问题本质完全相同 —— 行业从未吸取教训。

为何选择「便利」而非「原则」？

自建基础设施意味着：购买昂贵的硬件、保障稳定供电、维护专属带宽、雇佣安全专家、实现地理冗余、搭建灾备系统、24 小时监控 —— 每一项都要投入大量资源。

而使用 Cloudflare 只需：点击一个按钮、输入信用卡信息、几分钟内完成部署。

DDoS 防护由别人负责，可用性由别人保障，扩容由别人操心。

初创公司追求「快速上市」，风投机构要求「资本效率」—— 所有人都选择了「便利」，而非「抗故障能力」。

直到「便利」不再便利的那一刻。

10 月的 AWS 故障，引发了推特上关于「去中心化」的无休止讨论。

11 月的 Cloudflare 故障呢？鸦雀无声。

不是出于「哲学层面的沉默」，也不是「深思后的安静」。

而是因为：人们想吐槽，却发现自己常用的吐槽平台（推特），也因基础设施故障而瘫痪。

当「单点故障」恰好是你用来嘲讽「单点故障」的平台时，你根本无从吐槽。

当访问层依赖三家公司的基础设施，其中两家还在同一个月内发生故障时，「协议层面的去中心化」毫无意义。

如果用户无法触达区块链，那我们所谓的「去中心化」，究竟是在「去中心化」什么？

垄断困局：三家公司掌控 60% 云市场，加密行业何去何从？

AWS 掌控着全球约 30% 的云基础设施市场，微软 Azure 占 20%，谷歌云占 13%。

三家公司，掌控着支撑现代互联网的 60% 以上云基础设施。

加密行业本应是「中心化」的解决方案，如今却依赖着全球最中心化的基础设施。

加密行业的「中心化依赖清单」

• Coinbase —— 依赖 AWS；
• 币安、BitMEX、火币、Crypto.com —— 均依赖 AWS；
• Kraken 虽基于 AWS 构建基础设施，却仍因 Cloudflare 的 CDN（内容分发网络）故障受到冲击。

许多标榜「去中心化」的交易所，实则运行在中心化的基础设施之上。

10 月与 11 月的故障，还有一个关键区别：

AWS 故障时，X 平台（原推特）仍能正常运行，加密圈的推特用户得以大肆嘲讽「基础设施脆弱性」。

而 Cloudflare 故障时，X 平台也随之下线。

当你用来「嘲笑单点故障」的平台，本身就是「单点故障」的一部分时，你根本笑不出来。

这种讽刺感，让本应展开的行业讨论从一开始就陷入停滞。

30 天内三次重大故障，监管机构已对此高度关注。

监管层需正视的核心问题

• 这些公司是否属于「具有系统重要性的机构」？
• 互联网骨干服务是否应纳入「公用事业式监管」？
• 当「大到不能倒」的属性与科技基础设施结合，会引发怎样的风险？
• 若 Cloudflare 掌控着全球 20% 的网络流量，这是否构成垄断问题？

第 19 条组织的 Corinne Cath-Speth 在 AWS 上次故障时就直言不讳：「当一家供应商陷入瘫痪，关键服务也会随之下线 —— 媒体无法访问，Signal 等安全通信应用停止运转，支撑数字社会的基础设施分崩离析。我们迫切需要实现云计算的多元化。」

换句话说：各国政府正逐渐意识到，少数几家公司就足以让互联网陷入停滞。

其实，去中心化的替代方案早已存在，只是无人愿意采用。

比如用于存储的 Arweave、用于分布式文件传输的 IPFS、用于计算的 Akash、用于去中心化托管的 Filecoin。

去中心化方案为何「叫好不叫座」？

性能落后于中心化方案，延迟问题用户能直接感知。

普及率极低，与「点击『部署到 AWS』」的便捷体验相比，去中心化方案的用户操作流程显得繁琐复杂。

成本往往高于从「三巨头」（AWS、Azure、谷歌云）租赁基础设施。

现实是：

构建真正的去中心化基础设施难度极大，远超想象。

大多数项目只把「去中心化」挂在嘴边，却很少真正落地。选择中心化方案，始终是更简单、更廉价的选项 —— 直到 18 个月内 4 次故障发生，人们才意识到「简单廉价」背后隐藏着巨大代价。

OORT 首席执行官 Max Li 博士在近期 CoinDesk 的专栏文章中，直指行业的虚伪性：

「对于一个以『去中心化』为荣、不断宣扬其优势的行业而言，却将自身基础设施严重依赖于脆弱的中心化云平台，这本身就是一种虚伪。」

他提出的解决方案是：采用混合云策略，让交易所将关键系统分散部署到去中心化网络中。

中心化云平台在性能与规模上的优势，始终有其不可替代性 —— 但当涉及数十亿美元资金、每一秒交易都至关重要时，其抗故障能力远不及分布式方案。

只有当「便利」的代价惨重到足以改变行业行为模式时，「理念」才会战胜「便利」。

显然，11 月 18 日的故障还不够惨重，10 月 20 日的 AWS 故障也不够，2024 年 7 月的 CrowdStrike 故障同样不够。

要到何种地步，「去中心化基础设施」才会从「话题谈资」转变为「硬性要求」？

11 月 18 日，加密行业并未「失败」—— 区块链本身运转完美。

真正「失败」的，是行业集体自欺欺人的谎言：以为能在「可瘫痪的基础设施」上搭建「不可阻挡的应用」；以为当三家公司掌控着「访问通道」时，「抗审查」还有实际意义；以为当 Cloudflare 的一份配置文件就能决定数百万人能否交易时，「去中心化」还算得上真正的去中心化。

如果区块链仍在生成区块，却没人能提交交易，那它真的算「在线」吗？

行业没有任何应急预案。

出故障了，只能等 Cloudflare 修复，等 AWS 恢复服务，等 Azure 部署补丁。

这就是当前行业的「灾难恢复策略」。

不妨设想一下：若数字身份与区块链深度绑定，会发生什么？

美国财政部正推动将身份凭证嵌入智能合约，要求每一次 DeFi 交互都必须通过 KYC 审核。

当下一次基础设施故障发生时，用户失去的将不只是交易权限 —— 还会失去在金融系统中「证明自己身份」的能力。

原本 3 小时的故障，会变成 3 小时「无法加载的人机验证界面」—— 只因验证服务运行在已瘫痪的基础设施上。

监管机构想要搭建的「安全护栏」，前提是「基础设施始终在线」。但 11 月 18 日的故障证明，这个前提根本不成立。

当「过度监控」的问题变得显而易见时，科技从业者会转向「隐私保护」。

或许现在，是时候将「基础设施抗故障能力」也纳入这一范畴了。

它不应是「可有可无的加分项」，而应是「支撑一切的基础要求」—— 没有它，其他所有功能都无从谈起。

下一次故障已在酝酿之中 —— 可能来自 AWS，可能来自 Azure，可能来自谷歌云，也可能是 Cloudflare 的二次故障。

可能是下个月，也可能是下周。基础设施未变，依赖关系未变，行业激励机制也未变。

选择中心化方案，依旧是更廉价、更快速、更便捷的选项 —— 直到它不再是。

当 Cloudflare 下一次常规配置变更，触发下一个关键服务中的隐藏漏洞时，我们将再次目睹熟悉的「剧情」：满眼的 500 错误页面、交易全面暂停、区块链运转正常却无人能访问、想发推文讨论「去中心化」却发现推特已瘫痪、企业承诺「下次会做得更好」却从未兑现。

一切都不会改变，因为「便利」总能战胜「风险防范」—— 直到「便利」的代价大到再也无法忽视的那一天。

这一次，「守门人」瘫痪了 3 个半小时。

下一次，故障可能持续更久；下一次，故障可能发生在「每一秒交易都关乎生死」的市场崩盘时刻；下一次，身份验证系统可能也会被卷入故障之中。

当你赖以生存的基础设施，在你最输不起的时刻陷入瘫痪，这究竟是谁的错？

数据来源：《卫报》、乔尼・波波夫、《个人电脑杂志》、《IT 专业人士》、美国消费者新闻与商业频道（CNBC）、Cloudflare、TechCrunch、美联社新闻、CoinDesk、《汤姆硬件》、戴恩・克内希特、《汤姆指南》、苏里亚、绵羊电竞、TheBlock、Kraken（ kraken）、BitMEX、Ledger（莱杰）、区块链新闻、Statista（数据统计平台）、《嘶吼电脑》、詹姆森・洛普、本・席勒、第 19 条组织、CoinTelegraph（加密电报）