1. Docker Sandboxes 到底是什么

先说明这个工具是什么、不是什么。

  • 它不是普通容器。 它借用了 Docker 的名字，内部也确实使用了容器。但每个沙箱会话运行在它自己的 微型虚拟机 中，拥有自己的内核。这是真正的硬件级隔离，类似完整虚拟机，而不是普通容器那种轻量级隔离。
  • 它不需要 Docker Desktop。 它自带一个命令行工具 sbx。你可以在从未安装过 Docker Desktop 的机器上直接使用。
  • 每个沙箱都有自己的私有 Docker 守护进程。 这是它与其它代理沙箱工具的主要区别。代理可以在沙箱内完整运行 docker build、docker run 和 docker compose，完全不需要宿主机上的 Docker 环境。
  • 隔离边界是虚拟机监控程序，而不是进程。 即使代理行为异常或被攻破，它也无法访问宿主机文件、宿主机 Docker 守护进程、其它沙箱或你的网络。它只能访问你明确允许的内容。

为了让这套机制跨平台工作，Docker 自己实现了 虚拟机监控程序（VMM），没有使用 Firecracker，因为 Firecracker 只支持带 KVM 的 Linux。Docker 的 VMM 原生使用：

  • macOS：Apple 的 Hypervisor.framework
  • Windows：Windows Hypervisor Platform (WHP)
  • Linux：KVM

这就是沙箱几乎能瞬间启动的原因，即使它们使用的是虚拟机级隔离。通常虚拟机启动比容器慢得多，但 Docker 绕过了这个问题。

如果你直接把代理跑在笔记本上，代理可以执行像 rm -rf 这样的命令、读取你的密钥，或者破坏你当前会话能访问的一切。Docker Sandboxes 的思路很简单：AI 模型不应该自己决定安全边界，这个决定应该来自它周围的系统。

2. 它是如何构建的（架构）

关键事实如下，依据 Docker 自己的安全文档：

  • 你的项目文件夹是通往宿主机的唯一默认桥梁。 默认情况下，Docker Sandboxes 将你的项目文件夹以读写方式挂载进沙箱。这是代理在你这台机器上唯一能看到的宿主文件。其它东西——你的其它文件、宿主机 Docker 守护进程、你的网络——都完全在沙箱之外。
  • 网络流量经过代理。 代理根据允许/拒绝列表检查每个出站请求，并在代理层注入凭据，例如你的 GitHub 令牌或模型 API 密钥。代理进程本身可能永远看不到真实的秘密，它只能对已批准的目的地使用这些秘密。
  • 沙箱内的一切都可以丢弃。 已安装的软件包、下载的镜像、正在运行的容器、shell 历史，全部存放在沙箱自己的文件系统中。移除沙箱后，这些全部消失，宿主机不受影响。

免责声明： Docker Sandboxes 很新。Docker 在 2025 年 12 月首次展示它，并在 2026 年 3 月左右正式推出。工具变化很快。截至撰写本文，当前稳定版本是 v0.38.0（2026 年 8 月 4 日发布）。有些功能，例如自定义“工具包”，仍标记为 早期访问。因此命令可能会变。始终运行 sbx version 检查你本机的版本，并查看 官方文档。

3. 在 Linux、macOS 和 Windows 上安装 Docker Sandboxes

3.1 各平台需要什么

  • Linux：需要内核支持 KVM，当前用户必须能访问 /dev/kvm。如果你在虚拟机或 VDI 环境里运行，还需要开启嵌套虚拟化。
  • Windows：需要启用 Windows Hypervisor Platform，并重启系统。管理员 PowerShell 是必需的。
  • macOS：使用 Apple 的虚拟机框架，无需额外安装 hypervisor。
  • 所有平台都必须登录 Docker 账户；sbx login 是强制步骤，不是可选项。

3.2 Linux：检查 KVM 是否可用

先检查 KVM 模块是否启用，可以省去后面排查问题的时间。

lsmod | grep kvm

你应该能看到 kvm_intel、kvm_amd 或 kvm 存在。

再确认内核模块和 libvirtd 状态：

kvm_intel             552960  0
kvm                  1527808  1 kvm_intel
irqbypass              16384  1 kvm

如果没有任何输出，运行 kvm-ok 查明原因。没有 KVM，sbx 无法启动。

你还需要把自己的用户加入 kvm 组：

sudo usermod -aG kvm $USER

