编辑|华为的一半网络又断了。就在今天，Cloudflare 遭遇了持续数小时的宕机，导致许多热门网站和 AI 服务离线。据报道，服务中断持续了约五个半小时。 Openai的Chatgpt和Sora都是受影响的应用程序之列，Claude、Shopify和美国新泽西州公共交通系统的官方网站也出现故障。神秘的流量激增导致大范围的停电。据外媒报道，Cloudflare 于 11 月 18 日美东时间凌晨 5 点 20 分左右首次发现平台流量异常。大约一个半小时后，该公司更新了状态页面公告，告知客户此次中断。错误消息和增加的 mga 延迟表明服务中断“CloudFlare 正在经历内部服务中断。某些服务可能会间歇性受到影响，”Cloudflare 在发布的公告中表示。大约早上 7 点之前。网站的 CDN 服务并不是唯一受到此次中断影响的服务。这次中断还影响了其应用程序产品套件，该套件为云和本地工作负载提供 CDN 功能，同时保护工作负载的应用程序编程接口免受恶意流量的影响。 7 月份的 CloudFlare 博客指出，全球约 20% 的网站依靠它来管理和保护流量。据 DownDetector 报道，X uprising、Spotify、OpenAi 的 Chatgpt、社交媒体网站 Trump Truth Social、在线设计平台 Canva 以及 Letterboxd 的电影应用程序 Movie 均获得批准。是我们自己的DownDetector的bsite受到了短路的影响。这次中断还影响了至少两项其他服务。在修复过程中，CloudFlare 工程师关闭了伦敦地区的 Warp 虚拟专用网络 (VPN) 服务。此外，一些用户无法使用该公司的Cloudflare访问零信任网络（ZTNA）工具。 ZTNA 产品的用途与 VPN 类似但提供更高的安全性和性能。美国东部时间 11 月 18 日上午 8 点 09 分，该公司表示“已发现问题并已实施修复”，但恢复过程并不顺利。 Cloudflare 于 11 月 18 日上午 8:13 左右在伦敦地区重新启用 Warp 服务。据 CloudFlare 称，控制面板服务于上午 9:34 恢复。上午 9:42，该公司在其状态页面上宣布，工程师已修复了流量原因。在接下来的几个小时内，Udflare 将继续监控恢复过程，并“寻找加快完全恢复的方法”。服务中断于上午 11:44 结束。Cloudflare 的一位发言人向媒体证实，在发布第一个状态更新之前，他们发现“其中一项服务出现异常流量激增”，“导致流经 Cloudflare 网络的部分流量变得不稳定”。 “我们正在全力确保所有交通正常。然后我们将集中精力调查联合国大学的原因Cloudflare 在一份声明中表示，值得一提的是，在 X 平台上，有网友评论称，“Rust Rust 重写版本的 Cloudflare 没有经受住时间的考验。”9 月 26 日，该公司表示，得益于 Rust 的语言特性，这次重构“更快、更安全”。CloudFlare 的崩溃报告特别指出了导致泄漏的生锈代码行。“一行 Rust 代码崩溃，瘫痪”很多人认为，写过 rust 的人都知道，非随便使用不是一个好习惯。还有人指出，“只有在配置文件出现问题时，Unwrap 才会失败。”还有人说，“Cloudflare 的朋友”宕机是因为一个工程师试图修改一个旧的配置文件，删除了一堆看起来过时的代码。正是这些代码行维持了他们的路由系统的稳定性。当配置文件部署时，一半的监控系统即时通讯立即变红，整个网络开始出现一些异常现象，甚至他们的内部文档也无法完全解释。长时间的备份，一系列自动重新加载操作的循环，并试图让完全混乱的服务器集群恢复正常运行。 “而且，他透露，”（Cloudflare）办公室里堆满了红牛罐头，每个人都暗自恐慌。还有一位高级开发人员不断重复“不要碰任何东西”。 “官方披露：CloudFlare 是流媒体的根本原因。全世界大约 20% 的网站都依赖内容分发网站 (CDN)。当用户访问网页时，CloudFlare 内容数据会从靠近用户的数据中心传输。该架构可以向全球 95% 的人口提供 50 毫秒或更少的延迟。原因是当天晚上，Cloudflare 首席技术官 Dane Knecht 在 X 平台上的一篇帖子中透露。认为此次中断是由恶意流量功能造成的公司的重整，而不是由攻击引起的。该高管强调，“依赖机器人保护功能的服务存在潜在漏洞。在例行配置更改后，它开始崩溃，导致我们的网络和其他服务的性能普遍下降。”与此同时，CloudFlare发言人也向外媒提供了更详细的最新进展。据称，“这次中断的根本原因是自动生成的流量配置威胁。”发言人表示，“需要明确的是，目前没有证据表明这是由攻击或恶意活动引起的。”我们期待事件发生后流量会自然增加，部分Cloudflare服务可能会出现暂时的性能下降，但所有服务将在接下来的几个小时内恢复正常。”在后续博客中，CloudFlare进一步解释了完整的故障过程，受影响的系统及加工方法。报告称，“该问题是由我们的数据库系统中的权限更改引发的，导致数据库向机器人发出请求。管理系统使用的功能文件中输出了多个条目。已超出。据报道，CloudFlare的机器人管理模块包括多个系统，其中包括一个机器学习模型，该模型为流经其网络的每个请求生成机器人评分。客户使用这些评分来决定是否允许tuI拥有可以访问其网站的机器人。该模型的输入数据是“签名”配置文件每隔几分钟更新一次并在网络上同步，使其能够响应互联网流量的变化。这是底层点击查询行为的变化，导致生成的文件中出现大量重复的“功能”行。此更改更改了先前配置的文件大小配置功能的大小，从而导致机器人模块出现错误。触发错误。因此，负责处理客户流量的主代理系统向所有依赖机器人模块的流量返回 HTTP 5xx 错误代码。此问题会影响 KV 工作人员和依赖密钥代理的访问服务。更改是为了允许所有用户获取他们有权访问的表的准确元数据。但问题是，他们过去的代码中有一个预设的前提：这样的查询返回的列列表只包含默认数据库的内容，而且这个查询不会过滤数据库的名称。当他们逐渐向目标集群用户推出这种显式权限时，上面的查询开始从存储在 R0 数据库中的基础表中返回列的“重复项”。不幸的是，机器人管理模块的文件生成逻辑正是使用这种类型的查询来生成本节开头提到的文件中的每个特征输入“feature”。由于授予了额外的权限对于用户来说，查询响应现在包含 R0 数据库模式的所有元数据，导致响应行数增加一倍以上，最终影响输出文件中的行数（即特征数）。起初，他们错误地认为观察到的症状是由大规模分布式拒绝服务（DDOS）攻击引起的，但随后准确地识别了主要问题，成功阻止了比预期更大的签名文件传播，并将其替换为早期版本。详细报道链接：https://blog.cloudflare.com/18-november-2025-outage/六年来最严重停电，“真相”被嘲笑？ CloudFlare 股价整体下跌约 3%。 “由于 Cloudflare 服务的重要性，任何停机都是不可接受的。网络将在一段时间内无法正确路由流量，这对我们团队中的每个人来说都非常悲伤。我们知道现在每个人的信任都被背叛了。” Cloudflare 在 bl 中也说了奥格。此外，公司还解释了后续加固系统以防止故障的步骤，包括以下几个方面：根据用户生成的输入保护标准，加强对CloudFlare配置生成的文件的身份验证的接受；增加更多全局紧急关闭开关以实现相关功能；防止基本转储或其他错误报告占用大量系统资源；综合分析各主要代理模块的各种错误故障模式。对于此次宕机，CloudFlare承认，这是2019年以来最严重的一次宕机，记录无法获取，但六年多来，从未出现过导致大部分主要流量无法通过我们网络发送的情况。”据了解，该公司上次重大宕机发生在6月，当时有超过6个服务离线约两个半小时。那次宕机是由于KV的数据存储故障造成的。愤怒平台。有网友评论道：“这都是Cloudflare搞砸的，一个小故障就成了第一张多米诺骨牌。”还有人认为，“这次宕机本身是件小事，但它暴露了Cloudflare自身服务之间的过度耦合问题，导致控制面板无法访问。如果控制面板可用，它可以让很多服务更快地部分恢复功能。还有人问：“互联网真的有必要完全依赖单一提供商吗？”同时，也有批评人士表示，这样的宕机充分暴露了互联网的脆弱性，尤其是在每个人都依赖同一个服务提供商的情况下。 e-services-offline/https://arstechnica.com/tech-policy/2025/11/widespread-cloudflare-outage-bled 商业AI产品的秘密，探索AI编码创新的新方向！
特别声明：以上内容（如有则包括照片或视频）由自媒体平台“网易加速器”用户上传发布ount”。本平台仅提供信息存储服务。
注：以上内容（包括图片和视频，如有）由网易HAO用户上传发布，网易HAO为社交媒体平台，仅提供信息存储服务。
推荐文章
