讨论 就在刚刚Cloudflare全球大规模报错

域名讨论相关内容
C

C

NameTube.com
站长
管理员
UID
3

事情经过​

在 2025-11-18 11:47 UTC 前我就遇到多个网站打不开的情况，我就怀疑是CloudFlare香港节点有问题。
1763479841556.png


去 CloudflareStatus.com 看了，以为只是香港的寻常维护导致的。
1763479960261.png

但是也不应该导致ERR500，直接无法访问，因为根据他们说的，应该会 重新路由(reroute)流量。
一分钟之后，Cloudflare 就更新了最新情况，并确认是全球的Cloudflare 网络问题。

1763479941442.png

在全面恢复Cloudflare 最重要的网络服务前，其中有多次的短暂恢复。
1763480197314.png

最终在 14:42 UTC，解决了对外的公共CDN, Proxy服务。全面回复。
但是截至15:35UTC，Cloudflare Dashboard 后台面板仍然未解决。
15:38UTC，可以正常加载Dashboard 内容，但仍然出现卡顿情况。

影响​

Cloudflare 是现金互联网的基于反向代理的内容分发网络的美国公司，许多你所使用的服务都依赖Cloudflare 提供的互联网保护。包括但不限于：X、ChatGPT、Spotify、LOL、Claude、Canva、Uber等等一众大公司的服务。
在此同时，通过DownDetector可见，与Cloudflare全球网络问题同时出现了其他服务的downtime，基本可以肯定那些公司或多或少使用了Cloudflare的CDN、代理，或甚至只是嵌入了cloudflare的js或者CAPTCHA服务就可以导致服务不可用。
1763480728868.png

Cloudflare 的Dashboard 与Support Portal 都加载超时，除Business和Enterprise用户外可以通过LiveChat和热线联系Cloudflare以外，其他方案的用户只能等待Cloudflare网络修复完成，只能通过CloudflareStatus.com 查看问题进度。
1763480722800.png

即使CloudflareStatus.com应该未使用Cloudflare CDN、Proxy服务，但也出现了 CSS 链接受损的情况。CloudflareStatus 是由 atlassian.com 提供的一项即时服务状态更新网页的服务。Atlassian 应该没有使用 Cloudflare 的服务，而是相对独立自主的 Status Page。

思考​

现在许多大公司网站都使用Cloudflare，包括我自己在内，100个网站，101个都使用Cloudflare Proxy，既可以提升国际速度又可以保护源IP。
但通过这一次事件，我们见识到当巨头Cloudflare 一旦出现网络问题，我们自己的所有网络服务都可能失去联系。
举一个很有意思的例子，如果使用Cloudflare的ChatGPT因为Cloudflare问题而无法链接，那么Cloudflare的员工也无法使用ChatGPT来排解问题；又或者，如果Cloudflare的员工需要由A点联系B点的员工，（假如）WhatsApp、Telegram或其他聊天软件都使用了 Cloudflare的CDN、Proxy，或者只是Cloudflare的CAPTCHA验证，都有可能导致聊天软件无法使用。
通过这次事件，我想带出三点：Isolation分离、Independence自主、Loop循环。
Isolation 分离，是指 Cloudflare 核心网络服务 与 CloudflareStatus的分离，这一点Cloudflare做到了；假如CloudflareStatus也使用Cloudflare 网络的CDN，Proxy，很有可能连状态页面我们也看不到🤣。
Independence 自主，即使Cloudflare这些现成的网络分发服务、网络保护服务很棒，作为一家成熟的网络公司还是需要有自己的 Failover，Single Point of Failure (SPOF) 的Plan B，后备方案。同时，对于站长来说，如出现这种Web渠道的不可用时，我们应该提供Web以外的联系方式，确保能够在适当时间内回复客户、安抚情绪，
Loop 循环，这一点是我在半年前已经想讨论的，不过一直没有写博文。在这事件中，通过访问不同站点出现了Cloudflare的错误页就可以得知该网站使用了cloudflare服务。有些站长想修改NS，使网站不再经过Cloudflare网络，以短暂恢复可用性，但如果这些站长的域名的注册商（管理平台）使用了Cloudflare，那么他们则也无法登入管理平台以修改NS。不意外，这些使用Cloudflare的注册商其中包括 Netim.com、Dynadot.com等等。他们在此之际，只能干等Cloudflare的恢复，因为他们无法联系注册商的LiveChat或者提交tickets，也不一定记得注册商的电话、邮件地址。
实际上，以上这三点在许多时候都是环环相扣的。

真正的原因 - 2025-11-20 更新​

根据Cloudflare与媒体发布的说明，核心原因如下：
  • 事件最初源于 Cloudflare 监测到某个服务出现 “异常流量激增”。
  • 公司表示此次故障 并非网络攻击 所致。
    技术上：
  • Cloudflare 用于处理“威胁流量”（如机器人验证、反滥用挑战等）的 配置文件体量意外膨胀，超出了系统预期。
  • 这个过大的配置文件触发了系统中一个潜伏的软件缺陷，导致负责处理流量的关键组件发生崩溃。
  • 更具体地说：
    • 其 “Bot Mitigation / 挑战系统” 中存在一个隐藏 bug，本是日常的配置更改，却触发了这个 bug。
    • 崩溃随后产生连锁反应，引发多个 Cloudflare 服务大范围失效。

可能，不一定不是网络攻击​

2个月前，cloudflare也被报道服务不可用。在这次事件当天，多家媒体报道了 Cloudflare 股价在宕机当天出现下跌：
  • 《金融时报》指出：Cloudflare 股价在当天 “下午交易时段下跌约 1.4%”。
  • Yahoo Finance 的报道称：宕机事件使 Cloudflare 的股价在交易中“下跌了约 4%”。
  • 市场分析提到：Cloudflare 股价过去一年波动很大（超过 24 次单日 >5% 波动），但此次跌幅依然“具有意义”，虽然尚不足以改变市场对其长期业务的看法。
然而，cloudflare称这次不是由于网络攻击。不得不进一步引发我的猜想。
有可能是为了让外界（业界、顾客）安心，证明其抗打能力仍然值得信赖，这亦间接或直接影响股价，最终都影响公司声誉、收益。
正如我上面提到的三点 IIL (Isolation,Independence,Loop)，在俩个月后再发生全球规模的服务不可用，而且这次事件的全球经济损失是以秒级计算的，不少公司应该会重新考虑failover、业界也认识到这家全球最大的防DDoS攻击公司就是一个最大的SPOF，对于cloudflare的信赖、依赖会在小程度上降低。并且会考虑更多备用方案，例如如何在类似事件时在（使用cloudflare的）域名注册商更改NS，以备用线路确保消费者的正常存取。
 
最后编辑：
您必须登录或注册才可回复。
后退
顶部