最常见原因是系统bypass规则拦截127.0.0.1导致请求未发往代理，需显式配置http://127.0.0.1:7890、禁用http.proxyStrictSSL以绕过自签名证书校验，并在Remote-SSH场景下于远程Machine/settings.json中单独配置代理并重启连接。
为什么填了 http.proxy 还是报 Failed to fetch
最常见原因是 VSCode 发往 127.0.0.1:7890 的请求被系统自动绕过——Windows/macOS 默认把 localhost 和 127.0.0.1 加入 bypass 列表，VSCode 根本没把流量送进代理进程。
验证方法很简单：终端执行 curl -x http://127.0.0.1:7890 https://httpbin.org/ip。如果返回的是你本地 IP 而不是代理出口 IP，说明请求压根没走代理。
- 必须用
http://127.0.0.1:7890，别写localhost:7890或127.0.0.1:7890（缺http://前缀会被静默忽略） - 代理服务本身要监听
127.0.0.1:7890（不是仅0.0.0.0:7890），且 HTTP 端口已开启 - Clash/Surge 类工具需确认
allow-lan: true已启用，否则局域网其他设备无法中转
http.proxyStrictSSL 为什么必须设为 false
很多本地代理（比如 Charles、旧版 Fiddler、自建 mitmproxy）用的是自签名证书，VSCode 内置的 Electron 证书校验会直接拒绝连接，报错类似 DEPTH_ZERO_SELF_SIGNED_CERT 或空白响应页。
VSCode 不走系统根证书库，它只认自己内置的证书列表，所以加系统信任链没用。
- 加
"http.proxyStrictSSL": false是唯一有效绕过方式（仅限调试或可信内网环境） - 企业中间人代理（如 Zscaler、Netskope）几乎必须开这一项
- Clash/Surge 等标准代理通常不需要，但开了也无害
Remote-SSH 场景下插件装不了，该配哪边的 http.proxy
本地 VSCode 的 http.proxy 设置对远程服务器上的 vscode-server 进程完全无效——Remote 插件安装失败，90% 是因为没在远程机器上单独配代理。
正确路径是修改远程机上的 ~/.vscode-server/data/Machine/settings.json（注意是 Machine 目录，不是 User 或 Remote）。
- 内容示例：
{"http.proxy":"http://192.168.1.100:7890","http.proxyStrictSSL": false} - 改完必须重启 SSH 连接（不是重载窗口），否则不生效
- 别指望
export HTTP_PROXY放在~/.bashrc里——SSH 非交互式 shell 不 source 它，vscode-server也完全不认
代理和镜像源能同时用吗？优先级怎么算
能共存，但作用完全不同：http.proxy 管「网络通路」，extensions.gallery.serviceUrl 管「下载地址」。网络不通时换源没用；网络通了但官方域名被污染或响应慢，光配代理也不够快。
比如你配了代理却仍卡在 marketplace.visualstudio.com，大概率是 DNS 劫持或 CDN 回源异常，这时换清华源或 vscode-cn 才是正解。
- 清华源地址：
"https://mirrors.tuna.tsinghua.edu.cn/vscode/extensions" - vscode-cn 地址：
"https://vscode.cdn.azure.cn/_apis/public/gallery" - 改
product.json生效最快，但 VSCode 升级后会被覆盖；改用户settings.json更持久，但部分旧版本不识别extensions.gallery.*字段
真正容易被忽略的是：Remote-SSH 下的 vscode-server 启动时只读一次 Machine/settings.json，改完不重启连接等于白改；另外，http.proxy 的协议前缀、IP 写法、bypass 规则这三点，错一个就全盘失效。
