Docker Sandboxes 的网络策略：balanced 挡住了什么，怎么放行一条例外
Docker Sandboxes 实测系列（共 5 篇）
- Docker Sandboxes 上手：从安装到第一次跑 Agent
- Docker Sandboxes 工作区怎么接：Direct、Clone 和它们的边界
- Docker Sandboxes 的隔离例外：共享 Skills 与宿主机 MCP
- Docker Sandboxes 的凭证：host 代理转发，不进 microVM
- Docker Sandboxes 的网络策略：balanced 挡住了什么，怎么放行一条例外（本篇）
TL;DR
balanced 不是“基本全开”。初始化后本机生成了 197 条网络 allow 规则，看着不少，但拦下的东西更值得关注：宿主机 localhost、局域网私有地址、云平台的 metadata 端点（169.254.169.254）、VS Code 和 Microsoft 的遥测域名，默认全部 403 或 DNS 直接拒绝。
排查用 sbx policy log，看某个 sandbox 到底被拦了哪个域名、什么原因；放行用 sbx policy allow network --sandbox <name> <host>，改动立刻生效，不用重启 sandbox。
三档预设，balanced 挡的比想象中多
第一篇提过一句：三档预设里，balanced 是居中那档——默认拒绝，放行常见开发站点。这篇把“常见开发站点”具体是什么、“默认拒绝”具体拒绝了什么，摊开看。
先看规模：
$ sbx policy ls
POLICY SOURCE APPLIES TO SUMMARY
local-policy local all network: 197 allow; filesystem read: 1 allow; filesystem write: 1 allow
197 条 allow 规则，覆盖模型 API、包管理器（PyPI、npm）、代码托管（GitHub）、容器 Registry 这些开发常用域名。但下面这些默认都不在名单里：
$ sbx exec my-sandbox bash -c 'curl -s -o /dev/null -w "%{http_code}\n" http://example.com'
403
$ sbx exec my-sandbox bash -c 'curl -s -o /dev/null -w "%{http_code}\n" http://localhost:1'
000
$ sbx exec my-sandbox bash -c 'curl -s -o /dev/null -w "%{http_code}\n" https://pypi.org'
200
example.com 403，宿主机 localhost 直接连不上（000），pypi.org 在白名单里，200。
值得留意的不是这几个示例域名，是我这几天测试攒下来的 sbx policy log 里，balanced 真正拦住的东西——云平台的 metadata 端点和几个大厂的遥测域名，默认也在拒绝名单里：
Blocked requests:
SANDBOX HOST REASON
... 169.254.169.254:80 No matching allow rule (default deny)
... metadata.google.internal:80 No matching allow rule (default deny)
... westus-0.in.applicationinsights.azure.com:443 No matching allow rule (default deny)
... main.vscode-cdn.net:443 No matching allow rule (default deny)
... mobile.events.data.microsoft.com:443 No matching allow rule (default deny)
169.254.169.254 是云平台通用的 metadata 服务地址（AWS/Azure/GCP 都用这个地址回答“我是谁、我的凭证是什么”）；一个跑在容器里的进程如果尝试连它，通常不是好事。balanced 默认把这条也堵了，不只是挡“陌生网站”。
用 sbx policy log 查一条请求被拦在哪
sbx policy log 按 sandbox 分组，列出被拦和放行的请求，带上代理类型和命中次数：
$ sbx policy log
Blocked requests:
SANDBOX TYPE HOST PROXY RULE REASON COUNT
my-sandbox network example.com:80 forward no applicable policies for op(...) No matching allow rule 1
my-sandbox network example.com network <dns proxy policy> DNS lookup blocked 1
同一个域名会出现两条：一条是 HTTP 层的连接被 403，一条是 DNS 解析本身就被挡——balanced 不只在 HTTP 代理层拦，DNS 查询这一步也可能先被切断，取决于 sandbox 是不是先解析出了地址再发起连接。
想在不实际发请求的情况下判断某个域名会不会被放行，用 sbx policy check，不用起 sandbox 或等 curl 超时：
$ sbx policy check network blocked.example.com
Denied: blocked.example.com:443
Reason: no matching allow rule (default deny)
$ sbx policy check network api.anthropic.com
Allowed: api.anthropic.com:443
放行一条例外，只影响一个 sandbox
第一篇讲 SuperGrok 时用过全局放行：sbx policy allow network "*.x.ai:443,…"，之后所有 sandbox 都能连。如果只想给某一个 sandbox 开例外，加 --sandbox：
$ sbx policy allow network --sandbox my-sandbox example.com
Rule added to policy local (scope: sandbox:my-sandbox): 64cae706-... (example.com)
$ sbx exec my-sandbox bash -c 'curl -s -o /dev/null -w "%{http_code}\n" http://example.com'
200
加规则不需要重启 sandbox，立刻生效。撤销同一条规则：
sbx policy rm network --sandbox my-sandbox --resource example.com
sbx policy ls <sandbox-name> 能看到这个 sandbox 当前实际生效的规则合集——包括全局 local-policy，也包括 kit 额外加的规则。我这台机器上跑过的几个 OpenCode sandbox，sbx policy ls 显示它们各自还多了一条来自 kit 的 allow 规则，是 OpenCode 的 sandbox 模板自己声明的，不算在全局 197 条里。这条提醒：换一个 Agent 或换一个 kit，实际放行的域名集合可能比全局策略更宽，出问题时记得连 kit 规则一起查。
小结
balanced 不是一个粗粒度的开关，是一份具体的域名白名单——覆盖了主流开发工具链，但云 metadata、遥测、局域网、宿主机自己，默认全部拒绝。出问题先查 sbx policy log 定位是 DNS 层还是连接层被拦，再用 sbx policy check 确认改动前后的判断，最后按需 --sandbox 精确放行，不必为一个域名把全局策略打开一个口子。
