VSCode插件下载慢或超时主因是代理配置错误：http.proxy需带http://前缀、bypass列表排除localhost/127.0.0.1、代理须支持HTTPS CONNECT；https证书校验失败时需设"http.proxyStrictSSL": false；Remote-SSH需在远程Machine settings.json配代理；更稳方案是改extensions.gallery.serviceUrl为镜像源并彻底重启VSCode进程。
VSCode 插件下载慢或连接超时，90% 不是网络本身问题，而是它没走你预期的代理路径——http.proxy 配置错、被绕过、或根本没生效。
填了 http.proxy 还是连不上 Marketplace？检查这三处
VSCode 不继承系统代理，也不读 HTTP_PROXY 环境变量（除非你用终端启动且配置正确），它只认自己设置里的 http.proxy。但填了仍失败，常见原因有：
-
http.proxy值漏了http://前缀，比如写成127.0.0.1:7890→ VSCode 会静默忽略，必须写成http://127.0.0.1:7890 - Windows/macOS 默认把
localhost和127.0.0.1加入 bypass 列表，导致请求根本没发给代理；统一改用127.0.0.1，别写localhost - 代理服务监听的是
127.0.0.1:7890，但没开 HTTPS 中转能力（比如 Clash 默认只开 HTTP 代理端口），而 Marketplace 请求是 HTTPS，需确认代理支持 HTTPS CONNECT
http.proxyStrictSSL 必须设为 false 的真实场景
不是所有代理都用可信 CA 签发证书。当你用 Charles、Fiddler、自建 mitmproxy 或企业中间人代理（如 Zscaler）时，VSCode 会因证书校验失败直接中断连接，控制台报 DEPTH_ZERO_SELF_SIGNED_CERT 或空白页加载失败。
- 必须在 settings.json 里加
"http.proxyStrictSSL": false - 仅限你信任该代理环境时启用；公共网络下不建议长期开启
- 如果代理本身是标准 HTTPS 代理（如 Clash、Surge 默认配置），此项可省略
Remote-SSH 场景下插件安装失败？代理配置位置错了
本地 VSCode 的 http.proxy 设置不会透传到远程服务器。Remote 插件安装失败，几乎全是远程端没配代理。
- 远程机器上编辑
~/.vscode-server/data/Machine/settings.json（注意是Machine，不是User或Remote） - 写入：
"http.proxy":"http://your-proxy:8080"，同样要带协议前缀 - 修改后必须重启 remote server：断开 SSH 连接，再重新连接，热重载无效
- 别在
~/.bashrc里export HTTP_PROXY—— vscode-server 启动时不加载 shell 配置
比代理更稳的方案：extensions.gallery.serviceUrl 换镜像源
代理容易受本地防火墙、杀毒软件拦截（尤其国产安全软件对 cdn.azure.cn 域名静默丢包），而直接换扩展市场地址更底层、更可靠。
- 在用户 settings.json 里加：
"extensions.gallery.serviceUrl": "https://vscode.cdn.azure.cn/extensionGallery/extensionGallery/"（末尾斜杠不能少） - 保存后必须彻底退出 VSCode 进程（任务栏右键 → 退出 / Activity Monitor 杀光所有
Code进程），否则旧连接缓存还在 - 公司网络若拦截非微软域名，可换阿里云：
"extensions.gallery.serviceUrl": "https://vscode-extensions.oss-cn-hangzhou.aliyuncs.com/extensionGallery/extensionGallery/" - 这个配置不影响自动更新，想让更新也走镜像，还得改
product.json文件
最常被忽略的一点：VSCode 的扩展主机（Extension Host）进程会缓存网络配置，哪怕你改了设置，它也可能继续用旧的连接逻辑。关掉所有窗口后，手动杀掉残留的 Code Helper 或 code 进程，比反复重启更有效。