然后注销并重新登录，或者运行 newgrp kvm 让组变更生效。

还有一件事： 如果你是在虚拟机或 VDI 环境里运行这套设置，需要 开启嵌套虚拟化。Docker Sandboxes 本身是虚拟机监控程序工具，外层虚拟机必须允许内部创建虚拟机。

  • 如何在 Proxmox VE 中启用嵌套虚拟化
  • 如何在 Linux KVM 中启用嵌套虚拟化
  • 如何在 VirtualBox 中启用嵌套虚拟化

3.3 Windows：先打开虚拟机监控程序

以管理员身份打开 PowerShell，然后运行：

Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All

开启后重启系统，再继续安装。

3.4 安装命令

Linux（Ubuntu）：

curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt install docker-sbx
sbx login

macOS：

brew trust docker/tap
brew install docker/tap/sbx
sbx login

Windows：

winget install -h Docker.sbx
sbx login

运行 sbx login 后，终端会显示类似下面的信息：

Your one-time device confirmation code is: XXXX-XXXX
Open this URL to sign in: https://login.docker.com/activate?user_code=XXXX-XXXX
By logging in, you agree to our Subscription Service Agreement. For more details, see https://www.docker.com/legal/docker-subscription-service-agreement/
Waiting for authentication...

打开浏览器，粘贴给出的 URL，完成 Docker 登录流程。

点击 Configure 注册你的设备。

登录 Docker 账户是必需的。第 8 节解释了原因。

如果你无法使用包管理器，也可以从 Docker 的 GitHub 上的 sbx-releases 页面下载预编译二进制。想提前拿到修复，可以安装 nightly 构建，例如 brew install docker/tap/sbx@nightly。

3.5 检查版本并保持更新

$ sbx version
sbx version: v0.38.0 c022b14634c4bea846ca12870d1d5e97d5868b54

升级命令：

# Linux (Ubuntu)
sudo apt-get update && sudo apt-get install --only-upgrade docker-sbx
# macOS
brew upgrade docker/tap/sbx
# Windows
winget upgrade Docker.sbx

在 Windows 或通过 Homebrew 升级时，后台守护进程 sandboxd 会自动重启，不需要手动执行这一步。

3.6 一些 Windows 特有提示

这些是真实用户报告中常见的问题：

  • 运行 winget install 之后，sbx.exe 可能位于 %LOCALAPPDATA%\DockerSandboxes\bin\ 下，PATH 可能不会立即更新。如果安装后找不到 sbx，请注销并重新登录，或打开一个新的终端窗口。
  • 如果你刚启用了 HypervisorPlatform，第一次运行 sbx create 之前务必重启系统。跳过重启通常会遇到挂起或难以理解的 hypervisor 错误，而不是一条明确的重启提示。
  • sbx 会把登录信息和守护进程存放在你的正常桌面会话中。在 Windows 上通过纯 SSH、没有交互式桌面的方式设置它，效果不好。

4. 你的第一个沙箱

4.1 登录你的代理

如果你使用 Claude Code 搭配 Claude 订阅（Max、Team 或 Enterprise），无需额外配置。第一次在沙箱内运行 /login 时，会通过浏览器完成登录。Docker 团队明确表示，登录令牌只保存在宿主机上，永远不会存入沙箱。

如果你更想用 API 密钥，用 sbx secret set 保存它，细节见第 8 节。

要让代理打开 Pull Request 或在 GitHub 上执行操作：

sbx secret set github -t "$(gh auth token)"

4.2 启动你的第一个沙箱

cd ~/my-project
sbx run --name my-sandbox claude

第一次运行任何沙箱时，sbx 会要求你选择默认网络策略：

Initialize the global network policy for your sandboxes:
1. Open         — All network traffic allowed, no restrictions.
❯  2. Balanced     — Default deny, with common dev sites allowed.
2. Locked Down  — All network traffic blocked unless you allow it.

刚上手时选 Balanced。它允许 npm 注册表、PyPI、GitHub 等常见开发者流量，同时默认阻止其它一切。以后随时可以改，所以不用太纠结。

你可以把 claude 换成任何其它受支持的代理。目前支持 Claude Code、Codex、GitHub Copilot CLI、Cursor、Droid、Gemini、Kiro、OpenCode、Docker 自己的 Docker Agent，以及不带任何代理的 Shell 模式。

