DeepSeek Harness · run failure
dsh run failed: “DeepSeek API request … failed” — what it means
DeepSeek API request to https://api.deepseek.com failed
The HTTP request from dsh to the model provider never completed. The turn ended with `{"kind":"error","code":"TRANSPORT"}`.
dsh 发往模型 provider 的 HTTP 请求根本没有完成。turn 以 `{"kind":"error","code":"TRANSPORT"}` 结束。
Why it happens根因
A network-path failure between your machine and the API host: a proxy or VPN that dropped the connection, DNS resolution, a TLS interception, or the endpoint being briefly unreachable. In a measured corpus of 2,006 turns this was 67 of 84 failures — 80% — spread over 15 days and 32 sessions, the signature of a chronic background condition rather than one outage.
你的机器与 API 主机之间的网络链路问题：代理或 VPN 断流、DNS 解析、TLS 拦截，或端点短暂不可达。在一份 2,006 个 turn 的实测语料里，84 次失败中有 67 次是这一类——80%——散布在 15 天、32 个会话，这是慢性背景问题而非单次故障的特征。
How to fix it怎么修
- Re-run the turn. This class is usually transient, and nothing local is left half-written when it fails before the first tool call.
- If it repeats, check the proxy/VPN path to the API host and whether DNS resolves it.
- Run `npx dsh-why` to confirm the local install itself is healthy and see which plugins are loaded.
npx dsh-why run see every run failure this can name看它能定性的全部运行期失败- 重跑这个 turn。这一类通常是暂时的；在首次工具调用前失败时，本地不会留下写了一半的东西。
- 如果反复出现，检查到 API 主机的代理/VPN 链路，以及 DNS 能否解析它。
- 跑 `npx dsh-why` 确认本地安装本身健康，并看清加载了哪些插件。
npx dsh-why run see every run failure this can name看它能定性的全部运行期失败Is this my plugin’s fault?这是我的插件引起的吗？
No. The turn failed between dsh and the provider — before, or instead of, a model reply. Plugins run inside dsh; none of them sits on the path to the API host. A failed plugin shows up as a load error at startup, not as a provider rejection.
不是。这个 turn 是在 dsh 与 provider 之间失败的——发生在模型回复之前，或取代了模型回复。插件跑在 dsh 里面，没有任何一个位于通往 API 主机的链路上。插件坏了会表现为启动时的加载错误，而不是 provider 的拒绝。
Related failures相关失败
502 status code (no body)a 5xx from the providerDeepSeek stream idle timeout after 300000msthe stream went idleclient-modules: require("…") missed the module table— or the other way round: dsh will not start at all
502 status code (no body)provider 返回 5xxDeepSeek stream idle timeout after 300000ms响应流空闲超时client-modules: require("…") missed the module table—— 或者反过来：dsh 根本起不来
FAQ常见问题
Why do my dsh runs keep failing with an API request error?
It is a network-path problem between dsh and the provider endpoint, not a plugin or model problem. `npx dsh-why run --all` shows whether it is chronic on your machine and how it compares to your own baseline.
Is this caused by an installed plugin?
No. The turn failed between dsh and the provider — before, or instead of, a model reply. Plugins run inside dsh; none of them sits on the path to the API host. A failed plugin shows up as a load error at startup, not as a provider rejection.
How do I tell this apart from a provider outage?
A transport failure is between you and the endpoint, so it tends to hit only your machine and to recur sporadically over days. A provider-side problem arrives as `provider-server` with an HTTP 5xx and usually correlates across users at the same time.
为什么我的 dsh run 反复报 API 请求失败？
这是 dsh 与 provider 端点之间的网络链路问题，不是插件或模型的问题。`npx dsh-why run --all` 会告诉你它在你机器上是否属于长期问题、以及相对你自己基线如何。
这是插件导致的吗？
不是。这个 turn 是在 dsh 与 provider 之间失败的——发生在模型回复之前，或取代了模型回复。插件跑在 dsh 里面，没有任何一个位于通往 API 主机的链路上。插件坏了会表现为启动时的加载错误，而不是 provider 的拒绝。
怎么和 provider 故障区分开？
transport 失败发生在你与端点之间，所以它通常只影响你这台机器，并且会在多天里零星复现。provider 侧的问题会以 `provider-server` 加 HTTP 5xx 的形式出现，且通常在同一时间影响多个用户。