Hacker News 中文摘要

RSS订阅

2026年2月20日Cloudflare服务中断 -- Cloudflare outage on February 20, 2026

原文链接 | HN讨论 | 2026-02-22 06:03:31

文章摘要

2026年2月20日Cloudflare因修改自有IP地址管理方式导致部分客户路由被错误撤回，引发持续6小时的服务中断。故障非网络攻击所致，工程师发现问题后立即回滚变更并逐步恢复配置，期间部分客户服务和1.1.1.1 DNS解析器出现连接超时及403错误。

文章总结

Cloudflare 2026年2月20日服务中断事件报告

事件概述
2026年2月20日17:48 UTC，Cloudflare因网络配置变更导致部分"自带IP"（BYOIP）客户的互联网路由通过BGP协议被意外撤销，造成服务中断。此次事件持续6小时7分钟，非网络攻击所致，而是由内部自动化流程缺陷引发。

影响范围
- 全球6500个BGP前缀中，1100个（占BYOIP前缀的25%）被错误撤销
- 核心服务影响包括：
- CDN及安全服务：用户无法访问受影响IP的网站
- Spectrum：BYOIP代理服务中断
- 专用出口IP：流量无法到达目的地
- Magic Transit：连接超时
- 递归DNS网站1.1.1.1出现403错误（但DNS解析服务未中断）

时间线
- 17:56：错误配置开始传播
- 18:46：工程师终止故障进程
- 19:19：开放客户自助恢复通道
- 23:03：全部前缀配置完成恢复

根本原因
自动化清理任务中的API查询缺陷导致系统误判所有BYOIP前缀为待删除状态。具体表现为：
go resp, err := d.doRequest(ctx, http.MethodGet, `/v1/prefixes?pending_delete`, nil)
空值参数触发全量前缀删除，而测试环境未能覆盖此场景。

改进措施
1. API标准化：规范参数校验逻辑
2. 状态分离：区分配置状态与运行状态
3. 熔断机制：监控大规模路由变更行为
4. 快照回滚：建立分钟级配置恢复能力

事件关联
此次变更属于"Code Orange: Fail Small"计划的一部分，该计划旨在通过三方面提升可靠性：
- 受控的渐进式部署
- 消除应急流程中的循环依赖
- 完善系统故障模式测试

后续承诺
Cloudflare对此次事件深表歉意，正在实施上述改进方案以杜绝类似问题。公司重申其构建更可靠互联网的使命，并邀请用户通过1.1.1.1体验优化服务。

（注：原文中产品推广及招聘相关内容已精简，保留核心事件分析与技术细节）

评论总结

总结评论内容：

  1. 对Cloudflare近期频繁故障的担忧
  • 认为故障次数增多，影响平台可靠性（评论3,14） "Cloudflare has been having more network disruptions lately"（评论3） "Too many outages in the past months...people will leave the platform"（评论14）
  1. 对事故报告透明度的不同看法
  • 赞赏透明度但更关注实际服务稳定性（评论1,17） "Truly appreciate them being transparent...but businesses care more about SLAs"（评论1） "This transparent report can earn my trust"（评论17）
  1. 对技术原因的质疑
  • 指出测试不足和代码逻辑问题（评论2,5,16） "it sounds like Cloudflare is barely tested at all"（评论2） "the explanation makes no sense...value is not used in that block"（评论5） "Google's internal system had the same exact bug"（评论16）
  1. 对处理方式的批评
  • 认为应进行更谨慎的生产环境测试（评论11,12） "why not dry run this change in production"（评论11） "happy to be spared from the initial 25%"（评论12）
  1. 幽默/讽刺性评论
  • 用玩笑表达对服务中断的不满（评论4,6,15） "DaaS - Downtime as a Service"（评论4） "The irony is...'Code Orange: Fail Small initiative'"（评论6） "new MCP features are more important than uptime"（评论15）
  1. 关于API设计的讨论
  • 提出空参数应返回无结果而非全部数据（评论21） "returning everything is rarely what's desired...can be a problem"（评论21） "standard practice...return nothing if no filters are provided"（评论21）