2025年11月18日，Cloudflare 全球网络遭遇内部服务降级，导致广泛服务中断和高错误率。故障影响了包括 WARP 和 Cloudflare Access 在内的多项服务，伦敦地区的 WARP 访问一度被禁用。经过紧急修复，大部分服务已恢复，但事件凸显了全球网络基础设施的脆弱性。

Cloudflare 内部服务降级事件始末

2025年11月18日，对于依赖 Cloudflare 服务的用户而言，注定是感受到互联网“心跳骤停”的一天。这家作为全球网络基础设施关键角色的公司，其全球网络遭遇了严重的内部服务降级，直接导致了许多服务的间歇性中断和高错误率。

事件的最初通报出现在 UTC 时间 11:48，Cloudflare 官方发布了“Investigating”(调查中)的动态，承认正在经历一次“内部服务降级”，并告知部分服务可能受到间歇性影响，他们的重点工作是恢复服务。随后在 12:03 UTC 和 12:37 UTC，官方持续更新，表示仍在调查问题。

在 12:21 UTC 时，Cloudflare 发布了一则略微乐观的更新，称“正在看到服务恢复”，但同时也提醒客户在他们持续进行修复努力的同时，可能会继续观察到“高于正常水平的错误率”。这表明虽然部分系统已开始自行稳定或被动修复，但故障的根源尚未完全解决。

工程师的“救火”与伦敦 WARP 的失灵

随着调查的深入，技术团队在 12:53 UTC 和 13:04 UTC 继续更新，确认了仍在积极调查。然而，在修复过程中，一个临时性的“补救措施”被采纳，这也带来了局部服务的中断。在 13:04 UTC 的更新中，Cloudflare 明确指出，为了尝试缓解问题，他们不得不“禁用”了伦敦地区的 WARP 访问。对于身处伦敦并试图通过 WARP 连接互联网的用户，这直接表现为“连接失败”。这反映了工程师在处理核心故障时，可能需要暂时牺牲某些边缘服务的可用性，以防止问题蔓延或集中资源进行核心修复。

在随后的关键时刻，事情出现了转机。在 13:09 UTC，Cloudflare 宣布“问题已确定，正在实施修复”。这标志着工程团队已经定位了导致内部服务降级的具体原因，并着手进行代码或配置层面的纠正。

仅仅四分钟后，13:13 UTC 的更新显示修复工作卓有成效。Cloudflare 宣布：“我们所做的更改已使 Cloudflare Access 和 WARP 得以恢复。Access 和 WARP 用户的错误水平已恢复到事件前的速率。”更进一步，他们谨慎地“重新启用了伦敦的 WARP 访问”。尽管如此，官方依然表示他们“将继续努力恢复其他服务”，暗示着这次内部降级的影响范围超出了 WARP 和 Access。

https://www.cloudflarestatus.com/incidents/8gmgl950y3h7

“互联网已彻底瘫痪”：来自开发者的亲历

在 Cloudflare 工程师们忙于在数据中心和代码库中进行高强度“救火”时，互联网上的普通用户和开发者们则正在经历一场数字世界的“末日”。

一位名为 jongjong 的 Hacker News 评论者，在事件发生约 54 分钟前留下了近乎绝望的评论，生动地描绘了这种连锁故障的感受。jongjong 称当天“互联网已彻底瘫痪”。在工作期间，他们公司的平台遭遇问题。下班后，这位开发者决定进行年度维护，测试其开源库在最新的 Node.js 引擎上的兼容性。

灾难接踵而至：首先是依赖项(Dependencies)损坏，勉强升级依赖项后，又出现了一大堆“无理由”的测试失败，jongjong 怀疑是 Node.js 破坏了兼容性。作为一个低级套接字库的维护者，他们表示从未见过 Node.js 升级会带来如此多的问题。

当 jongjong 试图将更新后的库发布到 npm 时，直接遭遇了 Cloudflare 带来的障碍。他们被 Cloudflare 的人机验证(CAPTCHA)机制反复要求证明自己是人类，最终心力交瘁，不得不放弃。

带着对“软件末日”的愤懑，jongjong 转向社交媒体 Twitter X 抱怨，认为“版本号越高，软件就越差”。然而，连最简单的发帖动作也被阻挠，Twitter X 提示“出错了”(Something went wrong)。这一系列的失败，从底层系统到应用层，无不指向 Cloudflare 这次故障所带来的广泛影响。

https://news.ycombinator.com/item?id=45963949

Fastly 故障的经验教训与警示

虽然 Cloudflare 的这次事件正在调查中，但另一家 CDN 巨头 Fastly 过去的一次全球性故障，为理解这类“网络神经中枢”的脆弱性提供了深刻的背景和教训。一位评论者在此次 Cloudflare 事件下引用了 Fastly 官方对 2021 年 6 月 8 日事件的总结，虽然事件主体不同，但其机制具有高度的参考价值。

Fastly 的那次全球中断，是由于一个“未被发现的软件错误”在 6 月 8 日被一个“有效的客户配置更改”所触发。

在 Fastly 的时间线上，从“全球中断的初步发作”(09:47 UTC)到“Fastly 监控识别全球中断”(09:48 UTC)只用了一分钟。工程师在 10:27 UTC 确定了触发故障的客户配置，并在 10:36 UTC 开始恢复受影响的服务。在 49 分钟内，Fastly 网络的 95% 恢复正常。

Fastly 事后总结，那个潜伏的错误是在 5 月 12 日的一次软件部署中引入的，它需要在“特定客户配置”和“特定情况”下才能被触发。他们深表歉意，并提出了一系列的改进措施：

短期措施：尽快部署错误修复，对事件中的流程和实践进行完整的事件后分析(Post Mortem)，查明为何质量保证和测试流程没有发现该错误，并评估如何缩短修复时间。

长期方向：继续创新和投资于底层平台的安全性，特别是利用 WebAssembly 和 Compute@Edge 的隔离能力来构建更高的弹性。

Fastly 的经验表明，即使是看似微不足道的客户配置更改，也可能触发潜伏已久的软件逻辑漏洞，导致大规模的连锁反应。

https://www.fastly.com/blog/summary-of-june-8-outage


2025王摸鱼秋款卫衣，玩梗系列