11月7日15时11分起，DeepSeek官方状态页记录了一次“DeepSeek网页/API部分中断”，受影响范围包含三大核心模块：对话服务（Chat Service）、DeepSeek V4 Pro API、DeepSeek V4.1 Flash API。也就是说，网页版和App里的聊天用不了，开发者通过接口调用的第三方工具也同步报错。记者实测时，对话功能无法使用，聊天界面一度显示“服务器繁忙，请稍后重试”。知乎长春晚报
服务已经恢复。官方状态页的事件报告写明：本次中断从15:11持续到15:56，历时45分钟，最终标注“已恢复”，受影响的对话服务下包含对话与搜索两个组件。截至发稿，官方暂未公布本次故障的根本技术原因，也没有提及任何补偿计划。晚间仍有个别用户发帖称提问报错，官方没有再发布更新。微博知乎微博
中招的还是11月3日那三项服务
把本周内两次中断放在一起看，受影响的模块完全重合。11月3日16时58分起，DeepSeek网页和API服务出现部分中断，记者当天下午测试对话功能时页面提示服务器繁忙，受影响的同样是对话服务、V4 Pro API和V4.1 Flash API。那次中断并非一步恢复：对话服务、DeepSeek V4.1 Flash API服务在17时06分转性能下降，17时13分短暂恢复，17时36分又转性能下降。今视频长天新闻财经网
18时25分，DeepSeek官网发布当日第二次中断公告，称网页端及API服务出现部分中断，已实施修复、正在监控，受影响服务仍是上述三项。按状态页记录，这次中断持续到18时48分才完全恢复，历时约1小时49分钟。11月刚过去7天就出现两个中断日，话题#DeepSeek11月7天崩2次#随之登上热搜。贝壳财经微博
连续两次波及同一组服务，指向的更可能是网页与API共用的接入层或算力调度环节承压，而非某个单点模块自身故障——但这只是从故障模式能做的推断，官方两次均未披露根因，结论只能到此为止。再往前，10月15日早8点后，DeepSeek网页和APP一度显示“服务器暂时不可用”，官方信息同样标注对话服务部分中断、V4.1 Flash API部分中断、网页/API性能下降。第一财经
原因未公布，负载背景有迹可循
社区把矛头指向流量高峰与“重试风暴”——用户量快速上涨和算力储备跟不上的矛盾慢慢凸显，叠加架构、重试风暴等问题，很容易加重故障压力。这类推测官方没有背书，能核实的背景是需求正处在爬升最快的阶段：11月5日，DeepSeek的Agent产品Harness官宣日活达154万、日消耗92万亿Token。用户增长与算力扩容之间的节奏差，是目前解释这两次故障最直接、也最缺乏官方确认的一条线索。微博第一财经
现在该做什么
普通用户如果仍遇到“服务器繁忙”，等待重试即可，确认进度可查官方状态页；不过11月7日故障期间有用户反馈，状态页本身一度无法访问、连接被重置，此时参考官方社媒公告更可靠。补偿方面，社交平台上“什么时候补偿”的追问不断，而官方公告中未出现任何补偿方案。知乎
对依赖DeepSeek API跑业务的开发者，7天两次中断的节奏下，“别把工作流绑死在单一API”的备份方案——多模型兜底、为重试设上限并采用指数退避、非紧急任务错峰调度——优先级明显变高了。由于根因未公布，这两次中断究竟是一次性波动还是算力瓶颈的常态信号，只能靠状态页的后续披露来检验；在此之前，把“可用但可能不稳”作为调用DeepSeek的前提假设更稳妥。
