8月17日,不少人打开Bluesky,信息流刷不出来,登录卡住,图片传不上去。有人报的是504,有人报的是"failed to reach upstream service"。从美国、加拿大到英国、法国、德国、葡萄牙、巴西,故障零零散散地铺开,像信号不好的收音机,时断时续。
第二天,Bluesky官方发帖确认:又是一次DDoS攻击,持续约24小时,"已升级防御措施,持续监控"。没有攻击规模,没有归因,没有技术细节。这是今年内第二次。
24小时,到底是什么24小时
Bluesky说的"24小时"指的是攻击持续的时间,不是服务瘫痪的时间。用户的真实体验是间歇性的、跨地域不均的故障,不是铁板一块的宕机一整天。这个区别看着小,但决定了你该怎么理解这次事故的严重程度——攻击者一直在打,但防线没有一直被击穿,说明升级后的防护多少起了点作用。
只是"起了点作用"和"真正扛住"之间,还差很远。
这不是第一次,也可能不是最后一次
把时间线拉长看,会发现这压根不是孤立事件:
- 2025年4月.一次约1小时的DDoS重创Bluesky,CTO Paul Frazee事后承认,攻击打的是Bluesky自家托管的PDS(个人数据服务器),而独立运营的PDS完全没事。
- 2026年4月15日至20日.更长、记录更详细的一轮攻击,官方博客写清了首次症状出现的时间、恢复稳定的时间点,以及随后一次余波。
- 2026年8月16日至17日.这次,官方只给了一句简讯。
一年半三次,攻击方式看着都指向同一个软肋。
协议是分散的,咽喉是集中的
Bluesky建在AT Protocol上,理论上由PDS(存用户数据)、relay(转发消息)、AppView(拼出信息流)三层分离,谁都可以自己搭一套,理论上没有单点。
但绝大多数用户从没想过要自己搭一套。他们用的就是Bluesky官方托管的那一整套服务。攻击者也不傻,不会去打成百上千个分散的独立节点,直接打Bluesky自营的那几台机器就够了——2025年4月那次已经验证过,独立PDS毫发无损,官方PDS却让主流体验瘫了。
这就是"协议去中心化"和"服务去中心化"的落差。前者是设计图纸,后者是普通人每天点开App时摸到的现实。图纸再漂亮,咽喉要道还是那一条。
- 风险.普通用户几乎享受不到"去中心化红利",除非主动迁移到独立PDS或第三方客户端,而这需要相当技术门槛。
横向比一比,Bluesky两头不占
Mastodon是联邦制,单个实例出问题不影响全网,天生带故障隔离,代价是用户体验分散、不统一。Threads和X是纯中心化,规模换来的是单点风险,好在至少不用假装自己抗打。Bluesky想两者兼得——协议设计追求分布式,产品体验却又要统一顺滑,结果是攻击者只需要瞄准官方基础设施这一个点,就能让"去中心化叙事"当场破功。
古人说"其兴也勃焉,其亡也忽焉",用在这不算夸张——一套系统立得快,也可能垮得快,关键看根基是分散的还是集中的。
AT Protocol团队不是没意识到这一点。2025年秋季路线图里明确提了"硬去中心化":更多独立relay、更容易的账户迁移、非归档式的Sync 1.1中继、自托管同步工具tap、PLC目录副本。方向是对的,问题是这些基础设施改进目前还停留在给开发者和极客用的阶段,普通用户的默认体验依然全绑在Bluesky自家服务器上。
结论:去中心化的意义,不在于协议允许分散,而在于用户实际用的东西是不是分散的。这次攻击再次证明,只要Bluesky官方托管的那套服务还是绝大多数人唯一的入口,它的抗打击能力就和一个中心化平台没什么本质区别。
真正值得盯的不是这次攻击本身,而是Bluesky会不会在下次攻击之前拿出比"升级防御,持续监控"更实在的东西——比如一份像4月那样详细的事后复盘,交代清楚打的是哪一层、独立PDS这次到底扛没扛住。如果连这个都拿不出来,"去中心化"这三个字,眼下还只是一句还没兑现的承诺。