第一次启动沙箱会稍慢，因为 Docker 需要下载代理基础镜像。之后会复用同一镜像，几秒钟就能启动。

4.3 查看沙箱可以访问什么

打开第二个终端：

$ sbx ls
SANDBOX       AGENT    STATUS    PORTS   WORKSPACE
my-sandbox    claude   running           ~/my-project

WORKSPACE 列显示沙箱和宿主机之间唯一共享的内容。代理在那里修改文件后，你会立即在工作目录看到变化，然后用普通的 git diff 审查，就像审查人类协作者的改动一样。

4.4 检查和调整网络访问

sbx policy ls
sbx policy allow network registry.npmjs.org

如果你选择 Locked Down，那么连模型自己的 API 也会被阻止，直到你显式放行。对包含敏感数据的仓库，这是好选择。

4.5 完成后清理

sbx stop my-sandbox     # pause it; everything stays saved
sbx rm my-sandbox        # delete it for good; packages and images go away too

沙箱在 stop 和再次启动之间会保持保存状态。已安装的软件包、拉取的 Docker 镜像、shell 历史都会在暂停后保留。但 rm 会删除沙箱内的一切，包括克隆模式下沙箱内的 git 克隆。宿主机上真实的项目文件夹不会被 rm 触碰。

5. 核心 sbx 命令速查

下面是每天最常用的命令：

$ sbx run claude                         # start or reconnect to an agent
$ sbx ls                                 # list your sandboxes and their status
$ sbx stop <name>                        # pause a sandbox
$ sbx rm <name>                          # delete a sandbox for good
$ sbx rm --force <name>                  # force-delete, even mid-session
$ sbx exec -it <name> bash               # open a shell inside a running sandbox
$ sbx cp ./file.json <name>:/home/user/  # copy a file from host to sandbox
$ sbx cp <name>:/home/user/out.log ./    # copy a file from sandbox to host
$ sbx ports <name> --publish 8080:3000   # forward a port for a running sandbox
$ sbx daemon restart                     # restart the background daemon
$ sbx                                     # open the interactive dashboard

每个 sbx 命令都会与后台守护进程 sandboxd 通信。如果沙箱在配置变更（例如代理设置）后行为异常，先试 sbx daemon restart，不要急着删除任何东西。

关于 sbx cp 的安全说明： 把文件从沙箱复制到宿主机，曾经是一个真实安全漏洞的目标，编号 CVE-2026-17106，绰号“CopyEscape”。详情见第 13 节。在你信任 sbx cp 从不受信任的沙箱拉取文件之前，确认你运行的是 sbx 版本 0.38.0 或更高。

如果 sbx 提示“默认网络策略尚未配置”，手动设置：

sbx policy set-default <allow-all|balanced|deny-all>

注意命令行里的词语和之前菜单里的不同：Open → allow-all，Balanced → balanced，Lockdown → deny-all。

命令中的 run（run）用于启动沙箱并附加到会话。

5.1 重新连接沙箱并命名

在同一个目录下再次运行 sbx run，会重新连接到同一个沙箱，而不是新建：

sbx run claude ~/my-project   # creates the sandbox
sbx run claude ~/my-project   # reconnects to it

如果指定名字，就可以从任意目录重新连接：

sbx run claude --name my-project
sbx run --name my-project        # reconnect later, from any folder

也可以在同一仓库上同时运行多个代理，只要每个代理有独立名字：

sbx run claude --name feature ~/my-project
sbx run claude --name spike   ~/my-project

5.2 创建沙箱但不立即打开

sbx create --name my-project claude .
sbx run --name my-project        # attach whenever you're ready

5.3 使用 git 的两种方式

这部分比看起来更重要。代理访问仓库有两种完全不同的方式。

  • 直接模式（默认）：代理对你的真实工作目录有全部读写权限。改动立即出现在宿主机上，就像协作者实时编辑文件。
  • 克隆模式（--clone）：代理在沙箱内的独立 git 克隆上工作。在你主动 fetch 或代理 push 之前，宿主机工作目录不会被改动。宿主机仓库在沙箱内可见，但只读。
sbx run --clone claude

当你同时在一个仓库上跑多个代理、不希望它们互相覆盖改动时，克隆模式很合适。如果你还不够信任某个代理，不想让它直接改工作目录，克隆模式也有用。

