事情经过
在 2025-11-18 11:47 UTC 前我就遇到多个网站打不开的情况，我就怀疑是CloudFlare香港节点有问题。去 CloudflareStatus.com 看了，以为只是香港的寻常维护导致的。
但是也不应该导致ERR500，直接无法访问，因为根据他们说的，应该会 重新路由(reroute)流量。
一分钟之后，Cloudflare 就更新了最新情况，并确认是全球的Cloudflare 网络问题。
在全面恢复Cloudflare 最重要的网络服务前，其中有多次的短暂恢复。
最终在 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服务就可以导致服务不可用。
Cloudflare 的Dashboard 与Support Portal 都加载超时，除Business和Enterprise用户外可以通过LiveChat和热线联系Cloudflare以外，其他方案的用户只能等待Cloudflare网络修复完成，只能通过CloudflareStatus.com 查看问题进度。
即使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，也不一定记得注册商的电话、邮件地址。
实际上，以上这三点在许多时候都是环环相扣的。
最后编辑：