DeepSeek崩了4小时52分，我翻了官方状态页：这个月已经第5次

今天早上 8 点 11 分，DeepSeek 挂了。

网页端和 App 都提示「服务器暂时不可用」，一直挂到下午 1 点 04 分才恢复。

我没急着骂。骂也骂不动。我干的是另一件事——把它官方状态页从头翻了一遍，然后发现真正值得说的不是「它崩了」，而是这个月它已经崩了 5 次。

DeepSeek 这次崩了多久，官方怎么说的

DeepSeek 有一个官方状态页，地址是 status.deepseek.com，中文界面。所有故障都会在上面留档：什么时候开始、什么时候结束、影响了哪些服务、修到哪一步。

今天这次的事故记录是这样写的：

整个过程，官方一共发了六条更新：

时间列为北京时间。官方页面按 UTC 显示，写的是 12:11 AM ~ 05:04 AM，换算过来就是 08:11 ~ 13:04。

从 8:11 出问题，到 9:06 说「定位到原因」，中间隔了 55 分钟。从定位到修复上线，又隔了 3 小时 43 分。

然后，官方从头到尾一个字都没说原因。

我把状态页往前翻，翻出了一本账

这才是我今天真正想说的部分。

状态页上有个「历史事件」页，会按月份列出全部故障。我翻了一下：

• 2026 年 8 月：一切运行正常——官方原文就这一行字，零故障
• 2026 年 9 月：8 个故障
• 2026 年 10 月：5 个故障

10 月这 5 次摊开来看：

9 月那 8 次里，最长的一次也是「部分中断」，持续 3 小时。

8 月那一行「一切运行正常」，是整页里最扎眼的东西。

两个月，13 次。8 月还是干净的。

99.45% 的可用性，翻译成人话是多少

状态页最底下还挂着官方自己公布的可用性数据，统计区间是 2026 年 7 月到 10 月：

99.45% 听起来很接近满分。翻译一下：按 30 天算，大约等于每个月有 4 小时是不可用的。

行业里常用的分档是这样的——99.9% 对应每月约 43 分钟，99.99% 对应每月约 4 分钟。

所以 99.45% 这个数，落在「能用，但每个月会断一次半」的位置上。

这串数字不是我算的，是 DeepSeek 状态页自己挂着的。

我怎么确认它真的恢复了

光看官方说「已恢复」不够，我自己去敲了一下门。

下午 12 点 54 分，我拿一个无效的 key 去请求 api.deepseek.com。返回的是标准 401 鉴权错误——这说明网关那层已经活了。要是它还没修好，你看到的会是 502、503，或者干脆连接超时。

下午 1 点 10 分，我再刷状态页，顶部的横幅已经从「We're experiencing issues」变成了「Everything is running smoothly」。

顺便说个查状态页的小技巧。页面上那四个状态词是有固定含义的，别看到红字就慌：

• 排查中（Investigating）：知道出事了，还没找到原因
• 已定位（Identified）：找到原因了，正在修
• 监控中（Monitoring）：修完了，在观察会不会复发
• 已恢复（Resolved）：结案

另外一个细节：这个状态页不是 DeepSeek 自己搭的，页脚写着 Powered by Flashduty——是第三方托管服务。所以它本质上是个「外包的公告板」，更新频率取决于官方有没有往里填内容。

说句公道话，和我的结论

先把没证据的话摘出去。网上现在传的「用户太多、算力不够」「算力被调走了」，我翻遍官方渠道，没有找到任何一条官方口径支持。官方状态页从头到尾没给原因，这些说法都是网友猜的，听听就好。

再说公道的一面。

99.45% 这个数放在全球头部 AI 服务里，不算最难看的那一档。而且这次的响应其实不算慢——8:11 出事，8:14 就有第一条公告，中间只隔了 3 分钟。宕机这件事，体量上去了基本躲不掉：用户量、并发、算力调度，任何一个环节抽一下风，前端就显示「服务器暂时不可用」。

但我还是要把账摆出来，因为它和「偶尔抽风」是两回事。

8 月 0 次，9 月 8 次，10 月 5 次。

这是官方自己记的账，不是我猜的。

所以结论是什么？

我不打算说「DeepSeek 要完」——这话没根据，它现在依然是我用得最顺手的模型之一。

但有一件事我改了：我不再把关键活儿只押在它一家。

具体点说，如果你只是拿它聊天查资料，崩了换个工具就行，影响不大。但如果你把它的 API 接进了自己的流程——比如写了个脚本天天调，或者产品里有功能依赖它——那你至少要心里有数：它 10 月这半个月已经出状况 5 次，平均 3 天一次，最长的一次是 4 小时 52 分。

备选方案不需要多复杂，能接上就行。真出事的时候，你不会希望自己只有一条路。

崩不崩，是它的事。

有没有后路，是你的事。

这类服务状态和免费入口的账，我平时都在翻，顺手记下来。关注一下，下次它再出状况你能第一时间知道。

你今天是几点发现它崩的？评论区报个时间，我看看是不是全网同步。

常见问题

Q：DeepSeek 现在恢复了吗？

A：恢复了。官方状态页记录 10 月 15 日 08:11 出问题，13:04 标记为「已恢复」，全程 4 小时 52 分。

Q：DeepSeek 为什么崩？官方给原因了吗？

A：没有。状态页从头到尾只写了「正在排查问题」「已定位原因」「已实施修复」三个阶段，没有披露具体原因。网上流传的「算力不够」「用户太多」等说法都没有官方口径支持。

Q：DeepSeek 状态页在哪看？

A：status.deepseek.com，中文界面，可以订阅更新。页面上的「历史事件」页能查到按月归档的全部故障记录。

Q：这次崩影响 API 吗？

A：影响。官方状态页列出的受影响组件有三个：对话服务、DeepSeek V4 Pro API 服务、DeepSeek V4.1 Flash API 服务。

Q：9 月和 10 月各崩了几次？

A：按官方状态页历史记录，2026 年 9 月 8 次，10 月 5 次，而 8 月是零故障。