插件下载慢主因是VSCode未走预期代理：90%失败源于http.proxy格式错误（须带http://前缀、用127.0.0.1而非localhost）、被系统bypass规则拦截，或Remote场景未在远程Machine/settings.json中配置代理并重启SSH；更稳方案是将extensions.gallery.serviceUrl改为https://vscode.cdn.azure.cn/_apis/public/gallery并彻底重启VSCode进程。
直接结论：插件下载慢不是网络差，而是 VSCode 没走你设的代理——90% 的失败源于 http.proxy 格式错误、被系统 bypass 规则拦截，或 Remote 场景配错位置。
http.proxy 必须带 http:// 前缀且用 127.0.0.1，不能写 localhost
VSCode 会静默忽略不带协议头的值，比如 "http.proxy": "127.0.0.1:7890" 完全无效；localhost 不仅部分版本解析异常，还默认被 Windows/macOS 的 bypass 规则拦截，请求根本不会发给代理进程。
- ✅ 正确写法：
"http.proxy": "http://127.0.0.1:7890"（Clash 默认 HTTP 端口） - ❌ 错误写法：
"http.proxy": "127.0.0.1:7890"、"http.proxy": "localhost:7890"、"http.proxy": "https://127.0.0.1:7890" - 需认证时密码含
@或:，必须 URL 编码，例如user:pass%40word@127.0.0.1:7890
证书校验失败时必须加 http.proxyStrictSSL: false
当你用 Charles、Fiddler、mitmproxy 或企业中间人代理（如 Zscaler）时，VSCode 会因自签名证书报 DEPTH_ZERO_SELF_SIGNED_CERT，表现为 Marketplace 空白页、插件卡在 0% 或控制台报错。
- 必须在
settings.json中显式添加："http.proxyStrictSSL": false - 此项仅限你信任该代理环境时启用；公共网络下不建议长期开启
- 标准 HTTPS 代理（如 Clash/Surge 默认配置）通常不需要此配置
Remote-SSH 场景下插件装不了？代理没配到远程机器
本地 VSCode 的 http.proxy 对远程服务器上的 vscode-server 进程完全无效。Remote 插件安装失败，几乎全是这个原因。
- 正确路径是修改远程机上的
~/.vscode-server/data/Machine/settings.json（注意是Machine，不是User或Remote） - 内容示例：
{"http.proxy":"http://192.168.1.100:7890","http.proxyStrictSSL":false} - 改完必须彻底断开 SSH 连接并重连，热重载或窗口重载无效
- 别在
~/.bashrc里export HTTP_PROXY——vscode-server启动时不加载 shell 配置
比代理更稳的方案：extensions.gallery.serviceUrl 换镜像源
代理容易被国产杀毒软件、防火墙静默拦截（尤其对 cdn.azure.cn 域名），而换镜像源是底层协议级替换，覆盖所有插件市场请求，重启即生效。
- 推荐镜像：
"extensions.gallery.serviceUrl": "https://vscode.cdn.azure.cn/_apis/public/gallery" - 必须同时配缓存地址：
"extensions.gallery.cacheUrl": "https://vscode.cdn.azure.cn/_apis/public/gallery/publishers" - 结尾不能带
/，否则 404；路径必须完整匹配微软原协议结构 - 清华/阿里等第三方镜像近年稳定性下降，
vscode.cdn.azure.cn是微软官方运营，SHA256 校验一致
最易被忽略的是：VSCode 进程必须彻底退出（任务管理器杀掉所有 code.exe 或 code Helper 进程），再重启——只关窗口不生效。Remote 场景下，远程 vscode-server 进程也得重启，不是重连就能读新配置。
