Cloudflare 宕机——长达 6 小时的全球大规模服务中断导致客户无法访问互联网

2026-02-22 11:55:04 5 1334

2026 年 2 月 20 日，Cloudflare 遭遇了长达 6 小时的全球服务中断，导致使用其自带 IP (BYOIP) 服务的客户受到严重影响。



2026 年 2 月 20 日，Cloudflare 遭遇了长达 6 小时的全球服务中断，导致使用其自带 IP (BYOIP) 服务的客户受到严重影响。

该事件始于世界协调时 17:48，持续了 6 小时 7 分钟，无意中从互联网上撤回了客户的 BGP 路由，导致许多服务和应用程序无法访问。

该公司证实，此次中断完全是由内部配置更新引起的，而非网络攻击或恶意活动，影响了全球 25%的 BYOIP 前缀，并在 1.1.1.1 公共递归 DNS 解析器网站上触发了 HTTP 403 错误。

地址 API 故障的技术分析

此次故障的根本原因可以追溯到 Cloudflare 地址 API 中的一个内部错误，该错误是在自动清理子任务部署期间引入的。

这项任务旨在取代 BYOIP 前缀的手动删除流程，作为公司“橙色代码：小规模故障”弹性计划的一部分。

工程师部署了一个系统，用于定期检查并移除网络中的待处理对象。然而，该系统执行的 API 查询传递了未赋值的 pending_delete 标志，导致服务器将该空字符串解释为将所有返回的 BYOIP 前缀加入删除队列的命令，而不仅仅是那些已计划删除的对象。

在一名工程师手动终止该进程之前，这种编码疏忽系统性地删除了大约 1100 个 BYOIP 前缀及其依赖的服务绑定。

受影响的连接立即进入一种称为 BGP 路径搜索的状态，在这种状态下，终端用户连接会持续搜索目标路由，直到超时并失败。此次影响范围波及多个依赖 BYOIP 配置进行互联网通告的核心产品。

恢复工作和计划​​补救措施

由于大规模提款对客户前缀的影响各不相同，导致恢复工作严重延误，需要进行密集且多样化的数据恢复操作。

虽然有些用户可以通过 Cloudflare 控制面板重新启用广告来自行解决问题，但大约有 300 个前缀的服务绑定被完全移除。

这些受影响严重的账户需要工程师手动恢复，他们必须推送全局配置更新，才能将设置重新应用到边缘网络上的每台机器上。

为防止未来发生灾难性部署，Cloudflare 正在根据其“橙色代码”指令加快几项关键架构变更。

工程团队计划规范 API 架构以防止标志位解析错误，实施熔断器以检测异常快速的 BGP 前缀删除，并建立基于健康状况的运行状态快照，以将客户配置与生产部署分开。



Cloudflare 在其官方事件报告的结尾，就 2 月 20 日的网络中断事件直接向用户和全球互联网社区致歉。该公司公开承认，此次大范围的网络中断损害了其提供高弹性网络的核心承诺。
类别 新闻资讯

关于作者

weak_hong40篇文章52篇回复

weak_hong
5

评论5次

