VS Code里“联网失败”至少可能指四件事：编辑器访问扩展市场失败、Git拉取失败、集成终端中的npm或curl失败、Remote SSH或开发容器无法下载远程组件。这些请求由不同进程、甚至不同机器发出，单改一个代理设置很难覆盖全部场景。
一、先确认哪个功能失败
| 功能 | 请求位置 | 优先检查 |
|---|---|---|
| 扩展搜索与安装 | 本地VS Code进程 | 编辑器网络设置、系统代理、证书 |
| Source Control拉取 | 本地或远程Git进程 | Git远程协议与Git配置 |
| 集成终端命令 | 终端Shell及子进程 | 工具配置、环境变量 |
| Remote SSH | 本地客户端与远程主机 | SSH链路、远程网络和CA |
| Dev Container | 容器内部 | 容器环境、DNS、证书与NO_PROXY |
二、VS Code编辑器代理控制什么
VS Code的网络相关设置主要影响编辑器自身和使用其网络栈的功能。具体设置键和默认行为会随版本变化，应在当前版本设置界面和官方说明中确认。不要从旧博客复制一组已弃用配置，也不要把带密码的代理URL同步到公开设置仓库。
三、为什么扩展市场能打开却安装失败
扩展详情、版本元数据和安装包可能经过不同请求或重定向。企业网络还可能限制特定下载域名。应查看VS Code日志中的实际主机、状态码和证书错误，避免只测试扩展市场首页。若使用离线VSIX，也应确认文件来源和完整性。
四、集成终端为什么不跟随编辑器
集成终端本质上是Shell。里面运行的npm、Git、Python或curl按各自规则读取环境变量和配置。编辑器本体能够访问扩展市场，不代表这些工具自动走相同出口。Node工具链配置可参考npm、pnpm和Yarn代理排查。
五、Git操作要先查看远程协议
HTTPS远程可以受Git的HTTP代理配置影响，SSH远程则走SSH自己的路径。如果命令行Git正常、VS Code失败，应比较VS Code实际调用的Git路径、运行环境和凭据助手；反过来也一样。详细方法见Git代理配置与凭据安全。
六、Remote SSH到底在哪边下载
Remote SSH包含本地连接过程和远程服务端组件。远程主机可能需要访问下载源，扩展也可能安装在本地或远端。故障时应在扩展面板确认安装位置，并检查远程主机的DNS、代理、系统时间和CA。不要只检测本地电脑公网出口。
七、Dev Container为什么又是一个新环境
容器拥有独立文件系统、环境变量、证书包和网络命名空间。宿主机设置的代理不一定进入构建阶段和运行容器，构建参数也不应包含会遗留在镜像层的明文密码。Docker三层代理差异见Docker Compose代理配置。
八、证书错误不要通过关闭校验长期处理
扩展市场或远程下载出现证书不受信任，应确认系统时间、操作系统与应用信任库、企业根证书分发和代理TLS检查。将SSL严格校验关闭会降低目标身份验证能力，还可能掩盖域名不匹配或中间证书缺失。
九、哪些日志值得看
- VS Code的窗口与共享进程日志；
- 扩展安装相关输出；
- Remote SSH或Dev Containers输出频道；
- Git输出和Git自身诊断；
- 代理端脱敏后的请求时间与状态码。
共享日志前要删除访问令牌、代理密码、远程主机名和项目敏感路径。
十、推荐排查顺序
- 记录VS Code版本与失败功能；
- 判断请求发生在本地、远程还是容器；
- 提取实际目标域名和错误阶段；
- 在同一环境执行最小网络测试；
- 核对代理、NO_PROXY、DNS和CA；
- 重启受影响进程，排除旧连接和旧环境；
- 清理临时代理、明文凭据和调试日志。
十一、结论
VS Code代理问题不能靠一个开关概括。把编辑器、Git、终端、Remote SSH和容器拆成独立网络环境，逐层确认请求位置，才能避免本地配置正常却在远端反复失败。