关于克隆模式要注意：

  • 只能在创建沙箱时启用，之后无法开启，只能删除重建。
  • 克隆的是创建沙箱时宿主机仓库当前检出的分支，不会自动创建新分支。
  • 只适用于真正的 git 仓库。非主 git 工作树也不行，因为只读挂载无法跟随工作树的 .git 指针文件。
  • 删除克隆模式沙箱时，沙箱内的克隆也会一并消失。先 fetch 或 push 任何重要内容。

5.4 共享多个文件夹

可以把宿主机上多个文件夹挂载进沙箱，适合共享库或不希望代理修改的参考文档：

sbx run claude ~/project-a ~/shared-libs:ro ~/docs:ro

第一个路径会成为主工作区，克隆模式用的就是它。后面列出的都只是额外挂载。加上 :ro 可以让文件夹只读。

5.5 从沙箱内发布端口

沙箱在网络上是双向隔离的。除非发布端口，否则宿主机工具无法访问沙箱内运行的开发服务器，这和普通 Docker 容器一样：

sbx run --publish 8080:3000 --name my-sandbox claude

如果沙箱已经运行：

sbx ports my-sandbox --publish 8080:3000

然后在浏览器打开 http://localhost:8080。

如果只发布沙箱侧端口，系统会分配一个空闲宿主机端口。可以之后查询：

sbx ports my-sandbox --publish 3000
sbx ports my-sandbox

6. 交互式仪表板

只输入 sbx 不带参数，会打开一个全屏终端仪表板。

每个沙箱显示为实时卡片，包含状态、CPU 和内存。你可以：

  • 创建沙箱：c
  • 启动或停止：s
  • 附加到沙箱：Enter
  • 打开 shell：x
  • 移除沙箱：r

还有一个网络面板，用 tab 打开，可以实时查看出站连接并即时修改允许/拒绝规则。按 ? 随时查看完整快捷键。

对新手来说，这是最友好的上手方式，不需要先记住所有命令。

7. 凭据与秘密

Docker Sandboxes 会尽量让原始秘密不进入沙箱本身，这样即使代理被攻破也无法偷走秘密。有两种方式授权代理访问秘密。

内置服务由宿主机上的代理处理，代理永远不需要直接读取秘密：

sbx secret set github -t "$(gh auth token)"

其它环境变量，例如 BRAVE_API_KEY 或内部公司令牌，没有内置服务。你需要把它们直接写进沙箱的持久环境文件。这意味着代理进程 可以 读取它们，和基于代理的秘密不同。只在没有代理方案可用时才这样用：

sbx exec -d <sandbox-name> bash -c "echo 'export BRAVE_API_KEY=your_key' >> /etc/sandbox-persistent.sh"

这个文件会在沙箱内每次启动 shell 时自动加载，因此值会保留到沙箱生命周期结束。注意 bash -c 这一段。默认情况下 sbx exec <name> <command> 运行命令时不经过 shell，所以 >> 重定向和环境文件必须按上面的方式包裹命令才能生效。

如果你在 无头 Linux 上，没有桌面钥匙串在运行，sbx 会自动回退到 ~/.config/com.docker.sandboxes 下的加密文件，并用严格的 0700 权限保护。这比真正的操作系统钥匙串弱，但可用。sbx 使用回退方案时总会明确提示你。

8. 为什么必须登录

普通的 docker run 命令不需要账户，但 sbx 不行。用 sbx login 登录是强制要求。Docker 的理由是：

  • 每个沙箱都有 可验证的身份。自主代理可以构建容器、安装软件包并代表你推送代码，你需要有清晰的责任记录。
  • 团队功能，例如组织级治理、共享环境和审计日志，都需要从底层就有“谁”的概念。
  • 沙箱需要向 Docker 的服务认证，才能拉取镜像并运行守护进程。

Docker 团队表示，账户邮箱只用于登录，绝不用于营销。CLI 只收集少量使用数据：运行了哪个命令、是否成功、耗时多久，以及登录后的用户名。它明确 不 收集你的提示词或代码。如果想完全关闭：

export SBX_NO_TELEMETRY=1

9. 哪些免费，哪些收费

这里经常让人困惑，简单说：

  • 免费，包括商业使用，不按座位收费： sbx CLI 本身，以及本文介绍的一切。
  • 付费，需要单独订阅（联系 Docker Sales）： 组织治理。包括集中管理的网络、文件系统和 MCP 策略、强制登录、审计日志交付。

