vscode remote-containers插件不继承终端docker cli配置，导致镜像拉取失败；需检查凭据、镜像源兼容性、插件版本及避免postcreatecommand隐式拉取。
Dev Containers 扩展与 Docker CLI 镜像拉取行为不一致
VSCode 的 Remote - Containers 插件在执行 Reopen in Container 时，并不会直接调用你终端里敲的 docker pull，而是通过自己的 Docker API 客户端发起请求，且会绕过部分本地 CLI 的配置（比如 shell alias、~/.docker/config.json 中的 credential helpers 或自定义 registry）。这导致你在终端能成功拉取的镜像，在 VSCode 里却报 unauthorized: authentication required 或 pull access denied。
常见诱因包括：
-
devcontainer.json中指定了私有 registry 镜像（如my-registry.example.com/myapp:latest），但未在~/.docker/config.json中配置对应凭据，或凭据已过期 - 你使用了 Docker Desktop 的“Cloud Sync”功能，而 VSCode 插件读取的是系统级 daemon 配置，两者认证上下文分离
- 插件启动时未继承当前 shell 的
DOCKER_HOST或DOCKER_CONTEXT环境变量，连错了 Docker daemon 实例
vscode-dev-containers 启动时静默跳过镜像源配置
即使你已正确配置 /etc/docker/daemon.json 并确认 docker info | grep -A 5 "Registry Mirrors" 显示生效，VSCode 的容器启动流程仍可能忽略它——因为插件内部调用的是 docker build 或 docker run --pull=always，而某些旧版插件（v0.290 之前）对 registry-mirrors 的兼容逻辑存在缺陷，尤其在使用 build.context + Dockerfile 场景下，会直接走默认 registry 而非镜像源。
验证方式很简单：打开 VSCode 的“输出”面板，切换到 Remote - Containers 日志通道，搜索 Pulling image 行。如果看到类似 Pulling image docker.io/library/node:18-slim，说明它没走镜像源；而正常应显示 Pulling image docker.mirrors.ustc.edu.cn/library/node:18-slim。
临时缓解方法：
- 在
.devcontainer/devcontainer.json的build段显式指定镜像源前缀："dockerfile": "Dockerfile"→ 改为"image": "docker.mirrors.ustc.edu.cn/library/node:18-slim" - 升级 Remote - Containers 插件至 v0.302+（2026 年 7 月后发布），该版本修复了 daemon.json 镜像源在 multi-stage 构建中的穿透问题
扩展之间共享 Docker socket 权限引发的 403 错误
当你同时启用 Docker（由 Microsoft 提供）、Remote - Containers 和第三方容器管理插件（如 Portainer 或 Kubernetes Tools）时，它们可能竞争对 /var/run/docker.sock 的访问控制。典型现象是：首次 Reopen in Container 成功，第二次就卡在 Building image 并最终报 Got permission denied while trying to connect to the Docker daemon socket。
这不是权限缺失，而是某个插件在后台调用了 docker system prune -f 或修改了 socket 文件的 ACL，导致其他插件连接失败。VSCode 插件日志中会出现 connect EACCES /var/run/docker.sock。
解决路径很直接：
- 禁用所有非必需的 Docker 相关插件，只保留
Remote - Containers和Docker官方插件 - 检查
ls -l /var/run/docker.sock输出，确保属组为docker且权限为srw-rw---- - 重启 Docker daemon：
sudo systemctl restart docker，再重启 VSCode（不是重载窗口）
devcontainer.json 中的 postCreateCommand 触发隐式镜像拉取
很多人把构建逻辑全塞进 postCreateCommand，比如写成 "postCreateCommand": "docker pull python:3.11 && pip install -r requirements.txt"。这看似方便，实则埋雷：VSCode 会在容器启动后、执行该命令前，先尝试拉取一个基础镜像来运行这个命令——但它拉取的是 python:3.11，而不是你 devcontainer.json 顶层声明的 image 或 dockerfile 对应的镜像。一旦该镜像在你的镜像源中不可用或需鉴权，整个流程就中断，且错误堆栈里根本不会提示这是 postCreateCommand 引起的。
更稳妥的做法是把这类操作移到 Dockerfile 中，或改用 onCreateCommand（在镜像构建完成后、容器启动前执行），避免多阶段拉取。
特别注意：postCreateCommand 默认以 root 用户执行，若镜像内未预装 docker-cli，该命令会直接报 command not found，而非拉取失败——这种静默失败最容易被忽略。
