一个小站的自留地
Cloudflare 全球网络遭遇故障,部分服务已恢复 据 Cloudflare System Status 页面显示,协调世界时(UTC)2025 年 11 月 18 日 11 时 48 分(北京时间 19 时 48 分),Cloudflare 遭遇内部服务降级,导致全球范围内的部分服务出现间歇性中断。 经过排查,官方确认了故障原因并开始实施修复。在此过程中,为了缓解问题,官方曾短暂禁用伦敦地区的 WARP 访问权限。截至 UTC 13 时 13 分(北京时间 21 时 13 分),Cloudflare…
Cloudflare 发布 18 日全球网络严重故障事故分析报告

Cloudflare 官方博客于 11 月 19 日发布事后分析报告,详细披露了前一日导致全球互联网大范围瘫痪的技术细节。故障始于 UTC 时间 11 月 18 日 11:20(北京时间 19:20),持续至 17:06 全部系统恢复正常。期间,核心 CDN 与安全服务、Workers KV、Access 以及验证码服务 Turnstile 均出现严重中断,导致包括 ChatGPT 在内的众多依赖其基础设施的网站无法访问,用户普遍遭遇 HTTP 5xx 错误。

官方明确指出,此次事故并非由 DDoS 攻击或其他恶意活动引起,而是源于内部 ClickHouse 数据库的一次权限管理变更。该变更旨在显化用户对底层基础表的访问权限,却意外导致机器人管理系统(Bot Management)的元数据查询返回了重复条目。这使得自动生成的威胁防御「特征配置文件」大小瞬间翻倍

由于核心代理服务(代号 FL2)为了性能考虑,采用了预分配内存的设计,并对特征数量设定了硬性上限。当体积异常的配置文件推送到全球边缘节点时,负责流量路由的 Rust 代码使用了 `.unwrap()` 方法来处理结果。该方法在遇到超出预期的错误状态(即文件大小超出限制)时,直接导致了进程崩溃(Panic),而非抛出可控的错误,最终引发了连锁反应。

在故障处置初期,由于 Cloudflare 托管在外部平台的状态页(Status Page)同时也因流量过载而瘫痪,加之故障特征与大规模网络攻击相似,运维团队曾一度误判。最终,团队通过停止生成错误文件并手动回滚至已知良好的旧版本文件恢复了核心流量。Cloudflare 表示后续将强化对内部生成配置文件的输入验证(将其视为不可信输入),增加全局终止开关,并全面审查核心模块的错误处理逻辑以防止类似单点故障再次发生。

Cloudflare Blog
 
 
Back to Top