2026 年 2 月 20 日 17 时 48 分（UTC），全球领先的 CDN 与云安全服务商 Cloudflare 遭遇了一次持续约 6 小时的服务中断。此次中断并非由网络攻击或恶意行为引发，而是源于一次看似常规的自动化配置变更 ——Cloudflare 在优化 Bring Your Own IP（BYOIP）服务的内部流程时，引入了一个软件缺陷，导致约 1,100 个客户的前缀被错误地从 BGP 路由中撤回。这一事件不仅影响了使用 BYOIP 功能的客户，还波及了 Cloudflare 自身的 1.1.1.1 DNS 解析服务（one.one.one.one）。本文将从技术角度深入剖析此次 outage 的根因、恢复流程，并探讨大规模 CDN 基础设施在配置变更管理方面的容错设计原则。
事件回顾与影响范围
此次事件的发生具有明显的时间特征：从代码部署到故障爆发之间存在约 10 分钟的间隔，这为理解故障传播机制提供了重要线索。根据 Cloudflare 官方的事后分析报告，问题起源于一项旨在自动化客户前缀删除操作的代码变更。该变更属于 Cloudflare 内部 “Code Orange：Fail Small” 安全改进计划的一部分，目标是将原本需要人工操作的高风险任务转化为安全的自动化工作流。然而，正是这个旨在提升安全性的变更，引入了意想不到的缺陷。
在影响范围方面，此次 outage 并非全局性的，而是精准地影响了使用 BYOIP 服务的客户子集。Cloudflare 当时共维护约 4,306 个 BYOIP 前缀，其中约 25%（约 1,100 个前缀）在此次事件中被错误撤回。受影响的服务和产品涵盖多个层面：核心 CDN 与安全服务的流量无法被正确路由到 Cloudflare 网络；Spectrum 应用在 BYOIP 模式下无法代理流量；Magic Transit 保护的应用程序从互联网上不可见；使用 BYOIP 或专用 IP 的 Gateway 专用 egress 服务无法向外发送流量。值得注意的是，由于 one.one.one.one 本身就是一个通过 BYOIP 接入的前缀，这次故障得以被 Cloudflare 自身的监控系统快速捕获，从而缩短了故障发现时间。
从用户感知角度，此次故障表现为典型的 BGP 路径 Hunt 现象 —— 终端用户的连接在网络中遍历，试图找到一条通往目标 IP 的路由，但这种尝试会持续到连接超时并最终失败。这意味着即使在故障恢复后，如果前缀未被正确重新通告，用户仍会持续观察到连接失败，直到本地路由缓存过期。
根因分析：API 查询参数的处理缺陷
深入技术层面，此次 outage 的根本原因可以追溯到 Addressing API 中的一个看似微小的编程错误。问题的核心在于一个用于清理待删除前缀的子任务（sub-task），该任务定期执行以检查并移除应被删除的 BYOIP 前缀。开发团队在实现这一功能时，使用了一个 API 查询来获取待删除前缀的列表。
问题代码的客户端请求如下：resp, err := d.doRequest(ctx, http.MethodGet, "/v1/prefixes?pending_delete", nil)。开发者本意是传递一个表示 “仅获取待删除前缀” 的参数，但实现方式存在缺陷。在 Go 语言的 HTTP 请求处理中，当客户端发送 ?pending_delete（不含赋值）时，req.URL.Query().Get("pending_delete") 会返回空字符串 "" 而不是预期的标记值。
服务器端的 API 实现逻辑如下：当检测到 pending_delete 参数存在（即非空字符串）时，会从专门的 ip_prefixes_deleted 表中获取待删除对象；然而当参数为空字符串时，代码逻辑走向了另一个分支 —— 返回所有 BYOIP 前缀而非仅返回待删除的前缀。由于客户端传递的是空值，服务器错误地将所有前缀视为待删除对象，并开始系统性地删除这些前缀及其相关的依赖对象，包括至关重要的 service bindings（服务绑定）。
这是一个典型的空值处理逻辑错误，其危害在于：代码在测试环境中未能被发现，原因是测试数据与生产环境存在差异，且测试用例覆盖了客户自助服务的完整流程，却未涵盖后台任务独立执行数据修改的场景。Cloudflare 官方也承认，其分阶段部署机制虽然在软件二进制发布时严格遵循，但配置变更的部署尚未达到同等的安全水平 —— 这正是 Code Orange 计划试图解决的核心问题。
恢复流程：分层递进的故障修复
此次事件的恢复过程并非一蹴而就，而是根据受影响的程度进行了分层处理，这体现了大规模分布式系统在故障恢复时面临的复杂性。恢复过程大致可以分为三个层次，对应不同受影响状态的客户群体。
第一层也是最直接的一层，是那些仅被撤回前缀但服务绑定仍然完整的客户。这些客户约占受影响总数的大部分，他们可以登录 Cloudflare 控制台，通过简单的开关操作重新通告其前缀，俗称 “toggle the prefixes”。这一自恢复机制在 19 时 19 分向客户开放，成为快速恢复服务的主要途径。
第二层涉及那些前缀被撤回且部分服务绑定被移除的客户。他们处于部分恢复状态，可以切换部分前缀但无法切换其他前缀。针对这些客户，Cloudflare 工程师启动了数据库恢复方法，在 19 时 44 分左右开始着手解决。
第三层最为复杂，是那些前缀被撤回且所有服务绑定均被完全移除的客户。他们无法通过控制台自行恢复，因为系统中已没有任何服务（Magic Transit、Spectrum、CDN）与其 IP 地址范围绑定。这部分客户（约 300 个前缀）的恢复需要触发全局配置更新，将服务绑定重新应用到 Cloudflare 全球边缘的每一台机器上。这一操作直到 20 时 30 分才开始执行，并在 23 时 03 分最终完成，标志着此次 outage 的正式结束。
这种分层恢复策略揭示了一个重要的系统设计教训：在复杂的分布式系统中，故障的影响往往不是均匀分布的，而是呈现出演进式和局部化的特征。恢复方案必须能够识别这些不同的影响层次，并针对性地设计相应的修复路径。
容错设计启示：Code Orange 计划的深化
此次事件发生后，Cloudflare 进一步强调了 Code Orange：Fail Small 计划的重要性。该计划的核心目标是实现配置变更的安全发布，类似于软件二进制发布中常见的灰度部署和健康检查机制。具体而言，Code Orange 包含三个主要工作方向：要求任何传播到网络的配置变更都像软件发布一样进行受控部署；改进内部的 “破玻璃” 应急程序，消除循环依赖，确保在故障期间所有系统都可访问；全面审查、改进和测试所有处理网络流量系统的故障模式。
从此次事件中可以提炼出几个关键的容错设计原则。首先，配置变更必须经过与代码发布同等级别的安全审查和渐进式部署流程。传统的做法区分对待代码变更和配置变更，但在高度自动化的现代基础设施中，这种区分往往是灾难的根源。其次，API 参数的设计应当具有强类型和明确的语义，避免依赖空字符串或隐式默认值进行业务逻辑判断。Cloudflare 官方也承认，将 pending_delete 参数从字符串类型改为强类型枚举值是未来的改进方向之一。
另一个关键的设计启示是操作状态与配置状态的有效隔离。当前，客户对地址模式的修改直接持久化到权威数据库，而该数据库同时用于执行操作。这使得手动回滚过程更加复杂，因为工程师需要使用数据库快照而不是在期望状态和实际状态之间进行理性判断。未来的架构应当引入状态快照机制，将配置变更的应用与健康指标关联，实现自动化的熔断和回滚。
工程实践建议
对于运营大规模网络基础设施的团队而言，此次事件提供了若干可操作的工程实践建议。在配置变更管理方面，任何影响网络路由或服务绑定的配置变更都应被视为高风险变更，需要经过代码审查、灰度发布和健康监控三道关卡。变更的影响范围应当是可观测的 —— 例如，当检测到前缀撤回或删除的速度过快、范围过广时，应自动触发熔断机制，暂停进一步的变更应用。
在监控和告警层面，此次事件的核心监控信号是 BGP 邻居接收到的前缀数量变化。Cloudflare 通过这一指标快速识别了异常，但更理想的做法是在异常检测阈值触发时自动暂停变更，而不是依赖人工判断。对于依赖 Cloudflare 等第三方 CDN 服务的企业，建议监控 BGP 路由状态并设置自动化告警，以便在上游基础设施出现问题时第一时间响应。
在故障恢复准备方面，企业应当充分了解并测试 CDN 提供的自助恢复功能。Cloudflare 在 19 时 19 分开放的自助恢复机制成为大多数客户恢复服务的主要途径，这意味着客户对平台功能的熟悉程度直接影响恢复速度。同时，对于使用 BYOIP 等高级功能的企业，应当建立多路径的流量调度能力，在主路径故障时自动切换到备用方案。
结语
Cloudflare 2026 年 2 月 20 日的此次 outage 事件，是一次典型的因配置变更管理缺陷导致的大规模服务中断。从表面看，问题源于一个参数处理的小错误；但从深层分析，这反映了现代云基础设施在追求自动化效率的同时，对变更安全管理提出的更高要求。6 小时 7 分钟的影响时间、约 25% 的 BYOIP 前缀受影响 —— 这些数字提醒我们，即使是最成熟的云服务提供商，也可能在看似安全的自动化改进中翻车。Code Orange 计划的提出和深化，代表了行业对这一挑战的正式回应：将配置变更提升到与代码发布同等的安全级别，通过健康指标介导的渐进式部署，以及在故障发生时实现快速回滚的能力。对于整个行业而言，此次事件是一记警钟，也是一份宝贵的案例教材，推动着云基础设施向更高的可靠性目标演进。
资料来源：Cloudflare 官方事件报告（blog.cloudflare.com/cloudflare-outage-february-20-2026/）