要评论？请先  登录  或  注册
  • 5楼
    Evilnight
    Rank: 2
    2026-3-4 11:59

    感觉最近cf炸的挺频繁啊

  • 4楼
    良品
    Rank: 1
    2026-3-2 18:28

    Cloudflare 是也降本增笑了吗，怎么感觉事故越来越频繁了

  • 3楼
    ChaseKing
    Rank: 1
    2026-2-23 23:14

    最近Cloudflare 宕机次数比较频繁啊

  • 2楼
    beiank
    Rank: 2
    2026-2-23 14:43

    互联网中的大善人 它已经是很重要的网络基础设施了 我生活中的反向代理离不开它了

  • 1楼
    T00lsAI T00ls官方AI机器人
    Rank: 3Rank: 3
    2026-2-22 11:59

    结论

    此次宕机事件是典型开发/运维流程中的输入验证与错误处理缺陷直接引发的级联故障。核心问题在于API参数未强制校验（未赋值的pending_delete标志被误解析为删除指令），且缺乏熔断机制控制大规模删除行为，最终导致BGP路由xi统全局失效。

    分析路径

    L1 攻击面识别

    • 关键组件与依赖链：
      • API接口：地址API负责BYOIP前缀的增删改查。
      • BGP路由xi统：依赖API数据通告客户IP路由。
      • 自动清理任务：定期触发API查询，删除标记为pending_delete的前缀。
    • 攻击面暴露点：
      • 自动任务调用API时传递未校验的pending_delete参数值（空字符串）。
      • API未对参数格式/枚举值进行约束，将空字符串误解析为“强制删除所有结果”。

    L2 假设与验证

    • 假设1：API的pending_delete参数未进行类型/枚举值校验，允许任意输入。
      • 验证路径：
        1. 检查API文档或代码，参数pending_delete是否仅允许true/false或预设枚举值。
        2. 模拟API调用，传递空字符串或异常值，观察是否触发错误返回而非误操作。
    • 假设2：自动清理任务未实现熔断机制，无法阻止异常删除行为扩散。
      • 验证路径：
        1. 检查任务逻辑是否统计单位时间内删除的前缀数量，超过阈值后触发熔断。
        2. 审查删除日志，确认是否在初始错误发生后持续批量删除目标。

    L3 边界/异常场景

    • 边界条件测试：
      • 参数pending_delete为空字符串时，API是否返回错误而非执行逻辑。
      • 自动任务连续删除超过阈值（如>100个前缀）时，是否触发熔断或人工审核。
    • 异常场景复现：
      • 通过API注入异常参数值（如空字符串、非布尔值），观察是否触发非预期删除。
      • 模拟高负载下任务频繁触发，验证熔断器是否生效并阻断后续请求。

    L4 防御反推与修复

    • 现有防御措施失效点：
      • 参数校验层缺失：未强制pending_delete参数类型为布尔值。
      • 熔断机制缺失：未对批量删除操作设置速率限制或总量阈值。
      • 变更回滚机制缺失：删除操作无事务性回滚能力，需手动恢复。

    验证步骤（最小可执行路径）

    1. 参数校验验证： 

      # 模拟API请求，传递空字符串作为pending_delete参数  curl -X POST "https://api.cloudflare.com/delete_prefix" \  -H "Content-Type: application/json" \  -d '{"pending_delete": ""}'

      预期结果：API应返回400错误并提示参数无效，而非执行删除操作。

    2. 熔断机制验证：

      • 触发自动清理任务，逐步增加需删除的前缀数量，观察是否在达到阈值（如50个/分钟）时触发熔断并停止后续操作。

    3. BGP路由影响验证：

      • 使用traceroute或bgpstream工具，监控删除前缀后的路由收敛延迟，确认是否因路由失效导致全局超时。

    修复建议

    1. API层防御加固：

      • 强制参数校验：在API接口中将pending_delete参数类型定义为布尔值，并拒绝非true/false输入。
      • 枚举值约束：若需多状态支持（如pending_delete、confirmed_delete），定义枚举值白名单并校验输入。

    2. 熔断与限流机制：

      • 在自动清理任务中添加速率限制（如每分钟删除<=50个前缀）、总量阈值（单次任务最大删除量），超过阈值需人工审批。
      • 实现熔断器：若单位时间内删除失败率超过10%，自动终止任务并告警。

    3. 变更回滚能力：

      • 对BYOIP前缀操作添加事务性日志，支持原子回滚（如删除后生成JSON快照，可快速恢复）。
      • 提供配置快照对比工具，对比生产环境与备份配置差异，自动化推送修复指令。

    4. 监控与告警：

      • 监控BGP路由收敛时间（如bgpq3工具采集AS_PATH长度变化）。
      • 对API异常参数调用、批量删除操作设置实时告警（如Prometheus+Alertmanager）。

    关键点：所有自动任务需遵循最小权限原则，并强制通过沙箱测试（如模拟环境验证参数边界条件）。