本轮运行失败DeepSeek Messages transport failed

[firepad2026]

感觉自从升级到4.1后 就连续出现这种情况，换ds其它模型也一样！已经无法使用了,有朋友知道是什么原因吗？求解答！

[paperbluster]

我也是刚刚遇到，这是咋了，草泥马

[PanZ1Haaaaaaang]

老哥别这么暴躁。。去API服务状态可以看

[PerryLink]

这条报错串是 DSH 自己打的分类标签，不是上游原文，所以它能告诉你的信息比看上去多。

DeepSeek Messages transport failed 只在 packages/llm/llm-deepseek/src/protocols/messages/adapter.ts:79 产生，条件是：请求生成器抛出的不是 LlmError（:76-79）。同一条生成器里，所有协议层/HTTP 层失败都有自己的文案与错误码，会原样抛出而不会落进这个分支：

• 空闲看门狗触发 → DeepSeek Messages stream idle timeout / TIMEOUT（adapter.ts:76）
• 用户中断 → DeepSeek Messages request aborted / ABORTED（:77）
• HTTP 非 2xx → AUTH / QUOTA / RATE_LIMIT / CONTEXT_WINDOW_EXCEEDED / INVALID_REQUEST / SERVER / HTTP_<status>（.../messages/transport.ts:29-35）
• SSE 帧坏 JSON、或事件类型与 type 不符 → MALFORMED_RESPONSE（.../messages/sse.ts:19、:23）
• 流结束仍未见到 message_stop → DeepSeek Messages stream ended before message_stop / STREAM_CLOSED（.../messages/translate.ts:165）
• 响应没有 body → EMPTY_RESPONSE（adapter.ts:147）

所以这条报错的含义是：请求本身或响应体流在 SSE/协议层之下断了（连接被重置、链路/代理中断、TLS 或 HTTP2 层失败等）。它不是「网关少发终态事件」，不是限流，也不是鉴权。截图里的 已重试模型请求（4/4） 说明它被判为可重试并已重试到上限——TRANSPORT 属于默认可重试码（packages/llm/llm/src/retry-policy.ts:18-24），默认 5 次重试、退避 500ms 起倍增封顶 10s、±10% 抖动（retry-policy.ts:14-17；算式 packages/llm/llm-retry/src/index.ts:59-64，上限判定 :223）。你那条路由的上限看起来是 4，退避也可能被 llm-deepseek: { retryPolicy: … } 覆盖（键在 packages/llm/llm-deepseek/src/config.ts:100，mode: always 可无限重试）；而 5293ms 这种不成倍数的等待，既可能来自自定义退避，也可能来自服务端 retry-after（.../messages/transport.ts:36-37、:42 会把它带出来，llm-retry/src/index.ts:228-236 会原样采用）。

关键一点：被包装的底层错误不会进入会话日志。turn/end 只保留结构化的 {message, code}（packages/core/agent-loop/src/agent.ts:329-336：LlmError 保留自身 facts，其他才折成 cause 链文本），所以界面上你永远只看得到这一层标签。

需要补的证据（缺一样就只能猜）：

1. DSH 版本与运行方式（dsh --version；Web 还是桌面端），官方路由还是自定义 baseURL。你说的「升级到 4.1」是哪个组件的版本号？如果是 DSH，请给准确版本（本次核对时 npm 上 latest=next=0.1.5-rc.2、alpha=0.1.6-alpha.2）。
2. 失败是必现还是偶发：是否都发生在输出较长或同一条长会话里？关掉代理/VPN、换出口、换时段后是否仍复现？
3. 同一 endpoint 直连验证（官方 Messages 协议的默认根是 https://api.deepseek.com/anthropic，见 config.ts:107 与 :292-293；请求路径再拼 /v1/messages，见 packages/llm/llm-deepseek/src/common/messages-api.ts:11-13 与 adapter.ts:122，所以完整地址是 https://api.deepseek.com/anthropic/v1/messages）：

curl -N -X POST https://api.deepseek.com/anthropic/v1/messages \
  -H "x-api-key: $KEY" -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"<你用的模型>","max_tokens":1024,"stream":true,"messages":[{"role":"user","content":"hi"}]}'

如果 curl 也在同一位置断，问题在链路/服务端，与 DSH 无关；如果 curl 稳定而只有 DSH 里复现，再贴失败那一轮的时间点。
4. 失败那一轮启动终端的输出——那里才有 cause 链（界面与日志里没有，见上面第 3 段）。

把 1–3 补齐我就能帮你把范围缩到「链路」还是「DSH 侧」，4 才能指向具体那一层。

如果这些定位步骤帮你找到了原因，可以把这条标为 answer。

[temotee2103]

所以如何解决这个问题？我的全部会话在更新0.1.7-rc.1之后没有一次请求成功 全部都是 本轮运行失败DeepSeek Messages transport failed

[yueranzs]

我也是这个版本出现的问题，于是来搜索了，没想当也是这个版本出现的问题

[temotee2103]

这个是很严重的问题，有没有解决方法？现在DSH直接用不了

[limoonrise]

我今天也遇到这个问题，看了下其他人的解决方案，不太行，我也没有安装 Kaspersky。目前基本就是处于用不了的阶段。
感觉最近这几个版本，都有很严重的bug

[natsuz0ra]

可以让它自己分析这个错误看看，我这边的情况是跟卡巴斯基的网络防御功能起冲突了，卡巴斯基在TLS 握手里换证书导致的

[cdjun]

ubuntu系统，把clash代理打开可以正常工作，关掉就运行失败，不知道是什么原因
dsh: all_proxy names a SOCKS proxy, which is not supported; connecting directly for that scheme — set an http:// or https:// proxy URL instead
dsh web: http://.......

[AlaskGulf]

其根因是卡巴斯基的加密连接扫描（HTTPS 中间人检查）在转发大请求时重置连接。 该结论由以下事实支持：卡巴斯基暂停的那一刻，同一会话、同一进程、同一网络路径上的传输错误立即归零，此后多个连续请求步无一次重试。

[blackleaft-web]

测试了还真是。不过就得找卡巴斯基反馈而不是找ds了。
在卡巴默认设置覆盖之前，手动设置可规避，设置→安全设置→网络设置→配置受信任程序添加文件夹：勾上不扫描加密流量、不监控子应用程序活动、递归地应用排除项→配置受信任地址：api.deepseek.com。卡巴需要保存2次，配置本身保存，然后设置的保存也需要点。
不再出现连接错误。

[yuppiesnotzhuhao]

测试了还真是。不过就得找卡巴斯基反馈而不是找ds了。 在卡巴默认设置覆盖之前，手动设置可规避，设置→安全设置→网络设置→配置受信任程序添加文件夹：勾上不扫描加密流量、不监控子应用程序活动、递归地应用排除项→配置受信任地址：api.deepseek.com。卡巴需要保存2次，配置本身保存，然后设置的保存也需要点。 不再出现连接错误。

解决了，感谢

[simuusang]

应该是插件不兼容了，不嫌麻烦的话可以试试把 .dsh 目录删掉 卸载后重装，我之前就是这么干的，还好我不装任何插件，不用过于折腾