摘要

  • 清理任务发送了不带值的pending_delete参数。Addressing API因而把请求解释为查询全部BYOIP前缀；后续任务删除了前缀及其依赖的服务绑定。
  • 大约1,100个前缀被撤回。约800个可通过重新通告恢复；另有约300个前缀的边缘服务配置也被删除，必须等待后续全局配置恢复。路由通告只是服务恢复的一层。

第二只恢复时钟

把Cloudflare在2026年2月20日的事故称作一次BGP中断并没有错，但这会漏掉最重要的后半段：部分客户前缀重新通告后，Cloudflare边缘节点上已经没有服务绑定，无法判断这些地址的流量应交给哪个产品。路线回来了，服务还没有。

一个公网地址并不等于一项应用服务。前缀可能登记在客户名下、授权供应商代表客户通告、保存在供应商地址库中、由BGP向外宣布、绑定到某项产品，再分发为边缘机器上的运行配置。这些状态彼此相关，却不能互相替代。外部看见路由，并不能证明数据包已抵达正确的客户服务。

Cloudflare的事故复盘说，周期性清理子任务原本要自动处理客户提出的BYOIP前缀移除请求。任务向API发送了没有值的pending_delete。复盘披露的服务端实现只有在参数字符串非空时才筛选待删除条目；空值因此让接口返回全部BYOIP前缀。清理任务又把所有返回项视为待删除，并移除了依赖对象，包括服务绑定。

Cloudflare表示这不是攻击。Addressing API版本于17:46 UTC部署，十分钟后清理任务开始执行，前缀随后遭到撤回。工程师于18:46识别并停止该任务。在此期间，约1,100个前缀被撤回；Cloudflare称这约占其全球通告的4,306个BYOIP前缀的25%。复盘还单独列出某个对等方可见的6,500个前缀。这是另一个统计口径，不能与全球BYOIP总量混用。

变更采用迭代式推进，因此并非所有客户都受到影响后才被叫停。这确实限制了爆炸半径，却不等同于恢复方案。分批发布只能控制错误扩散速度，不能自动找回被删除的服务状态。

“已经通告”不等于“已经服务”

Cloudflare文档把两种操作分开：BGP通告让目的流量被引向Cloudflare网络；服务绑定则把流量指向CDN、Spectrum或Magic Transit等具体产品。CDN用途还可能涉及地址映射。若自动化同时删除前缀及其服务绑定，重新通告可以让流量重新抵达供应商网络，却未必恢复边缘节点上的产品处理路径。

因此，控制台提供的自助恢复只适用于部分情况。19:19 UTC，Cloudflare建议客户重新通告前缀。到20:20左右，约800个前缀已恢复。其余约300个无法通过简单切换广告状态修复，因为相应服务配置也从边缘系统中消失了。客户无法在账户可见状态中创建一条已经不存在的绑定。工程师必须先找回配置，再把全局更新推送到边缘；这项工作于23:03 UTC完成。公司报告的事故总时长为六小时七分钟。

公开复盘没有给出受影响客户数、地理分布、收入损失或SLA赔付金额，但清楚展示了不同的恢复路径：只有路由被撤回、绑定部分消失，或服务绑定全部被删。同一场“BYOIP故障”背后，恢复责任和时钟并不相同。

one.one.one.one网站也出现HTTP 403。Cloudflare明确指出，1.1.1.1公共解析器的DNS解析，包括DNS over HTTPS，并未受影响。网站报错说明一个使用BYOIP的入口受到影响，不代表解析服务停止回答查询。把两者混为一谈，会让运营团队排错的方向走偏。

配置本身也是网络基础设施

Cloudflare称Addressing API是一份权威地址数据集，其变动会反映到全球网络。客户请求经由数据库和工作流触发通告与产品绑定的变化。复盘还指出，同一份存储状态既代表客户期望的配置，也直接驱动生产操作；这使回滚困难，工程师需要恢复数据库快照，而不是把期望状态与实际运行状态进行对账。

测试缺口也很具体：预发数据与模拟数据没有覆盖足够情形。团队测试了客户自行操作的流程，却没有测试一个独立任务运行器在没有客户明确请求时修改数据。由用户启动的API路径可能安全，定时任务复用同一接口却可能越权地产生破坏。只验证界面流程，等于把自动化任务使用的权限主体排除在安全模型之外。

Cloudflare提出的改进也不只是修正参数：统一API schema；分离配置状态和运行状态；让配置快照通过健康指标控制的分阶段部署进入生产；在异常时自动停止或回滚；发现前缀撤回过快、过广时触发断路器；并考虑使用客户服务健康状况作为停止信号。复盘记载的是当时宣布的后续工作，不足以证明这些方案在之后已经全部完成。

BYOIP的商业价值，是客户可以沿用熟悉的地址身份，同时使用供应商的网络和服务。它的实际运行关系更复杂：客户可能拥有地址段并授权供应商通告，但撤回路由、选择服务产品、向边缘机器分发配置的控制面都由供应商运营。资产可以具有可移植性，而恢复它所需的某些状态仍无法由所有者自行重建。

这不是反对托管路由的理由，而是要求把“连续性”定义在服务边界上。Cloudflare动态通告文档指出，成功的API响应只能说明请求已登记，路由传播还需要时间；BYOIP接入指南则要求在生产通告前准备好服务绑定。收到确认和服务真正运行，是两种不同证据。

连续性承诺需要交代什么

客户真正需要知道的，不只是供应商能否通告前缀，还包括哪个状态出了问题、谁能修复它。连续性时间线至少要拆成四项：停止危险任务；从外部观测到路由；恢复服务绑定和边缘配置；确认应用流量成功。每一项都有不同负责人和恢复时钟。

这次事故可以变成具体的验收演练：路由已经回来，但服务绑定仍然缺失时，供应商能否识别？能否只恢复一个客户的配置，而不冒险回滚整库？停止变更的门槛是否包含服务健康，而非只有路由数量？事故冻结期间客户还能做什么，冻结多久，什么条件可以恢复写操作？

客户可以规划备用通告路径，但这不能普遍替代供应商的配置恢复。Cloudflare的操作建议提醒，重叠通告和路由优先级需要谨慎处理。备用路径只有在源地址授权、流量处理和服务行为一起验证后才有意义。把数据包引到一张没有应用配置的网络，只是把故障搬了位置。

结论并不玄妙，却可验证：地址是路由系统中的名称；路由表达可达性；服务绑定决定流量去向；服务在线才是结果。连续性报告不应把这些层次压成一个绿色状态灯。前缀回来是进展，不是恢复终点。

来源