DeepSeek服务中断45分钟后恢复

我先检查 DeepSeek 这次服务中断的原始信息，确认时间与恢复情况。

官网状态页的原始记录已经拿到，我顺便把它近期几次故障的时长也核了一遍。下面是成稿。

DeepSeek 服务中断 45 分钟已恢复：11 月 7 日 15:11 起网页与 API 同时不可用，V4 Pro、V4.1 Flash、对话和搜索都在受影响列表里

先说结果：这次 DeepSeek 服务中断发生在 11 月 7 日下午，从 15:11 开始，到 15:56 结束，整整 45 分钟，现在已经恢复。DeepSeek 官方状态页（status.deepseek.com）把这条记为 “DeepSeek 网页 / API 部分中断（DeepSeek Web/API Partially Unavailable）”，状态标为 “已恢复”，中文说明只有一句 “本次问题已解决，服务已恢复”。受影响组件不是单一模型：DeepSeek V4 Pro API 服务、DeepSeek V4.1 Flash API 服务、对话服务（两个组件，含 Chatservice）、搜索服务都被列了进去 —— 也就是说，网页对话、API 调用、以及对话里依赖的联网搜索这一整条链路当时都出现了异常，用户侧看到的典型提示是 “服务器暂时不可用”。

这次断在哪里、断了多久：一条完整时间线

受影响组件清单：

• DeepSeek V4 Pro API 服务
• DeepSeek V4.1 Flash API 服务
• 对话服务（Chat Service）2 个组件，含 Chatservice
• 搜索服务（Search Service）

用户侧能观察到的情况很直接：多名网友在 11 月 7 日下午反馈对话时报错，界面提示 “服务器暂时不可用”；API 侧对应的表现是请求失败或返回错误，而不是变慢。

官方没说的那一栏：45 分钟里原因一直是空白

翻这条事件的更新记录，只有两条：15:11 的 “已实施修复，正在监控结果”，和 15:56 的 “已恢复”。没有 “Investigating”，没有 “Identified”，也没有 “已定位原因”。对照 7 月 2 日那次事件（那条记录里有完整的 “已定位原因 — 已实施修复 — 监控中 — 已恢复” 四段式），这次是跳过了排查与定因环节，直接进入修复后监控。

这意味着两件事：其一，根因没有对外披露，任何 “因为流量洪峰／机房故障／模型升级” 的说法目前都只是外部猜测，不能当事实写；其二，从 15:11 就已经是 “修复已实施” 的表述看，故障的实际起始时间可能早于状态页记录的时刻，状态页只是从人工确认那一刻开始计时。

至于为什么会同时打掉两个模型 API、对话和搜索，能从受影响面反推的只有一点：这几项服务很可能共用同一层基础设施或同一套路由与调度，单点异常就会横向扩散到多个能力。这是根据组件清单做的推断，不是官方口径。

45 分钟放在它自己的故障史里算什么水平

按官方状态页的历史记录，11 月已经出现 2 起（11 月 3 日和 11 月 7 日），10 月是 7 起，9 月标为全部正常。故障类型分两种：一种是 “性能下降”，表现为变慢但还能用，多数在 3 到 15 分钟；另一种是 “部分中断”，表现为不可用，时长跨度大，从 11 分钟到 4 小时都有。这次 45 分钟属于中断类里的中等偏轻，恢复速度比 10 月 15 日那次快得多。

顺带说一句可用率数字：状态页在 8 月至 11 月区间给出的可用率是 V4 Pro API 99.77%、V4.1 Flash API 99.59%、Chat Service 99.84%、Chatservice 99.59%、搜索服务 99.95%。但这组数是在本次事件之前抓取的页面快照，没有计入 11 月 7 日这 45 分钟，只能当长期基线看，不能当 “这次之后的最新可用率”。

当时该怎么做、现在该确认什么

如果你在故障窗口内正在用：

1. 先分辨是 “慢” 还是 “断”。页面还能出字但延迟明显，属于性能下降；直接弹 “服务器暂时不可用” 或请求报错，属于中断，重试没有意义，等恢复更划算。
2. 别在同一秒反复刷新。中断期间高频重试只会叠加无效请求，恢复后还可能撞上瞬时拥塞。
3. 看一眼官方状态页，而不是只看社交媒体。status.deepseek.com 的事件页会给出组件级状态和起止时间，是唯一的一手信源。
4. 恢复后的头几分钟先跑一个短请求验证，再提交长任务，避免长对话跑到一半再次失败。

如果你是通过 API 接入：

