在反复安装 DSH 后，我的 DSH 仍会频繁出现 DeepSeek API request to https://api.deepseek.com failed 问题

[17-qxm]

我没有检查到任何相关的日志，我具有一个正在运行的 clash 代理，但是我没有配置 nodejs 和其它软件相关的代理，同时检查过网络状况和插件都不会影响这个问题的存在

我无法具体的定位问题，但是我会持续关注这个帖子，如果有人愿意帮助我，我可以提供相应的一切信息

[PerryLink]

先说结论：「node 没配代理」不意味着 clash 不在链路里 —— 如果你的 clash 开着 TUN / 增强模式，它是在网络层透明接管流量的，Node 根本不需要任何代理配置。所以问题几乎一定出在 clash 这条链路上，而不是「DSH 没装好」（你重装过多次，这条基本可以排除）。

按下面顺序排，每步都很便宜：

1. 先绕开 clash 验证 API 本身

curl -v https://api.deepseek.com/v1/models -H "Authorization: Bearer <你的KEY>"

• 开 clash 跑一次、关掉 clash（或切直连）再跑一次。
• 两个结果一对比，立刻知道是不是 clash 的问题。

2. 确认 clash 的模式与规则

• TUN / 增强模式：api.deepseek.com 的流量被透明接管，完全按 clash 的规则走。检查这条域名是否被路由到 REJECT、一个死节点、或需要订阅的规则组。最省事的验证：给 api.deepseek.com 加一条 DIRECT 规则再试。
• 系统代理模式：Node 默认不读 Windows 系统代理（WinINET 对 Node 无效），所以「没配 node 代理」是正常的 —— 但也说明系统代理这条路根本不影响 DSH，问题不在这里。
• DNS：clash 本地 DNS 抢答也可能把 api.deepseek.com 解析到错误 IP。确认这条域名在 clash 里走的是远程解析，而不是被本地规则劫持。

3. 排除 DSH 侧（可能性低，但要排除）

• 若 curl 直连成功、只有 DSH 失败：检查 settings 里 llm-deepseek 的 baseURL 有没有被改过、环境里有没有 DEEPSEEK_BASE_URL、以及 key 是否被 DEEPSEEK_API_KEY 正确注入。
• 「频繁失败」这种间歇性特征，也更像网络链路（clash 节点抖动 / DNS 抖动），而不是配置——配置错了会一直失败。

4. 最小对照

关掉 clash → 开一个新会话试一次。通了就是 2；还是不通，把报错原文贴出来（遮掉 key），我按具体错误继续缩范围。你截图里的报错文本我看不清，原文对定位帮助最大。

[xwxxwk]

我遇到了同类问题，让dsh自查后解决，供你参考：

---

Node 端 TLS 拦截导致间歇性 SELF_SIGNED_CERT_IN_CHAIN 报告

症状

使用 Node 内置 fetch 的程序（本例 dsh 0.1.5-rc.2）间歇性请求失败，无规律：

重试模型请求：
重试延迟：8473 毫秒
失败原因：DeepSeek API request to https://api.deepseek.com failed

有时重试能恢复，有时连续失败导致任务中断。

根因

卡巴斯基的 HTTPS 扫描会部分劫持到 api.deepseek.com 的 TLS 连接，
把它换成自己的证书链（Kaspersky Anti-Virus Personal Root Certificate）。
Windows 信任这张根证书，浏览器因此正常；但 Node 内置 fetch 只信任自带的
120 张根证书，不读 Windows 证书存储，于是握手报 SELF_SIGNED_CERT_IN_CHAIN。
是否被劫持取决于这条 TCP 连接，同一条命令连打多次结果不同：

connect 1: authorized=false  issuer=[Kaspersky Anti-Virus Personal Root Certificate]
connect 2: authorized=true   issuer=[TrustAsia DV TLS RSA CA 2025]
connect 3: authorized=false  issuer=[Kaspersky Anti-Virus Personal Root Certificate]

为什么表现为"时好时坏"

undici 连接池里的 keep-alive 连接，握手早已完成，不会被劫持；
只有新建连接才可能撞上。实测：

场景	结果
原始 TLS 握手（直连）	6/10 报 SELF_SIGNED_CERT_IN_CHAIN
复用连接发 POST	16/20 成功
每个请求都新建连接	仅 1–2/20 成功
所以程序空闲一段时间后（连接池需要开新连接）最容易失败，
短时间内连续操作反而正常——这就是"没规律"的来源。

修复

把拦截根证书导出，让 Node 额外信任它：

[Environment]::SetEnvironmentVariable(
  'NODE_EXTRA_CA_CERTS',
  "$env:USERPROFILE\.dsh\certs\interception-roots.pem",
  'User')

NODE_EXTRA_CA_CERTS 只在进程启动时读取，必须重启程序。
修复后实测：原始握手 0/10 报错，新建连接请求 20/20 成功。

[phquathi]

Cross-reference: this failure mode is already documented in #6338.

On Windows, antivirus HTTPS scanning (Kaspersky in the confirmed case) re-signs api.deepseek.com with its own local root CA. The Windows certificate store trusts that root, but Node's bundled CA set does not, so every request fails with SELF_SIGNED_CERT_IN_CHAIN after the retry sequence — which surfaces in dsh only as DeepSeek API request to https://api.deepseek.com failed.

Quick check:

node -e "fetch('https://api.deepseek.com').then(r=>console.log('HTTP',r.status)).catch(e=>console.error(e, e.cause))"

If that prints SELF_SIGNED_CERT_IN_CHAIN, the one-variable workaround is:

setx NODE_USE_SYSTEM_CA 1

then open a new shell and restart dsh. Certificate evidence and the full write-up: #6338 (comment)

（中文）若上面的命令复现出 SELF_SIGNED_CERT_IN_CHAIN，则与 #6338 是同一根因：本地安全软件或网络代理的 HTTPS 扫描重签了证书链，而 Node 默认 CA 不信任这张自签根证书。执行 setx NODE_USE_SYSTEM_CA 1 后新开终端并重启 dsh 即可恢复，无需关闭 HTTPS 扫描。