VSCode插件更新慢的根源是Windows版VSCode默认访问境外扩展市场，需在Windows侧settings.json中配置Open VSX镜像源并彻底退出重启；WSL内插件须在Remote-WSL模式下单独安装，且语言服务器等额外下载不受镜像影响。
WSL 环境下 VSCode 插件更新慢，根本不是 WSL 的锅，而是 VSCode 进程运行在 Windows 上，仍走默认境外扩展市场（marketplace.visualstudio.com），和你是否用了 Remote-WSL 无关。只要 VSCode 主体是 Windows 版，网络请求就由 Windows 网络栈发出，镜像源必须改在 Windows 侧生效。
改 extensions.gallery.serviceUrl 是唯一有效起点
别信“换 DNS”或“清缓存”能解决本质问题——90% 的慢卡在首次 HTTP 请求超时。必须强制 VSCode 扩展市场走国内镜像。
- 打开 Windows 版 VSCode 的设置 JSON 文件：
%APPDATA%\Code\User\settings.json - 添加或替换整个
extensions.gallery配置块（注意不是只改serviceUrl字段）：
{
"extensions.gallery": {
"serviceUrl": "https://open-vsx.org/vscode/gallery",
"itemUrl": "https://open-vsx.org/vscode/item"
}
}
关键点：Open VSX 不依赖微软账户、无墙、CDN 稳定，且已同步 ESLint、Prettier、GitLens 等主流插件；但 Microsoft 官方扩展（如 ms-python.python）版本可能滞后 1–2 小时，功能无损。
改完后必须彻底退出 VSCode（右键任务栏 → “退出”，或 macOS 用 Cmd+Q），仅关窗口不生效。
code --install-extension 在 WSL 终端里失效？检查环境变量继承
你在 WSL 终端执行 code --install-extension，实际调用的是 Windows 上的 code.exe，它不会自动读取 WSL 里的 VSCODE_EXTENSIONS_MSA_URL 环境变量。
- 正确做法是显式传入镜像地址：
VSCODE_EXTENSIONS_MSA_URL=https://open-vsx.org code --install-extension esbenp.prettier-vscode - 如果仍报
connect ETIMEDOUT，大概率是系统代理干扰（比如 Clash/Clash for Windows 正在运行但未全局）；临时关闭代理工具，或加参数禁用：code --proxy-settings=off --install-extension esbenp.prettier-vscode - 某些插件（如
ms-python.python）安装后会额外下载语言服务器二进制包，这部分流量不走 gallery 协议，镜像源对其无效——此时只能手动下载对应平台的.vsix或语言服务器压缩包，再本地安装。
Remote-WSL 下插件“看起来没更新”，其实是加载位置错了
启用 Remote-WSL 后，VSCode 分为两层：Windows 上的 UI 进程 + WSL 里的 Server 进程。插件也分两类：
- UI 层插件（如主题、快捷键增强）：装在 Windows 用户目录，受上面说的镜像配置控制
-
WSL 层插件（如 Python、Docker）：需在 Remote-WSL 模式下，通过命令面板运行
Extensions: Install Local Extension (for WSL)安装，否则只装在 Windows 侧，对 WSL 内项目无效
常见错觉：“我点了更新，但 Python 补全还是旧的”——其实你更新的是 Windows 侧插件，而真正干活的是 WSL 侧那个没动过的旧版本。务必确认当前窗口右下角显示 WSL: Ubuntu（或你的发行版名）后再操作安装/更新。
最易被忽略的一点：extensions.gallery 配置只影响市场搜索与在线安装，不影响插件自身运行时的更新检查逻辑；部分插件（如 GitLens）会单独发起 HTTP 请求检查更新，这类请求无法被镜像覆盖，只能靠代理或手动下载新版 .vsix 替换。