也就是说，单个开发者可以 免费 使用完整的隔离和安全模型。只有当你需要在整家公司集中执行策略时才需要付费。

9.1 代理仍然要花钱

Docker Sandboxes 给你一个免费的环境运行代理，但代理本身是另一家公司的独立产品，通常不是免费的。

Claude Code 需要 Claude 订阅（Pro、Max、Team 或 Enterprise）或通过 Anthropic API 计费。GitHub Copilot CLI 需要 Copilot 订阅。Codex、Gemini、Cursor 等代理也各有各的定价。

不管你选哪个代理，花费都和直接在桌面/笔记本上运行差不多。沙箱不会增加费用，也不会减少费用。

10. 为什么代理会跳过批准提示（以及如何恢复）

这可能是新手最大的观念转变。

通常，用 Claude Code 的 --dangerously-skip-permissions 这类标志在裸机上运行代理是真正危险的。这正是该标志名称里带“dangerously”的原因。

但 Docker 的论点不同：一旦进入沙箱，沙箱本身就是安全边界。批准提示原本要处理的问题——停止破坏性命令、阻止网络访问、拦截未审查的文件改动——已经由虚拟机边界、网络策略和凭据隔离处理了。

如果某个会话想恢复批准提示，大多数代理支持会话中切换模式。Claude Code 中输入 /permissions。

如果希望谨慎模式成为每个会话的默认，可以构建自定义 工具包，从代理启动命令中移除跳过权限的标志：

# claude-safe/spec.yaml
schemaVersion: "1"
kind: sandbox
name: claude-safe
sandbox:
image: "docker/sandbox-templates:claude-code-docker"
entrypoint:
run: [claude]

sbx run claude-safe --kit ./claude-safe/

工具包和模板在 Docker 文档中仍标记为 早期访问，且格式已经变过一次。

截至 v0.38.0，新工具包默认使用 v2 模式。新版本把字段整理成清晰的块，例如 permissions.network.allow/deny 和 setup.install，取代旧的扁平风格 network.allowedDomains 和 commands.install。

旧版 v1 工具包仍可通过兼容路径加载，但加载器对混用两种格式很严格。v2 规范里出现遗留 v1 字段会直接失败，而不是悄悄运行。发布前运行 sbx kit validate ./your-kit，并查阅当前的 工具包参考 获取完整字段列表。工具包可以分发为本地目录、ZIP 文件、OCI 工件或 Git URL。

10.1 其它值得了解的实验性功能

截至 v0.38.0，这三个功能位于功能标志后面，应该当作真正的实验功能：

  • GPU 直通（仅 Linux）： sbx run --gpu 让沙箱使用 NVIDIA VFIO GPU 直通。先用 sbx settings set feature.sandbox-gpu true 启用。
  • 本地模型： sbx run --model <name> claude 让 Claude Code 针对本地 GGUF 模型运行，而不是托管 API。如果要拉取现有 Ollama 安装中的模型，加上 ollama/ 前缀。
  • 企业网络： 可以为沙箱流量和守护进程流量设置独立代理，并支持 Windows 上的 NTLM/Kerberos 代理登录。如果公司网络位于一个检查并认证流量的代理后面，这项功能很重要。

11. 想用本地模型降低成本？

转成本地模型能省掉订阅和 API 费用，但整体上并不自动“免费”。你仍然需要一块足够显存的 GPU，才能以可用速度运行有能力的模型。如果还没有 GPU，购买成本可能超过多年托管订阅。

本地开放权重模型在多步骤自主编码任务上通常仍然落后于 Claude 这类托管模型，不过差距在缩小。

注意 sbx run --model 仍然运行在 Claude Code 自己的框架内，只是换掉了背后驱动它的模型。它适合本地测试，或让代码不经过外部 API。

12. MCP 网关（v0.38.0 新增）

从 v0.38.0 开始，sbx 增加了对模型上下文协议（MCP）服务器的原生支持。

这与直接在代理内部配置 MCP 服务器（例如 Claude Code 自己的 MCP 配置）不同。它解决的问题是：你在宿主机上注册一次服务器，就可以在每个沙箱、每个代理中复用，而且不需要把凭据放进沙箱。

sbx mcp add notion --url https://mcp.notion.com/mcp
sbx mcp add playwright --command npx --args @playwright/mcp@latest
sbx mcp ls
sbx mcp inspect notion

