CloudFlare宕机, 半个互联网崩了

JustYY.com 小赖子的英国生活和资讯

3 months ago

今天的 Cloudflare 宕机：一次震撼全球的“单点故障”

今天早上，我突然收到了一大堆报警，我手下的15个网站都报警了，收到了很多邮件，这很不正常，有的时候是报警的程序自己的问题，因为其中的一个邮件报警是我自己写的。但是我核实了一下，确实打不开，显示是500服务器内部错误，这个错误一般就是服务器配置错误崩溃造成的。但我细眼一看，是CloudFlare的服务器的问题。这可是我第一次见。

Cloudflare 已经是互联网基础设施级服务，一旦宕机影响面巨大。这次事故暴露了去中心化互联网在实际运行中高度中心化的问题。

CloudFlare按现在最新数据，有750万个网站，排名/流量最高的1万个中有33%是用CloudFlare，所以这次宕机的影响之深，还好，这次友宕机也就三个小时左右，这次宕机影响到了很多服务，其中X和ChatGPT都打不开了，中间还陆陆续续间断的恢复过几分钟时间。

18 日，全球知名的网络基础设施服务商 Cloudflare 发布公告称，其全球网络出现大范围异常，导致大量网站和应用出现访问中断。受影响的平台包括 X（前 Twitter）、ChatGPT 等多家核心互联网服务，有媒体报道称 Spotify、亚马逊部分服务也出现了故障。

受此次事故影响，Cloudflare 股价在盘前一度下跌超过 5%。

按照官网介绍，Cloudflare 是一家全球性的云网络平台，为各类规模的企业提供安全加速、内容分发、DNS、零信任等服务。其数据传输网络覆盖全球 125 个国家、330 座城市，是互联网“入口层”的关键基础设施之一。Cloudflare 于 2019 年 9 月 13 日在纽约证券交易所上市。

北京时间 19:17（伦敦时间 11:17），Cloudflare 状态页显示，其支持门户出现故障，客户在查看或回复支持工单时可能遇到错误。大约半小时后，Cloudflare 再次更新称公司正在经历“内部服务故障”，部分服务可能会出现间歇性异常。

又过了约 20 分钟，Cloudflare 表示整体中断情况已开始缓解，但仍在调查问题根源。至北京时间 21:13，官方最新状态指出，部分服务的错误率“已恢复到事件发生前的水平”，同时团队正在继续恢复其余受影响的服务。

X、ChatGPT 等多个互联网平台仍受到此次故障影响。X 上用户的帖子会显示“无法载入”等提示，访问仍不稳定。

Cloudflare 历史关键时间线

2009：Cloudflare 成立（创始人：Matthew Prince、Lee Holloway、Michelle Zatlyn）。
2010–2015：从 CDN 起家，加入 DDoS、防火墙、DNS、边缘计算等产品。
2019-09-13：Cloudflare 在 NYSE 上市，代码 NET。
2020–2024：推出 1.1.1.1、Zero Trust、Workers、R2 等，逐步成为互联网“前门”。
市场占有率：全球流量最高前 10,000 个网站中约三成使用 Cloudflare（各统计口径有差异，约在 30% 左右）。

技术分析：为什么会看到 Cloudflare 返回 500

1. Cloudflare 的基本工作方式

用户访问域名 → DNS 指向 Cloudflare Anycast 边缘/Edge节点。
Cloudflare 作为反向代理：处理缓存、加速、TLS、WAF、Workers。
然后 Cloudflare 再把请求转发给源站（origin）。

2. 边缘节点返回 500 的常见原因

源站真实返回 500：Cloudflare 将错误透传。
Cloudflare 内部组件异常：代理池、缓存层、Workers、WAF 崩溃导致边缘自身返回 5xx。
边缘与源站连接失败：握手超时或连接异常，本应返回 502/524，但部分情况可能回落为 500。
SSL/TLS 配置冲突：证书或协议版本不匹配导致处理失败。
Workers 运行异常：未捕获异常直接导致 500。

3. Cloudflare 常见错误码对照

编码	说明
500	通用错误，source 或 Cloudflare 本身都可能产生。
502	Bad Gateway，Cloudflare→源站连接问题。
520	源站返回空或格式不正确的响应。
521	源站拒绝连接。
522	Cloudflare→源站连接超时。
524	源站处理超时。

4. 工程上如何确认是 Cloudflare 问题

绕过 Cloudflare 测试源站：

curl -I -H "Host: yourdomain.com" http://YOUR_ORIGIN_IP

看响应头是否含 server: cloudflare 或 cf-ray。
查看 Cloudflare 状态页：https://www.cloudflarestatus.com/
如使用 Workers，检查日志与堆栈信息。
必要时暂停 Cloudflare（“Pause Cloudflare on Site”）并确认源站可用性。

5. 为什么故障影响面巨大

大量网站的 DNS + 代理都托管在 Cloudflare。
Cloudflare 是“入口层”，入口挂了源站再健康也没办法。
对许多服务来说，Cloudflare 就是互联网对外公开的“唯一入口”。

工程建议（可实践）

多 DNS、多 CDN 架构：降低对单一供应商的依赖。
开启缓存 fallback：为内容站点提供 Always Online 类体验。
健康检查 + 自动切换：重要 API 建议多云部署。
边缘脚本不要走关键路径：Workers 出错会影响所有请求。
制定应急回滚流程：包括 DNS 回滚、IP 直连、信息通告模板等。

快速诊断手册（给工程师）

绕过 Cloudflare 访问源站：确认是否是源站本身故障。
查看响应头是否含 Cloudflare 标识。
查看 status 页面是否有大规模宕机。
用不同地区的 curl/Pingdom/UptimeRobot 对比确认是否是区域性还是全球性问题。

再强的基础设施也会宕机。互联网架构虽然理论去中心化，但现实中高度依赖少数大型服务商。

前几周的AWS因为dynamodb的DNSRace Condition的BUG，也是影响了互联网大半个江山，因为都是互联网基础服务，不过CloudFlare更是，因为从用户在浏览器打域名后，CloudFlare就接管了，只是到最后面的服务器不是在CloudFlare，前面的流量都被CF牢牢控制。从另一个角度也说明了CF的重要性，掌握了入口和流量。

这次 Cloudflare 宕机是一次非常典型的 “单点故障课” – Single Point of Failure。