[Bug] 配置 HTTP(S)_PROXY 后宿主 fetch 不再跟随任何 3xx：模型下载报 HTTP 308（app undici 8.11.0 × 运行时 undici 7.x）

[Zleitai]

按照官方文档《在网络代理后面运行 DSH》把 HTTP_PROXY / HTTPS_PROXY 写进 $DSH_HOME/.env 之后，宿主进程里的 fetch 不再跟随任何 3xx 重定向——响应状态码能到，但 Location 头读不到（redirect: 'manual' 也是空的），于是 3xx 被当成最终响应返回。

直接后果：语音输入插件首次准备模型时下载失败，界面提示 无法下载 model.int8.onnx：下载服务返回 HTTP 308。（下载源
https://hf-mirror.com/
）。任何依赖重定向的宿主 fetch 流程都会同样失败。

[Zleitai]

环境

• @deepseek-ai/dsh-desktop 0.1.7-rc.2（nightly），Windows 11 x64，zh-CN
• Electron 44.0.0、运行时 Node 24.18.1
• app 自带 node_modules/undici：8.11.0
• 运行时内置 undici：7.x（在 Node 24.21.0 上实测 7.29.1）
• 代理：本地 HTTP 代理（HTTP_PROXY=http://127.0.0.1:<port>、HTTPS_PROXY=同），写在 ~/.dsh/.env，即文档描述的方式

复现步骤

1. 在 $DSH_HOME/.env 写入 HTTP_PROXY / HTTPS_PROXY（文档推荐做法）。
2. 重启 DSH → 插件 → 语音输入 → 点「重试准备」。
3. 观察到：无法下载 model.int8.onnx：下载服务返回 HTTP 308。，下载来源 https://hf-mirror.com。

进程内最小复现（同一个 URL，五种传输对照）：

const url = 'https://hf-mirror.com/<repo>/resolve/<rev>/tokens.txt';

// A. 已安装出厂策略 dispatcher（线上路径）：3xx 被当作最终响应
await fetch(url);
//   → status=308, res.url 仍是 hf-mirror.com, res.headers.get('location') === ''
//   → 对 huggingface.co/…/resolve/… 同样：status=307

// B. 同一策略 + redirect: 'manual'
await fetch(url, { redirect: 'manual' });
//   → status=308, location === ''      ← 连手动跟随都拿不到目标

// C. 对照：不安装代理策略
await fetch(url);                      // → 206，最终 URL 落到 huggingface.co

// D. 对照：用 app 那份 undici@8 自己的 fetch + 它自己的 dispatcher
appUndici.fetch(url, { dispatcher: new appUndici.ProxyAgent({ uri: proxy }) });   // → 206

// E. 把 app 的 undici@8 Agent/ProxyAgent 直接交给内置 fetch
await fetch(url, { dispatcher: new appUndici.Agent() });
//   → TypeError: fetch failed — cause: invalid onRequestStart method

两个源的 resolve 链接本来就是重定向链（308 → 307/302 → 200），所以任何固定资源下载都会踩到；界面显示的 308 只是"最后尝试的那个源"的状态（SpeechDownloadError 的 reason: "http"）。

期望 vs 实际

期望	3xx 被正常跟随（包 README 明确说下载/探测"跟随重定向"；网络代理文档也引导用户导出这些变量）
实际	3xx 作为最终响应返回，且 Location 在 fetch 层不可见，调用方无法跟随

疑似根因

@deepseek-ai/dsh-http-proxy 用 app 自带的 undici@8.11.0 构造全局 dispatcher（createPolicyDispatcher → new Agent({ factory }) → ProxyAgent/Pool）并 setGlobalDispatcher，于是运行时内置的 fetch（undici 7.x）通过 legacy 槽位拿到的是一个跨大版本的 dispatcher。该包 README 自己就标注了这个耦合：

Reaching Node's built-in fetch from a userland undici relies on both writing the legacy Symbol.for('undici.globalDispatcher.1') slot. That is an implicit cross-version coupling, not a contract — see corepack#834

对照 C/D/E 说明问题在版本边界而不是代理本身：同一代理、同一 URL，不装 dispatcher 或用 undici 8 自己的 fetch 都是 206；而把 undici 8 的 Agent 交给内置 fetch 会直接在 onRequestStart 契约上报错。

影响面

• 托管资源下载（已复现：@deepseek-ai/dsh-experimental-speech-to-text-sensevoice 的 assets.json 固定 URL）
• 其它依赖 3xx 的资源/鉴权获取
• 依赖 redirect: 'manual' 读取 Location / set-cookie 的流程
• 附带影响：装了策略后，代理一旦不在线，宿主所有出站请求都会 ECONNREFUSED，且没有自动回退直连

修复建议

1. 让 dispatcher 的 undici 大版本与运行时内置版本保持一致（或在可用时委托给运行时自带的 env-proxy 支持）。
2. 加一条冒烟测试：安装策略后断言某个 302 响应确实被跟随（一个 fixture 就能拦住这个回归）。
3. 退一步：检测到版本不匹配时在启动阶段显式报错，而不是让 3xx 静默返回给调用方。

临时规避

不要把代理变量写进 .env（这样应用就不会动内置 fetch）；改用 TUN 模式透明代理，或只在确需代理的单条命令上临时设置变量。