我先并行检索 DeepSeek 这次服务中断的时间线、影响范围和官方状态页说明。
先把答案说清楚：11 月 7 日下午 15:11 开始，DeepSeek 网页端和 API 出现部分中断，用户对话时会提示 “服务器暂时不可用”，官方状态页在 15:11 就挂出 “已实施修复，正在监控结果”，到 15:56 更新为 “本次问题已解决，服务已恢复”，前后 45 分钟。受影响的是 DeepSeek V4 Pro API、DeepSeek V4.1 Flash API、对话服务（2 个组件）和搜索服务，属于 “部分中断” 而不是全站瘫痪。到 11 月 8 日晚间，状态页显示各项服务运行正常，近三个月（8—11 月）累计可用率在 99.59% 到 100% 之间，其中 V4 Pro API 为 99.77%、V4.1 Flash API 和对话服务均为 99.59%、搜索服务为 99.95%。这次官方只给了 “已修复、已恢复” 两句话，没有公布根因，也没有像 10 月 15 日那次近 5 小时的故障一样发补偿公告，所以对普通用户来说，眼下该做的就是重试并确认自己的报错码，对开发者来说则是把重试和降级逻辑再检查一遍。
这次发生了什么
| 时间（北京时间，11 月 7 日） | 状态页记录 | 含义 |
|---|---|---|
| 15:11 | 标记 “部分中断”，同时写 “已实施修复，正在监控结果” | 问题已处理，进入观察期 |
| 15:11—15:56 | 持续 45 分钟 | 期间网页对话提示 “服务器暂时不可用” |
| 15:56 | 更新为 “本次问题已解决，服务已恢复” | 事件关闭 |
受影响组件清单如下：
| 组件 | 是否受影响 | 说明 |
|---|---|---|
| DeepSeek V4 Pro API | 是 | 开发者调用旗舰模型会失败 |
| DeepSeek V4.1 Flash API | 是 | 走 flash 名称的请求同样受影响 |
| 对话服务（2 个组件） | 是 | 网页端和 App 对话直接报错 |
| 搜索服务 | 是 | 联网搜索不可用 |
| 搜索 API、抓取 API、上传文件服务 | 否 | 状态页未列入本次受影响范围 |
“服务器暂时不可用” 对应的到底是哪个错
很多人把这句提示当成 “DeepSeek 挂了”，但它在 API 层面对应的是不同的状态码，处理方式也不一样。
| 你看到的提示 | 对应 HTTP 码 | 官方定义 | 该怎么做 |
|---|---|---|---|
| 服务器暂时不可用 / 服务器繁忙 | 503 | 服务器负载过高、流量太大 | 退避重试，错峰跑批 |
| 服务器故障 | 500 | 服务端内部故障 | 稍等重试，持续失败再报障 |
| 请求速率达到上限 | 429 | 触发并发或速率上限 | 降并发，别把它当成宕机 |
| 余额不足 | 402 | 账户没钱 | 充值，和故障无关 |
区分这两类很关键：503 是 “平台侧忙”，重试通常能过；429 是 “你自己打得太快”，重试没用，要降并发。这次 45 分钟的中断属于前者。
这类中断为什么反复出现
从状态页的历史记录能看出一个很明显的节奏：11 月已经记录 2 起故障（11 月 7 日 45 分钟、11 月 3 日 1 小时），10 月记录了 7 起，其中 10 月 15 日那次最长，媒体报道从早上 8 点前后一直到 12 点 50 分才修复，接近 5 小时（状态页本身记为 4 小时，两个口径有出入）。更早的 3 月底还有一次接近 12 小时的中断。
| 日期 | 事件 | 持续 |
|---|---|---|
| 11 月 7 日 | 网页 / API 部分中断 | 45 分钟 |
| 11 月 3 日 | 网页 / API 部分中断 | 1 小时 |
| 10 月 27 日 | API 性能下降 | 14 分钟 |
| 10 月 20 日 | 搜索服务异常 | 8 分钟 |
| 10 月 15 日 | 网页 / API 部分中断 | 状态页 4 小时，媒体称近 5 小时 |
| 10 月 12 日 | 网页 / API 性能下降 | 15 分钟（第三方监控称更长） |
| 10 月 11 日 | 网页部分中断 | 11 分钟 |
| 10 月 8 日 | 网页 / API 性能下降 | 3 分钟 |
| 10 月 2 日 | 网页 / API 性能下降 | 1 小时 |
| 3 月底 | 大规模宕机 | 接近 12 小时 |
这些故障集中在两件事上：一是用户规模和调用量涨得太快，模型侧成本已经压下来了，但算力调度、集群容灾这些 “地基” 没同步跟上；二是流量在高峰时段集中，官方把北京时间周一至周五 9:00—12:00、14:00—18:00 定为高峰，其余时段按半价计费，本身就是在用价格引导错峰，说明高峰容量一直是紧的。11 月 7 日 15:11 正好落在工作日午后高峰尾部，时间点并不意外。
还有一层背景：DeepSeek 正在冲刺上市，第二轮融资规模已到千亿元级别、估值被报道为 6000 亿元上下，服务稳定性已经从 “体验问题” 变成 “能不能兑现” 的问题，这也解释了为什么状态页的每一次更新都被媒体盯着转。
你现在该怎么做
网页端和 App：
- 先刷新页面重进，别在同一个会话里反复点 “重新生成”。
- 关掉联网搜索和深度思考，用最简单的对话先确认服务是否通。
- 长对话容易卡在处理阶段，新开一个对话比硬等更快。
- 避开工作日 9:00—12:00、14:00—18:00 两个高峰窗口。
API 和自建应用：
- 开指数退避加抖动重试（1、2、4、8 秒加随机小数），OpenAI SDK 可以用 max_retries 直接接管。
- 用流式请求，尽早拿到首 token，也便于识别服务是否真的恢复。
- 区分 503 和 429：前者退避重试，后者降并发。flash 的并发上限是 2500，v4-pro 是 500，超了就是 429。
- 批量任务排到空闲时段，价格是高峰的一半，稳定性也更好。
- 备一条降级路径 ——DeepSeek 的权重是 MIT 协议开源，可以切到其他推理服务商或本地部署。
- 所有失败请求记下 request_id 和时间戳，后面要报障或者对账都靠它。
这次和 10 月 15 日那次有什么不同
10 月 15 日那次中断近 5 小时，官方开放平台当晚发了服务恢复及补偿通知，按账号 7 日内（10 月 8 日至 14 日）的消耗金额以赠金形式全额返还，自动到账，扣费先从赠金账户走，有人收到 4 块多，也有人晒出 300 多元。这次 45 分钟的中断，截至 11 月 8 日没有见到补偿公告，状态页也只写了恢复。所以如果你的业务在这 45 分钟里有失败请求，目前能做的就是重试，别指望自动补。
收成一句：这次是一次 45 分钟的部分中断，不是全站故障，服务已恢复、功能可用；真正值得记住的是三件事 —— 看到 “服务器暂时不可用” 先分 503 还是 429，重试策略比刷新页面有用，以及在 11 月这个故障偏密的月份里，把降级方案提前备好。
【相关 FAQ】
问题 1：DeepSeek 网页 / API 部分中断这次持续了多久，现在真的恢复了吗？
回答 1：从 11 月 7 日 15:11 到 15:56，共 45 分钟，官方状态页在 15:56 明确写 “本次问题已解决，服务已恢复”，到 11 月 8 日晚间各项组件均显示运行正常；如果你仍在报错，先确认是不是本地网络或账号余额问题，因为 DeepSeek 网页 / API 部分中断结束后，剩下的报错多半是你自己的请求参数或并发超限。
问题 2：提示 “服务器暂时不可用”，是不是说明 DeepSeek 又全站崩了？
回答 2：不等于全站崩。这次是部分中断，只影响 V4 Pro API、V4.1 Flash API、对话服务和搜索服务，“服务器暂时不可用” 在 API 层面对应 503（负载过高），属于平台侧忙、重试能过的类型；如果是 429 那是你并发打太满，和 DeepSeek 网页 / API 部分中断是两回事，别混着判断。
问题 3：DeepSeek 网页 / API 部分中断这么频繁，是不是不该把生产业务接上去？
回答 3：要看你业务的容错能力。近三个月 V4 Pro API 可用率 99.77%、V4.1 Flash API 和对话服务 99.59%，单看数字不差，但 10 月一个月就记录了 7 起故障、其中一次近 5 小时，说明尾部风险不小；所以接入可以做，前提是必须配好重试、超时、降级三件套，把 DeepSeek 网页 / API 部分中断当成必然会发生的事件来设计，而不是偶发事故。
问题 4：DeepSeek 网页 / API 部分中断之后，官方会给补偿吗？
回答 4：这次没有看到补偿公告。10 月 15 日那次近 5 小时的中断，官方按账号 7 日内消耗金额以赠金形式全额返还；11 月 7 日这次只有 45 分钟、且状态页直接标记已恢复，截至 11 月 8 日没有补偿通知。所以遇到 DeepSeek 网页 / API 部分中断，先按重试处理，补偿属于官方酌情动作，不是必然。
问题 5：怎么第一时间知道 DeepSeek 网页 / API 部分中断，而不是自己瞎排查？
回答 5：盯官方状态页最直接。status.deepseek.com 会按组件列出受影响范围、持续时长和更新记录，11 月 7 日这次就是 15:11 挂出、15:56 关闭，历史页还能看到 11 月和 10 月的全部故障清单；配合错误码文档一起看，就能在几分钟内判断是平台侧问题还是自己的调用问题，不必等社交媒体上传开。
【参考资料】
[2026-11-07]（DeepSeek 网页 / API 部分中断（DeepSeek Web/API Partially Unavailable））DeepSeek Status
[2026-11-07]（History - DeepSeek Status）DeepSeek Status
[2026-11-07]（DeepSeek 网页 / API 服务恢复正常，今天下午一度中断 45 分钟）新浪财经（转 IT 之家）
[2026-11-07]（DeepSeek 网页及 API 部分中断 ）每日经济新闻（微博）
[2026-11-05]（DeepSeek API Pricing (November 2026): V4.1 Flash and V4-Pro Costs, Off-Peak Discount and "Server Is Busy" Fix）Freaky Jolly
[2026-10-26]（错误码 | DeepSeek API Docs）DeepSeek API Docs
[2026-10-16]（DeepSeek 再次出现大规模宕机 服务稳定性会影响冲刺 IPO 吗？）运营商财经网（新浪财经转载）
[2026-10-16]（DeepSeek 服务中断近 5 小时，官方致歉并补偿 API 用户 7 天消耗金额）TechWeb
[2026-10-15]（宕机数小时，DeepSeek 给补钱了！）机器之心（新浪财经转载）
免责声明：本文依据 DeepSeek 官方状态页（status.deepseek.com）的事件记录与历史页面、开放平台错误码文档，以及新浪财经、每日经济新闻、TechWeb、运营商财经网等公开报道整理，仅作信息参考，不构成对服务可用性的承诺或对任何商业决策的建议。故障持续时长、根因说明与补偿方案均以 DeepSeek 官方状态页和开放平台公告为准；其中 10 月 15 日事件状态页记为 4 小时、媒体报道称近 5 小时，10 月 12 日事件状态页记为 15 分钟、第三方监控称更长，本文已并列标注口径差异，未作单一取舍。可用率数据取自状态页近三个月统计，会随统计周期滚动变化。API 报错码含义、并发上限与峰谷时段以官方最新文档为准，本文引用的定价与限速信息来自第三方整理，可能存在滞后。