4 月 30 日 16:33 UTC，Canonical 状态页先把 blog.ubuntu.com 标成 Down。十分钟内，ubuntu.com、canonical.com、开发者站点、安全公告 API 等服务陆续出问题。
更扎眼的是后半段。真正牵动 Ubuntu 用户的两个软件源端点，security.ubuntu.com 和 archive.ubuntu.com，大约三小时后开始受影响。到 20:50/20:51 UTC 前后，它们稳定下来，后续解析到 Cloudflare AS13335。
攻击方声称使用的 Beamed 服务，beamed.su 和 beamed.st，也仍由 Cloudflare AS13335 代理。这里不能直接写成“Cloudflare 勒索 Canonical”。公开材料里没有勒索信，没有可见赎金流，也没有证据证明 Cloudflare 主动策划攻击。
但这已经足够构成一个行业问题：当攻击工具前台和受害者防护都绕不开同一家公司，DDoS 防护就不再只是技术服务。
关键事实：被打的不是官网，是软件源
这次故障从 4 月 30 日 16:33 UTC 开始，到 5 月 1 日 12:44 UTC 恢复，总体约 20 小时。
受影响的不是几个展示页。Ubuntu 的软件源、安全公告 API、开发者入口都在里面。对普通用户来说，最直接的是 apt update、自动安全更新可能受阻；对企业运维和下游发行版维护者来说，是补丁同步、构建链和镜像策略被打断。
| 项目 | 事实 | 影响对象 |
|---|---|---|
| 故障起点 | 4 月 30 日 16:33 UTC，Canonical 多个公共服务异常 | Ubuntu 用户、开发者、企业运维 |
| 关键端点 | security.ubuntu.com、archive.ubuntu.com | apt 更新、自动安全更新、下游包管理 |
| 稳定时间 | 20:50/20:51 UTC 前后，两个端点恢复稳定 | 最核心的软件分发链先止血 |
| Cloudflare 位置 | 两个仓库端点后续解析到 AS13335；Beamed 域名也解析到 AS13335 | 防护方与攻击工具前台出现在同一基础设施后面 |
时间线也说明，Canonical 没有把整套站点一次性搬到 Cloudflare。
19:34 和 19:40，两个软件源端点开始 Down。接下来约 70 分钟，它们在 Down 和 Operational 之间反复跳。到 20:50:29 和 20:51:13，两个端点几乎同时稳定。
ubuntu.com、canonical.com、launchpad.net、snapcraft.io、login.ubuntu.com 等站点仍在 Canonical 自己的 AS41231 地址空间里波动，后来才恢复。
这更像一次精准止血：先保住 archive 和 security。
这个选择很合理。软件源不是品牌门面，是 Linux 系统的供水管。官网挂了，很多人只是打不开页面；security 源挂了，安全更新就会卡住。
不能定罪，但结构已经不好看
原始线索里还提到 RIPE、Companies House、证书透明日志、注册商和自治系统迁移等同步点。它们让人不舒服，但证据强度有限。
时间重合不能当因果链。现在最多只能说：有一些未解释的可疑同频，不能说有人提前串通。
更硬的问题在 Beamed 这一层。
Beamed 公开声称出售“绕过 Cloudflare”的能力，包括住宅 IP 轮换、寻找源站端点等方法。这个销售页面本身由 Cloudflare 代理。攻击方又声称使用了这类服务。
Canonical 最后把两个最关键的软件源端点切到 Cloudflare 才稳定。
事实效果就很别扭：攻击工具前台能借“平台中立”继续在线，受害者在 outage 时钟里购买防护。
这不等于 Cloudflare 犯罪。也不能默认 Beamed 与 Cloudflare 有特殊合作关系。公开能看到的事实只是：Beamed 域名由 Cloudflare 代理，仍然可达；Ubuntu 两个仓库端点后来也到了 Cloudflare AS13335。
我更在意的是执行后果。
DDoS 防护市场卖的不是普通带宽，而是危机里的可达性。平时大家可以谈成本、架构、供应商偏好；一旦安全更新源被打，选择空间会急速缩小。
天下熙熙，皆为利来。放在这里不是骂街，是描述激励。只要威胁常态化，能让网站继续可达的一方就会拥有更强定价权。
1930 年代美国赛马 wire service 的类比不完全一样，但有一处相似：谁掌握实时可达的线路，谁就能向依赖这条线路的人收费。今天 Cloudflare 不是赛马黑帮，DDoS 防护也有真实技术价值。可相似的权力结构仍在：可达性成了入口税。
受影响的人该看什么
Ubuntu 用户最直接的动作很简单：别只盯官网是否恢复，要看安全更新源是否稳定。对桌面用户，这通常表现为更新失败、包索引拉不下来；对服务器用户，影响更麻烦，自动安全更新可能延迟。
企业运维团队要做的不是立刻迁走，也不是迷信某一家 CDN。更现实的动作有三类：
| 对象 | 该做的事 | 现实约束 |
|---|---|---|
| 企业运维 | 检查 apt 源、镜像源、自动安全更新告警 | 临时切源可能引入一致性和信任问题 |
| 镜像站维护者 | 复盘上游不可达时的同步策略 | 镜像只能缓冲，不能替代安全公告源 |
| 开源基础设施团队 | 准备多供应商 DDoS 预案和 DNS 切换流程 | 多供应商会增加成本和配置复杂度 |
采购团队也会更谨慎。不是所有人都会马上买 Cloudflare，也不是所有人会立刻避开它。但类似事件会推高一个问题的权重：供应商是否只卖防护，还是也代理了大量灰色前台。
接下来最该观察的不是谁发一句公关声明。
要看三件事：Cloudflare 如何处理 Beamed 这类公开出售绕过能力的前台；Canonical 是否说明两个软件源的切换策略和后续防护架构；开源项目是否开始把关键端点的抗打能力当成基础设施预算，而不是临时应急。
我不太买账“Cloudflare 救了 Ubuntu”这个单句叙事。它可能确实让两个关键端点恢复稳定，这一点该承认。但如果救火的人也给疑似纵火工具的门面提供遮蔽，行业就不能只鼓掌。
问题不在一封没有出现的勒索信。
问题在一种更安静的生意结构：威胁不必由你制造，只要你能从威胁的常态化里收租，就已经足够赚钱。
回到开头那个反常点。两个最关键的软件源端点切到 Cloudflare 后稳定；攻击工具的前台，也在 Cloudflare 后面继续可达。
这不构成定罪。
但足够提醒开源世界：公共软件源不能把最后一道门交给火场里的单一卖伞人。