1. 把超时和重试策略分开设。超时短一点（比如 30 秒级），重试次数有限（2 到 3 次），并加指数退避，避免在故障窗口内把配额烧光。
2. 关键业务做降级。V4 Pro 不可用时能否切到 V4.1 Flash，或者退回不带搜索的纯对话链路，这取决于你的提示词是否依赖联网搜索 —— 这次搜索服务也在受影响列表里。
3. 长任务做成可断点续跑的。45 分钟的窗口足以打断批量任务，把中间结果落盘，比整批重跑省得多。
4. 记录 incident 时间窗，事后对账。把 15:11—15:56 这个区间写进日志检索条件，能快速区分 “业务逻辑错误” 和 “上游故障”。

收个尾

这次 DeepSeek 服务中断的形态很清楚：45 分钟、组件级部分中断、官方已确认恢复，但根因未公开。对普通用户来说，影响就是那段时间用不了、等一等就好；对开发者来说，更值得记住的是它一个月内已经出现两次同类中断，重试、降级、断点续跑这三件事应当常备，而不是等下次再临时处理。

【相关 FAQ】

问题 1：这次 DeepSeek 服务中断 45 分钟具体是几点到几点？

回答 1：DeepSeek 服务中断 45 分钟发生在 2026 年 11 月 7 日北京时间 15:11 至 15:56，官方状态页记录的持续时长正好 45 分钟，状态已标记为 “已恢复”，中文说明为 “本次问题已解决，服务已恢复”。

问题 2：DeepSeek 服务中断 45 分钟期间，哪些功能不能用？

回答 2：DeepSeek 服务中断 45 分钟的受影响组件包括 DeepSeek V4 Pro API 服务、DeepSeek V4.1 Flash API 服务、对话服务的两个组件（含 Chatservice）以及搜索服务，也就是网页对话、API 调用和对话中的联网搜索当时都受影响。

问题 3：DeepSeek 服务中断 45 分钟的原因公布了吗？

回答 3：没有公布。DeepSeek 服务中断 45 分钟的官方更新记录只有 “已实施修复、正在监控结果” 和 “已恢复” 两条，没有 “已定位原因” 环节，因此根因目前属于未披露状态，外界关于流量或机房的说法都只是猜测。

问题 4：DeepSeek 服务中断 45 分钟是不是第一次？

回答 4：不是。按官方状态页历史，11 月 3 日已出现过一次约 1 小时的网页 / API 部分中断，10 月共记录 7 起事件，其中 10 月 15 日那次长达 4 小时，DeepSeek 服务中断 45 分钟在近期同类事件里属于中等偏轻。

问题 5：遇到 DeepSeek 服务中断 45 分钟这类情况，API 用户该怎么处理？

回答 5：建议把超时设短、重试次数有限并加指数退避，关键业务准备降级路径（如 V4 Pro 切 V4.1 Flash、或在搜索服务同时受影响时退回纯对话），长任务做断点续跑，并把故障时间窗写进日志便于事后对账。

问题 6：DeepSeek 服务中断 45 分钟恢复后，还需要做哪些验证？

回答 6：先看官方状态页确认组件级状态已转为正常，再用一个短请求验证对话与 API 是否通，接着验证涉及联网搜索的场景（这次搜索服务也在受影响列表里），最后再把长任务放回去跑，避免二次失败。

【参考资料】

[2026-11-08]（DeepSeek 网页 / API 部分中断（DeepSeek Web/API Partially Unavailable））DeepSeek Status

[2026-11-07]（DeepSeek 网页 / API 服务恢复正常，今天下午一度中断 45 分钟）IT 之家

[2026-11-07]（DeepSeek web and API services restored, 45-minute outage）链捕手 ChainCatcher

[2026-11-07]（DeepSeek の Web/API サービスが正常に復旧、今日午後一時 45 分間中断）PANews

[2026-11-05]（DeepSeek Status 服务可用率总览）DeepSeek Status

[2026-11-04]（History - DeepSeek Status 历史事件记录）DeepSeek Status

【免责声明】

本文依据 DeepSeek 官方状态页（status.deepseek.com）事件记录与历史事件页，以及 IT 之家、链捕手、PANews 等公开报道整理。起止时间、持续时长与受影响组件以官方状态页为准；官方未公布本次故障根因，文中关于 “共用基础设施导致横向扩散” 的表述为根据组件清单所做的推断，非官方口径。状态页给出的可用率数据为本次事件之前的页面快照，未计入 11 月 7 日的 45 分钟中断，仅作长期参考。本文不代表 DeepSeek 官方立场，不构成任何服务承诺或采购建议，实际服务状态请以 status.deepseek.com 实时页面为准。

核对说明：45 分钟按 15:11—15:56 计算并回官方事件页确认；受影响组件逐项照抄状态页清单，未扩展也未缩减。原因一栏按官方记录如实写为 “未披露”，未替官方编造根因。历史故障时长全部取自官方历史事件页，未采用媒体概括数字。可用率数据已标注抓取时点早于本次事件，避免误读为最新值。