凌晨1:42，Bluesky（去中心化社交平台）的状态页突然变红。三台服务器离线，美国东部节点彻底失联。9小时后，工程师仍在排查连接超时问题——而部分用户甚至没察觉异常。

故障时间线：一场不对称的崩溃

打开网易新闻 查看精彩图片

根据官方状态页，故障始于美国东部时间凌晨1:42。三台服务器同时掉线，核心症状是「连接超时」——这意味着数据包发出后，对方始终没回应。

诡异的是，并非所有人受影响。作者实测显示：主 feed 偶尔需要刷新，但服务基本可用。这种「部分可用」状态比全站宕机更难排查，因为工程师得先定位哪些用户、哪些区域、哪些请求链断裂。

这不是本月第一次。月初Bluesky刚经历过一次短暂中断，两次间隔不到两周。

「reginos」背后的技术现实

官方公告把「regions」拼成「reginos」，这个 typo 被原文明晃晃保留。小失误暴露大压力：凌晨值班工程师在紧张排查时，连拼写检查都顾不上。

更关键的是架构矛盾。Bluesky主打「去中心化」叙事，用户数据理论上不依赖单一服务器。但本次故障显示：三台服务器掉线就能让部分用户失联——中心化依赖依然存在，只是藏得更深。

美国东部节点作为流量重镇，一旦超时，辐射范围远超物理位置。所谓「去中心化」在基础设施层，仍受制于传统云服务的区域部署逻辑。

为什么部分用户无感知？

答案在缓存和负载均衡。Bluesky 的内容分发网络（CDN）可能缓存了热门内容，让部分请求绕过了故障节点。但实时互动——发帖、点赞、关注——必须回源验证，这部分用户就被挡在门外。

这种「半瘫痪」状态最伤产品信任。全站宕机，用户知道等修复；时灵时不灵，用户会怀疑是自己网络问题，反复刷新、重装、投诉——运营成本陡增。

去中心化社交的成人礼

Bluesky 从 Twitter 分裂而来，承载着「逃离马斯克」的集体情绪。但技术架构的成熟度，远没赶上用户增长的斜率。

两周两次故障，节奏逼近早期 Twitter 的「失败鲸」时代。区别在于：当年用户没得选，现在 Threads、Mastodon 都在旁边等着。

凌晨拼错的「reginos」，或许是个隐喻——去中心化理想很丰满，但运维凌晨的错别字，和中心化平台一样狼狈。