首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >Cloudflare挂了,互联网近乎一半网站瘫痪,ChatGPT、Claude 等全歇菜!

Cloudflare挂了,互联网近乎一半网站瘫痪,ChatGPT、Claude 等全歇菜!

作者头像
Bug挖掘机
发布2026-03-18 15:25:22
发布2026-03-18 15:25:22
4650
举报
文章被收录于专栏:测试开发基础测试开发基础

大家好,我是洋子。昨天晚上8点左右,我用着ChatGPT,突然就进不去了,打开网页就提示报错

在这里插入图片描述
在这里插入图片描述

一开始我以为是我本地网络出问题了,调整了下VPN发现没有用,然后我访问了下报错当中的challenges.cloudflare.com的网站,提示500(Internal server error),这才意识到是这个网站挂了

在这里插入图片描述
在这里插入图片描述

可能还有小伙伴不知道Cloudflare是干什么的,Cloudflare主要提供CDN服务,CDN是一组分布在全球各地的服务器

它的核心作用是把网站、视频、图片、JS、CSS等内容缓存到这些服务器上。用户访问内容时,会优先从距离自己最近、网络延迟较低的CDN节点获取,而不是每次都从原始服务器拉数据

此次中断引发连锁反应,全球近半数互联网服务受到影响,包括社交媒体、人工智能平台、在线工具及游戏服务等大量网站出现访问错误或加载失败

比如AI圈的ChatGPT, Claude, Perplexity等,社交圈的X (Twitter), Spotify, Discord, Grindr等,游戏圈的英雄联盟, Minecraft服务器等。

事件完整时间线梳理

基于Cloudflare官方发布的博客以及各方报道,以下是本次事故的详细梳理情况:

  • 发生时间:2025年11月18日19:20 - 22:30(主要影响时段)。持续时长:核心故障持续约3小时,完全恢复正常耗时约6小时。
  • 影响范围:全球性。
  • 根本原因:非网络攻击。系内部数据库权限变更导致的一个“潜伏Bug”被触发,引发机器人管理(Bot Management)配置文件体积异常膨胀,导致全球节点软件崩溃。
  • 具体时间线: 19:05:Cloudflare工程师部署了一项关于ClickHouse数据库访问控制的变更。 19:28:变更生效,故障开始。 19:32-21:05:Cloudflare团队介入调查。 21:05:实施第一阶段缓解,但核心问题仍存在。 21:37:找到原因。 22:24:停止生成新的异常配置文件,并强制节点回滚到旧版正常文件。 22:30:核心服务恢复。 次日01:06:所有系统完全恢复正常。
在这里插入图片描述
在这里插入图片描述

此次问题的出现:导致了用了它 DNS 和 CDN服务的网站全部访问异常。简单说,用户找不到你的服务器在哪,就算找到了,静态资源也加载不出来

技术根因剖析

1.导火索:一个"善意"的数据库权限优化

  • 时间点:11:05 UTC
  • 操作:团队为提升 ClickHouse 数据库的安全性和可靠性,修改了权限管理系统
  • 目的:让分布式查询能在初始用户账户下运行,实现更精细的查询限制和访问控制

2.意外后果:特征文件爆炸式增长

  • Bot Management 系统:Cloudflare 使用机器学习模型识别恶意机器人,依赖一个"特征文件"(feature file)做判断
  • 问题根源:生成特征文件的 SQL 查询没有指定数据库名称:
代码语言:javascript
复制
SELECT
name,
type
FROM system.columns
WHERE
table = 'http_requests_features'
orderby name;
  • 权限变更的影响:变更后,查询同时返回了 default 和 r0 两个数据库的元数据,导致特征数量翻倍(从约60个暴增至超过200个)

3.最后一根稻草:硬编码限制

  • Bot Management 系统为性能优化,硬编码限制了特征数量为200个
  • 当膨胀的文件(>200特征)推送到全球服务器时,系统触发 panic 崩溃
  • Rust 代码中的 unwrap() 调用失败导致整个代理线程崩溃

有趣的故障现象

时好时坏的"波浪式"故障

  • 特征文件每5分钟生成一次
  • 由于 ClickHouse 集群是逐步更新的,每5分钟可能由"已更新节点"(生成坏文件)或"未更新节点"(生成好文件)执行查询
  • 结果:系统一会儿正常,一会儿崩溃,形成独特波动模式

误判为 DDoS 攻击

  • 故障症状类似超大规模 DDoS 攻击
  • 巧合的是,Cloudflare 状态页面(托管在 Cloudflare 基础设施之外)也在同一时间宕机
  • 这让团队一度怀疑是协同攻击

改进措施

Cloudflare 列出了四项核心改进方向:

  1. 将内部配置文件视为"用户输入":即使是自己生成的文件也要做严格校验
  2. 增加全局功能开关:快速关闭出问题的功能模块
  3. 优化错误处理:防止调试系统消耗过多 CPU 资源
  4. 全面审查故障模式:梳理所有核心模块的错误处理逻辑

总结与启示

深层问题:

  • 配置即代码?:Cloudflare 将配置文件视为动态数据,但代码中却有硬编码限制,两者脱节
  • 测试覆盖盲区:权限变更本身没问题,但未测试其对下游 Bot Management 系统的副作用
  • 级联故障:一个模块的 panic 拖垮了依赖它的 Workers KV、Access 等多个系统

经验启示:

  • 即使是"内部"数据也需要严格校验和边界检查
  • 硬编码限制必须配合完善的监控和快速回滚机制
  • 故障排查时,警惕"sunk cost fallacy"(前期误判 DDoS 可能浪费了宝贵时间)

最扎心的一句话:

"Today was Cloudflare's worst outage since 2019... An outage like today is unacceptable. We've architected our systems to be highly resilient to failure to ensure traffic will always continue to flow."

这次故障再次证明:在复杂分布式系统中,小的配置变更可能引发灾难性后果,而"百万分之一概率"的问题,在规模化下终将发生。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2025-11-19,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 测试开发Guide 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 事件完整时间线梳理
  • 技术根因剖析
    • 1.导火索:一个"善意"的数据库权限优化
    • 2.意外后果:特征文件爆炸式增长
    • 3.最后一根稻草:硬编码限制
  • 有趣的故障现象
    • 时好时坏的"波浪式"故障
    • 误判为 DDoS 攻击
  • 改进措施
  • 总结与启示
    • 深层问题:
    • 经验启示:
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档