[BUG] 代理环境下 LLM API 请求全部失败：Node fetch (undici) 不读取 HTTP_PROXY/HTTPS_PROXY 环境变量

[ouspec-create]

Summary

在需要代理才能访问外网的网络环境（如 VMware NAT、公司代理、国内网络）下，dsh 的 LLM API 调用（chat/completions 等）全部失败；必须额外设置 Node 实验性开关 NODE_USE_ENV_PROXY=1 才能恢复。根因是 DSH 使用 Node 全局 fetch（undici），而 undici fetch 默认忽略 HTTP_PROXY / HTTPS_PROXY 环境变量。

Environment

• OS：Ubuntu（VMware 虚拟机，NAT 网络，需经宿主机代理访问外网）
• Node：v22.23.2（nvm 管理）
• dsh：0.1.1-rc.1（npm 全局安装 @deepseek-ai/dsh）
• 网络：必须经 HTTP 代理访问 LLM API；curl / npm / pip 均可正常走代理

Proxy 环境变量（已脱敏）

HTTP_PROXY=http://<host>:<port>
HTTPS_PROXY=http://<host>:<port>
NO_PROXY=localhost,127.0.0.1,<其他内网地址>
Steps to Reproduce
在 shell 中设置上述代理环境变量（此时 curl、npm 均正常走代理）；
正常启动 dsh，并配置使用 LLM API（如 DeepSeek API）；
发起对话请求。
复现并抓取报错日志（可选，便于维护者确认）：

bash
复制
unset NODE_USE_ENV_PROXY
dsh --profile headless "你好" 2>&1 | tee /tmp/dsh-error.log
Actual Behavior
请求直连外网、未走代理，全部失败，报错为网络层错误，例如：

复制
TypeError: fetch failed
cause: Error: connect ECONNREFUSED <host>:<port>
（视网络环境也可能是 ETIMEDOUT / ECONNRESET / 证书错误。判据：只要设置 NODE_USE_ENV_PROXY=1 后立即恢复正常，即可确认与"fetch 未走代理"相关。）

Expected Behavior
与 curl / npm 一致，自动读取 HTTP_PROXY / HTTPS_PROXY / NO_PROXY 环境变量；或提供显式的 proxy 配置项（如 config 中的 proxy 字段）。

Root Cause（初步定位）
@deepseek-ai/dsh-llm-deepseek 等包的 HTTP 调用使用 Node 全局 fetch（例如 lib/index.js:737 的 await fetch(\${connection.baseURL}/chat/completions`, ...)），未配置 undiciProxyAgent。而 Node 内置 fetch（undici）默认**不读取**HTTP_PROXY/HTTPS_PROXY` 环境变量（长期存在的生态问题，参见 nodejs/node#57165、openclaw/openclaw#20549）。因此在必须走代理的网络环境下必然失败。

Workaround（已确认有效）
设置 Node 实验性开关后恢复正常：

bash
复制
export NODE_USE_ENV_PROXY=1
（需 Node ≥ 22.21.0 或 ≥ 24.3.0；该特性由 nodejs/node#57165 引入。）

Suggested Fix
HTTP 层统一改用 undici ProxyAgent，按环境变量（HTTP_PROXY / HTTPS_PROXY / NO_PROXY）自动配置；注意 NO_PROXY 需放行 127.0.0.1 / localhost，避免 GUI（http://127.0.0.1:3080）回环请求被代理劫持；
或至少：显式支持 NODE_USE_ENV_PROXY，并在文档中补充代理配置说明；
影响面：dsh-llm-deepseek、dsh-llm-pi-ai、dsh-web-search-deepseek、dsh-host-apiproxy 等多个包。

[weijiafu14]

确认 +1，并补一个"独立撞上同一根因"的实证：我们的端到端验证装置（真 CLI + 真 OAuth 端点）在代理网络环境下同样全灭于 TRANSPORT: fetch failed，最终修法就是你说的 NODE_USE_ENV_PROXY=1——现在它被永久烤进了我们的 harness 环境（verify-codex-write-optional-e2e.mjs 里那段注释就是这次事故的尸检记录：undici 的 fetch 默认无视 HTTP_PROXY/HTTPS_PROXY）。

两个实务补充：

1. 这个坑的表现形态特别误导——报错是 fetch failed / Connection error，第一反应全是查 key、查端点、查网关，没人会想到是 Node 的 fetch 实现不读代理变量。我们也是先冤枉了两层别的东西才找到它。
2. 在官方修复（启动时自动设置该开关、或换 dispatcher 显式接代理配置）落地之前，任何写文档/装置的人都值得把 NODE_USE_ENV_PROXY=1 写进代理环境的前置说明——它是环境属性不是产品属性，但少写这一行，代理网络用户的第一条命令就是死的。

你提的"启动时检测 HTTP(S)_PROXY 存在则自动启用"是最小惊讶的修法，支持。

[alone-tree]

补充一个 Windows DSH Desktop 环境下的复现。

我在 DSH 中添加 OpenRouter 作为模型提供方，并在 %USERPROFILE%\.dsh\.env 中设置：

http_proxy=http://127.0.0.1:<PROXY_PORT>
https_proxy=http://127.0.0.1:<PROXY_PORT>
no_proxy=localhost,127.0.0.1,::1

但 DSH 并没有按预期将 OpenRouter 流量转发到代理端口。

实测结果：

• DSH 调用 OpenRouter 时返回地区限制 403；
• 代理软件中没有出现对应的 openrouter.ai 连接；
• 网络连接捕获显示，DSH 宿主进程直接连接了 openrouter.ai:443；
• 使用同一个 API Key、同一个模型，通过 curl.exe -x http://127.0.0.1:<PROXY_PORT> 显式指定代理后，模型可以正常回复 OK。

核心原因在于：Node 网络模块的初始化先于 DSH 对 .env 文件的读取。 DSH 启动后再读取代理变量，对已经初始化的 Node 原生 fetch 不生效，因此 OpenRouter 请求仍然直连。

临时解决方案是使用自定义 .cmd 脚本，在启动 DSH 前显式注入代理变量：

@echo off
setlocal

set "NODE_USE_ENV_PROXY=1"
set "http_proxy=http://127.0.0.1:<PROXY_PORT>"
set "https_proxy=http://127.0.0.1:<PROXY_PORT>"
set "no_proxy=localhost,127.0.0.1,::1"
set "HTTP_PROXY=http://127.0.0.1:<PROXY_PORT>"
set "HTTPS_PROXY=http://127.0.0.1:<PROXY_PORT>"
set "NO_PROXY=localhost,127.0.0.1,::1"

start "" "%LOCALAPPDATA%\Programs\DSH Desktop\DSH Desktop.exe"

使用该脚本启动后，OpenRouter 流量会正确转发到本地代理端口，再由代理软件根据域名规则选择代理节点。

环境信息：

• Windows 11
• DSH Desktop 2.0.10(anywhere-labs/dsh-desktop)
• DSH 内核 0.1.5-rc.2
• Electron 43.3.0
• Node.js 24.18.1

希望开发者能够调整代理配置的加载时机，在 Node 网络模块初始化前读取 DSH Home 下的 .env；或者确保 LLM 请求使用的 fetch 显式采用 DSH 配置的代理 dispatcher，使 .env 中的 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY 能按预期生效。