dsh web 在内网代理环境下请求 DeepSeek API 失败 — 现象 / 原因 / 修复方案

[fzully]

现象（Problem）

在内网环境（访问公网需要通过 HTTP 代理，浏览器走系统代理可以正常上网）的 Windows 主机上运行 dsh web：

• 打开 http://127.0.0.1:3080/ 正常；
• 发送任意消息后，页面提示：

This turn failed
DeepSeek API request to https://api.deepseek.com failed

原因（Root cause）

• DeepSeek 相关的 API 调用全部使用 Node 内置的 fetch（undici），且没有配置任何代理/Dispatcher：
  • packages/llm/llm-deepseek/src/adapter.ts:607（chat/completions）
  • packages/llm/llm-deepseek/src/files-api.ts:147（Files API）
  • packages/web/web-search-deepseek/src/provider.ts:222（Anthropic 兼容端点）
• Node 内置 fetch 默认不读取 HTTP_PROXY / HTTPS_PROXY 环境变量（Node 22 实测）。
• 因此后端 Node 进程直连 api.deepseek.com，被内网防火墙拦截（ECONNRESET）；而浏览器走系统代理不受影响，于是页面收到 TRANSPORT 错误。

修改说明（Fix）

在启动入口统一安装环境代理，使所有 fetch 自动走代理：

• 新增 packages/boot/app-boot/src/proxy.ts：installEnvProxy() — 检测到 http_proxy/HTTP_PROXY/https_proxy/HTTPS_PROXY 时，安装 undici EnvHttpProxyAgent 作为全局 dispatcher（自动遵守 NO_PROXY，本地回环流量仍直连）。
• packages/boot/app-boot/src/index.ts：在 boot() 开头调用 installEnvProxy()（覆盖所有 dsh 子命令），并从包导出。
• packages/boot/app-boot/package.json：新增依赖 undici@^7.28.0。
• 新增单测 packages/boot/app-boot/tests/proxy.spec.ts（4 个用例）。
• 未配置代理时 installEnvProxy() 为 no-op，直连环境行为保持不变。

验证（Verification）

• app-boot 全部单元测试通过（含新增 4 个）。
• 端到端：重启 dsh web 后，在网页发送消息，DeepSeek 经代理正常回复，不再报错。

[PensiveFei]

分析到位，我按你引用的三处源码（packages/llm/llm-deepseek/src/adapter.ts、files-api.ts、packages/web/web-search-deepseek/src/provider.ts）核对过，路径属实，根因也正确：Node 内置 fetch（undici）默认不读 HTTP_PROXY/HTTPS_PROXY，我在 Node 24 上实测过同样现象——设了代理环境变量，fetch 依然直连。所以内网环境报 TRANSPORT/ECONNRESET 是预期结果。

补充两点，供你参考：

1. 可以先试试 Node 官方开关，零代码改动。 Node 22.21+ / 24+ 内置了 NODE_USE_ENV_PROXY=1（或启动参数 --use-env-proxy），设置后 fetch 会自动按 HTTP_PROXY/HTTPS_PROXY/NO_PROXY 走代理（官方 commit：nodejs/node#57165，22.21.0 起 backport）。DSH 的 engines 是 ^22.19.0 || >=24.0.0，所以只要 Node 版本够新（≥22.21 或 24.x），先这样验证一下：

export HTTP_PROXY=http://代理地址:端口
export HTTPS_PROXY=http://代理地址:端口
export NO_PROXY=127.0.0.1,localhost,::1
export NODE_USE_ENV_PROXY=1
npx @deepseek-ai/dsh web

NO_PROXY 一定要带上 127.0.0.1,localhost——否则连 dsh web 自己的本地回环请求也会被代理接管。如果这个开关在你的 Node 版本下生效，就不需要改任何代码；这也是给维护者提 PR 前最省事的确认手段。

