windows 10 64位

结论：这不是项目代码导致的，是微信开发者工具 CLI/上传链路没有完全吃到“开发者工具不使用代<br />  理”这个设置，上传时仍会从系统/Chromium 代理解析里取代理。<br /><br /><br />  关键证据：<br /><br /><br />  - CLI 预览入口 /D:/path/cli-agent-run/devtools-<br />    asar/13ff54aebf81f1760f82320713227f2b.js:2 只做 initElectronBackend(...) 然后<br />    ICLIUtilsService.doUpload(...)，没有看到它主动把代理切成 DIRECT。<br /><br /><br />  - 上传实现 /D:/path/cli-agent-run/devtools-asar/527609dda0ad86da09fa2e9c04f60db9.js:2<br />    在 COS 上传时直接传：<br />    Proxy: I.getProxyForURL(o)<br /><br /><br />  - 这个 getProxyForURL 在 /D:/path/cli-agent-run/devtools-<br />    asar/8528f02482301c6722acbb03e03efe1d.js:80 里调用的是：<br />    nw.App.getProxyForURL(url)<br />    也就是 Chromium/NW 的代理解析，不是项目配置。<br /><br /><br />  - 设置页只是保存 proxyType，见 /D:/path/cli-agent-run/devtools-asar/<br />    f01e02bf2f304d23ee98e93fdfe875a2.js:2。真正生效要靠后端 ProxyService 初始化并 setProxy。<br /><br /><br />  - Electron 版 ProxyService 确实有 DIRECT -> mode: "direct" 的逻辑，见 /D:/path/cli-<br />    agent-run/devtools-asar/ac7bc06c35c611c6329270682ff003c6.js:2，但 CLI 上传路径看起来没有稳定地<br />    套上这层。<br /><br /><br />  - 本地日志里同样的错误从 2026-07-01 就反复出现：tunneling socket could not be established,<br />    cause=getaddrinfo ENOTFOUND 7890，说明这是工具上传网络层长期在读代理，不是这次改动引起的。<br /><br /><br />  ENOTFOUND 7890 说明某个请求层最后把 7890 当成主机名去解析了。结合你说系统 Internet 代理是<br />  127.0.0.1:7890，源码路径上最合理的解释是：CLI 上传链路仍读到了系统代理/Chromium 代理配置，并且在<br />  某层代理字符串解析时坏掉了。<br /><br /><br />  临时处理建议：跑 CLI preview/upload 前先关闭 Windows 的 Internet 代理，而不是只在开发者工具 UI 里<br />  选“不使用代理”。这个工具设置对 GUI session 可能生效，但对当前 CLI 上传链路不可靠。

系统设置了代理 127.0.0.1:7890 ，虽然开发者工具选择的是不走代理，但上传时还是读了系统代理而且解析错误。