如果远程服务器需要 OAuth，sbx mcp add 会在注册时运行一次登录流程，然后把令牌存入宿主机的凭据存储。之后网关会把令牌附加到沙箱的出站请求中，但令牌本身永远不会进入虚拟机。

创建沙箱时，有两种模式连接已注册的服务器：

  • 静态模式（--static-mcp server1,server2）：预加载固定列表，并向代理隐藏发现类工具。这是更严格、更安全的选择。
  • 动态模式（默认）：允许代理在会话中自行搜索并连接已注册的服务器，使用内置的 mcp-find 和 mcp-add 工具。

重要说明：

宿主机上基于本地 stdio 的 MCP 服务器运行在沙箱保护之外，使用宿主机当前用户的权限。Docker 团队警告，只应以这种方式注册受信任的命令和镜像。远程 HTTP 服务器没有这个问题，因为网关会代为代理。

13. 已知安全问题，以及为什么应该保持更新

在让沙箱处理任何敏感内容之前，请 仔细 阅读这一节。

Docker Sandboxes 仍然是年轻软件。它天生要处理不受信任的代码，因此已经出现过几个真实、公开披露的安全漏洞。其中两个是网络隔离缺口，最严重的一个是通过文件复制功能真正逃逸到宿主机文件系统。

要点是：网络允许列表本身并不能构成完美边界。它的有效性完全取决于当前版本，每个版本都必须逐一封堵 DNS、ICMP 等可能的侧信道。

宿主机与沙箱之间的文件复制路径（-c）也一直是攻击目标，不只是网络层。所以，如果你用沙箱处理敏感凭据或数据，请把版本号当作一个持续的安全问题，而不是一次性安装细节（-t）：

sbx version

对照 发布说明 或 sbx-releases 页面检查版本，如果落后了，用第 3 节的命令升级。

截至撰写本文，版本 0.38.0 或更高 已包含上述三个漏洞的修复。因为漏洞 CVE-2026-17106 很新，在确认版本不低于 0.38.0 之前，对 sbx cp 的复制方向要格外小心。可以时，优先在共享读写工作区里用 git diff 审查改动（见 5.3 节），而不是从你不完全信任的沙箱中随意复制文件。

这并不代表整体设计不值得信任。对文件和进程的虚拟机级隔离确实是可靠的方法，而且 Docker 修复漏洞的速度很快。

2026 年 6 月的两个漏洞在报告后约两周内修复；CopyEscape 的修复与披露发布在同一版本中。

始终记住：不要安装一次就置之不理。定期检查版本，尤其是在用 sbx cp 从不完全信任的沙箱拉文件之前，或者在你把网络允许列表当成完美防火墙之前。

14. 一些实用技巧

  • sbx run 在重新连接时会忽略 --publish。 如果你重新附加到已存在的沙箱并需要新的端口转发，改用 sbx ports <name> --publish ...。--publish 标志只在首次创建沙箱时生效。
  • 沙箱不会从你的账户复制完整的代理设置。 ~/.claude 这类目录里的 hooks 和配置留在宿主机，只有工作目录内的项目级配置会共享。唯一例外是 共享代理技能，需要你自己用 sbx skills import 开启。另外，不要依赖指向宿主机路径的符号链接；沙箱代理无法跟随这些链接离开自己的虚拟机。
  • 剪贴板图像粘贴默认关闭，因为开启后沙箱进程可以通过代理读取宿主机剪贴板。如果需要，自己开启：sbx settings set clipboard.imagePaste true
  • 不确定自己是否在沙箱里？ 直接问代理。Claude Code 里可以试 /btw are you running in a sandbox?。在粘贴任何敏感内容之前，这是一个快速的理智检查。
  • 如果公司防火墙阻止出站流量，你需要放行 Docker 自己的基础设施域名，sbx 本身才能工作：login.docker.com、hub.docker.com、api.docker.com、registry-1.docker.io、auth.docker.io，另外还有几个遥测和诊断端点。这与沙箱内部网络策略允许的内容是两回事。

资源和进一步阅读：

  • Docker Sandboxes 入门
  • 沙箱使用指南
  • 工作流
  • 安全模型 → 隔离层
  • 治理
  • 为什么是微型虚拟机（Docker 工程博客）
  • MCP 网关文档
  • GitHub 上的 sbx-releases
  • sbx 的 GitHub 安全公告