2. 你的 installEnvProxy() 方案本身没问题，但有一个容易踩的坑。 undici 的 EnvHttpProxyAgent 在 NO_PROXY 为空时不豁免 localhost/127.0.0.1（源码里 #shouldProxy：noProxyEntries.length === 0 直接返回 true，即全部走代理）。dsh web 后端进程有大量本地回环请求（127.0.0.1:3080 的 API、内部服务），全局 dispatcher 会把它们也丢给代理。所以要么在文档/实现里强制把 127.0.0.1,localhost,::1 并入 NO_PROXY，要么在测试里覆盖"代理不可达时本地请求不受影响"这个场景。你现有的 4 个单测里如果有 NO_PROXY 相关的用例，建议补一条"未设置 NO_PROXY 时本地回环仍直连"的断言。

另外一个小建议：全局 dispatcher 会影响进程内所有 fetch（包括未来新增的 provider 适配器），这正是它"一劳永逸"的好处，但也意味着责任面变大。如果维护者更保守，也可以只在你列的那三处显式传 dispatcher，效果相同、影响面小，只是代码要多改几行。

方便的话补充一下环境信息，大家排查起来更快：

• node -v（22.19/22.20 没有 NODE_USE_ENV_PROXY，22.21+ 才有）
• dsh --version
• 代理类型：HTTP / HTTPS / SOCKS？（EnvHttpProxyAgent 只处理 http/https 代理，SOCKS 需要 socks-proxy-agent 之类的实现）

[fzully]

感谢核实！你的分析基本都验证属实，我在你基础上补充实测结果和一个新发现。

关于 NODE_USE_ENV_PROXY（你的建议①）——验证成立
按你的建议把 Node 升到了 v24.19.0 后实测：

• NODE_USE_ENV_PROXY=1 下 fetch('https://api.deepseek.com/...') 出站经代理正常（401 = 到达 API）。
• 你补的版本说明也对：我原环境正是 22.20，所以官方开关触发不了，22.21+/24+ 才有。

关于 NO_PROXY 回环隐患（你的建议②）——实测比预想更常见，已修复
实测发现一个更隐蔽的坑：这台 Windows 机器上 NO_PROXY 是分号分隔的（127.0.0.1;localhost;10...*;...），而 undici 的 #parseNoProxy 只按
/[,\s]/（逗号/空白）拆分，分号整串被当成一个条目，等于一条豁免都没生效——本地回环fetch 127.0.0.1 被丢给代理（公司代理直接回 403）。也就是说，哪怕用户设置了
NO_PROXY，只要用分号分隔就不生效，这比你提到的"NO_PROXY 为空"更普遍。

补充验证：官方路径同样受影响——NODE_USE_ENV_PROXY=1 内部也复用undici 的 EnvHttpProxyAgent，分号 NO_PROXY 一样不解析。所以无论走官方开关还是自建 dispatcher，都得处理分隔符。

我做的加固：

• installEnvProxy() 里新增 resolveNoProxy()：把 NO_PROXY 按 , / 空白 / 分号 统一规范化，并强制并入 127.0.0.1, localhost, ::1, [::1]，构造时显式传 { noProxy } 给 EnvHttpProxyAgent。
• NO_PROXY=* 时直接不装代理（尊重"全直连"通配）。
• 新增测试覆盖：分号列表、空 NO_PROXY、NO_PROXY=*、以及"空 NO_PROXY 下回环仍直连"。
• 加固后回环恢复直连（200）、出站仍走代理（401），dsh web 端到端正常。

一个残留限制（你可能也关注）：undici 的 NO_PROXY 匹配只支持精确主机名/子域名，10...* 这类通配符不生效，对内部 10.x.x.x 主机的 fetch 仍会走代理。这块我还在考虑要不要处理。

环境信息（你之前问的）：

• node -v：v24.19.0（已从 22.20 升级）
• dsh --version：0.1.1-rc.2
• 代理类型：HTTP（EnvHttpProxyAgent 可处理）