VSCode本身不管理Node环境或证书信任，真正起作用的是环境变量、系统证书库及启动时的运行时上下文；需通过NODE_EXTRA_CA_CERTS显式指定企业根证书路径，并针对Remote-SSH等独立组件另行配置SSH证书信任机制。
VSCode 本身不管理 Node 环境或证书信任——它只是调用你系统里已有的 Node.js 和 Electron 网络栈。真正起作用的是环境变量、系统证书库、以及 VSCode 启动时加载的运行时上下文。
设置 NODE_EXTRA_CA_CERTS 让 Node.js 进程信任私有 CA
VSCode 内置终端、调试器、扩展（如 ESLint Server、TypeScript Server）启动的 Node.js 子进程，默认只信任操作系统证书库，不会自动加载企业内网根证书。必须显式告诉 Node.js 哪里找额外证书：
- 把 PEM 格式的根证书（例如
internal-ca.pem）存到固定路径，如 Linux/macOS 下/opt/certs/internal-ca.pem，Windows 下C:\certs\internal-ca.pem - 启动 VSCode 前注入环境变量：
NODE_EXTRA_CA_CERTS=/opt/certs/internal-ca.pem code（Linux/macOS），或set NODE_EXTRA_CA_CERTS=C:\certs\internal-ca.pem & code（Windows CMD） - 若通过桌面图标启动，需修改
.desktop文件（Linux）或快捷方式属性（Windows），在Exec=行前加环境变量前缀 - 验证是否生效：打开 VSCode 终端，执行
console.log(process.env.NODE_EXTRA_CA_CERTS)，再试curl https://gitlab.internal（需先装 curl）
禁用 http.proxyStrictSSL 仅覆盖部分 HTTP 客户端
这个配置只影响 VSCode 自身的 HTTP 请求（比如扩展市场、Copilot API、Settings Sync），对 Remote-SSH、Tabnine、调试器内置的 TLS 连接无效：
- 在
settings.json中设"http.proxyStrictSSL": false，可解决 Copilot 模型加载失败、扩展更新报net::ERR_CERT_AUTHORITY_INVALID - 但 Git 操作、Remote-SSH 连接、自托管 AI 插件仍会失败——它们走的是独立 TLS 栈，不读该配置
- 不要把它当成全局开关；它只是绕过代理层的 SSL 验证，不是让 Node.js 或 SSH 信任证书
别用 NODE_TLS_REJECT_UNAUTHORIZED="0" 除非你清楚后果
这个环境变量会让所有 Node.js TLS 连接跳过证书校验，看似“一劳永逸”，但风险极高：
- 它影响整个 VSCode 进程及其所有子进程（包括调试器、任务脚本、自定义构建命令）
- 一旦启用，任何中间人攻击都不可检测，尤其在共享开发机或 CI 环境中极其危险
- VSCode 2026 版本已默认启用 SM2/SM4 国密算法校验，设为
"0"可能导致国密握手失败或静默降级 - 正确做法是：用
NODE_EXTRA_CA_CERTS+ 系统级证书安装，而非全局关闭验证
国产化系统（麒麟/UOS）下证书路径和更新逻辑不同
Linux 发行版之间证书管理机制差异大，不能照搬 Ubuntu 的 update-ca-certificates：
- 麒麟 V10 使用
ca-certificates包，但证书目录常为/etc/pki/ca-trust/source/anchors/，需用update-ca-trust（非update-ca-certificates）刷新 - UOS 默认不挂载
/etc/ssl/certs，而是用/usr/share/ca-certificates/mozilla/，且需手动执行dpkg-reconfigure ca-certificates - VSCode 启动时若使用 snap 或 flatpak 打包版本，其沙箱环境可能隔离系统证书路径，此时
NODE_EXTRA_CA_CERTS是唯一可靠方式
最易被忽略的一点：VSCode 的 Remote-SSH 扩展根本不读 NODE_EXTRA_CA_CERTS，它复用 OpenSSH 客户端，必须把证书导入 ~/.ssh/known_hosts 或配置 ssh_config 的 VerifyHostKeyDNS 和 StrictHostKeyChecking——这和 HTTPS 证书信任是两套完全独立的机制。
