先看左下角：你在本机、WSL、容器还是远程主机

失败操作请求可能在哪里发起
更新编辑器或浏览扩展市场本机编辑器网络栈
某个扩展访问 API扩展运行位置及它自己的网络实现
集成终端里的 npm / Git终端所属环境和工具本身
Remote SSH 安装远端服务本地或远端，取决于阶段和配置
容器中的 pip 或 curl容器网络，并非宿主回环地址

记录本机 VS Code 版本、远程类型和具体报错。浏览器能打开扩展市场，不代表远端主机能下载扩展依赖；编辑器连接成功也不意味着集成终端自动继承所有代理配置。先确定请求所在环境，可以少改很多无关设置。

第一步：验证编辑器自身网络

  1. 按 VS Code 官方网络说明检查系统代理，退出全部编辑器窗口后重新启动，以免旧进程仍持有原设置。
  2. 重试扩展市场搜索或更新，打开“输出”中与该功能相关的频道，以及通知中的详细错误。记录失败域名与 HTTP / TLS 错误。
  3. 按官方列出的网络主机要求检查访问范围。主站可达但下载 CDN 不可达时，应处理实际失败域名，不能仅凭首页返回 200 宣称联网正常。

VS Code 主程序使用系统网络栈；官方同时说明扩展与 CLI 仍存在代理支持边界。http.proxy 等设置不能被当作一个覆盖所有终端和远程进程的总开关。若某扩展有独立代理、证书或服务端设置，按该扩展自己的官方说明核对。

第二步：在集成终端中做明确的单次请求

在发生问题的那个终端里运行；Windows 使用 curl.exe
curl --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 -I https://example.com

先确认该终端在本机还是远端。远程服务器、WSL NAT 或容器里的 127.0.0.1 不一定能访问你电脑的代理。不要在不知道监听与认证范围的情况下，把本机代理开放到公网给远端使用；优先使用组织支持的远端出口方案。

显式 curl 成功后，Git、npm 和 pip 仍需按各自配置验证。Git 的 HTTPS 与 SSH 依赖也不同。某个工具错误若是权限、分支冲突或缺少解释器，应回到该问题本身，而非继续改代理。

第三步：单独核对远端服务和扩展

  1. 查看远程连接输出，区分连接主机失败、安装服务失败和安装扩展失败。三种情况的修复对象不同。
  2. 根据实际错误确认下载发生在本地还是远端，再在同一环境测试目标。VS Code Server 和某些扩展还需下载第二阶段依赖。
  3. 受限制环境按官方支持的离线或管理员分发方式安装；从可信来源取得 VSIX 并核对适用平台，避免把离线安装当作绕过来源核验的办法。

证书错误和恢复

企业网络如需受信任 CA，应由管理员提供并按本机、远端和工具各自的信任方式安装。不要关闭 http.proxyStrictSSL 或使用忽略证书错误的启动参数来永久消除提示。修改前记录设置属于用户、工作区还是远端范围，防止把代理凭据提交进 .vscode/settings.json。

验收时分别完成一次扩展下载、原终端操作和远程重连；已有缓存不能替代网络验证。撤销无效的代理参数、工作区覆盖和临时启动选项，重开编辑器确认正常。提交问题时附脱敏的相关输出频道，而不是整个项目、完整环境变量和订阅文件。