沙箱引擎只改变网络隔离路径#

容器使用独立网络命名空间，但出站过滤最终由宿主网络策略执行。gVisor 可以把协议栈移到用户态并缩小宿主内核攻击面，microVM 使用独立 Guest Kernel 和虚拟网卡；两者仍需要宿主侧策略决定目的地址是否允许。

隔离引擎回答“网络栈与宿主之间隔多远”，出口策略回答“这个连接能去哪里”。前者更强不能推出后者自动具备域名语义。

域名与连接必须保持同一判断链#

若平台先解析域名、把 IP 写入白名单，再允许应用重新解析并连接，攻击者可以通过 DNS Rebinding 让两次解析得到不同结果。

更可靠的方式是：

• 通过显式 HTTP/CONNECT 代理取得目标主机；
• 由域名感知策略同时完成解析和连接；
• 阻止绕过代理的直接出口；
• 对解析结果设置生命周期并处理多 IP、CDN 与变更。

只嗅探 TLS SNI 也存在局限：它发生在 TCP 建连之后，且加密握手扩展可能隐藏主机名。代理在连接建立前获得目标域名，控制点更稳定。

身份与域名策略应独立于引擎#

出口规则通常还需要租户、任务与工具身份。相同域名对只读抓取任务可能允许，对处理私密数据的任务则可能禁止。

因此策略合同应表达：

1
谁（租户 / Session / Tool）
2
→ 在什么任务中
3
→ 访问哪个域名与端口
4
→ 使用何种协议
5
→ 记录什么审计信息

这些信息不应埋在某个 Sandbox SDK 中，否则更换容器、gVisor 或 microVM 时策略语义会漂移。

我的选择：统一代理，沙箱只负责强制接入#

我会让不同引擎都通过同一出口代理或域名感知网关，沙箱网络只负责禁止旁路，并限制元数据、内网和控制面地址。

代价是增加代理可用性、TLS 兼容和策略维护成本。若任务完全离线，直接禁网更可靠；若只需固定 IP 服务，三四层策略足够。只有业务要求按域名动态访问时，才引入七层控制，不能用一次 DNS 解析代替。