2026 年用 Docker Sandboxes 隔離運行 OpenClaw：與裸機 / 常規 docker run 對照的基線、資源邊界與排障 FAQ（Mac 雲 7×24）
社區與官方材料都在推「在 Sandboxes 裡跑 OpenClaw」：更強隔離、可控出口、密鑰不必直接進容器文件系統。但你可能已經讀過站內「Docker Exit 137 / 卷權限」文——Sandboxes 並不會 magically 消滅 OOM 與 DNS，只是換了安全與排障的優先級。本文給適用邊界、三張形態對照表、可復現的落地步驟（≥5 步）、Mac 雲側日誌與 18789 防火牆銜接，以及「先 Sandboxes 還是先 openclaw doctor」的分流 FAQ。
本文要點
1. 適用邊界：不要為了「聽起來更安全」默認上 Sandboxes
若你只是個人試用、改兩行配置、或強依賴宿主 GUI/本地工具鏈，裸機 npm 或官方一鍵腳本往往迭代更快。若你已有一套跑穩的 docker compose，且威脅模型主要是「別誤刪宿主目錄」，常規容器 + 只讀根文件系統 + 資源上限可能已經足夠。
- 更傾向 Sandboxes 的信號：多用戶共享一臺 Mac 雲、要給技能/插件加默認不可信假設、需要出口白名單或代理統一注入密鑰、合規要求把「代理能訪問的網域」寫進審計材料。
- 仍優先裸機/Compose 的信號：頻繁改源碼調試、需要掛載整塊 workspace 做大量本地 IO、或團隊尚未把 Docker 版本與 Sandboxes 相關 CLI 行為釘死在鏡像裡。
- Mac 雲特有點：無桌面、套餐內存封頂、磁碟與 Docker 數據根在同一卷——Sandboxes 的額外抽象會放大 IO 與內存預算壓力，基線要一起算。
2. 對照表：裸機 / 常規容器 / Sandboxes
下表用於架構評審幻燈片，可直接複製；具體 flag 以你安裝的 Docker 與 OpenClaw 發行說明為準。
| 維度 | 裸機 / npm | 常規 docker run / Compose | Docker Sandboxes 思路 |
|---|---|---|---|
| 隔離強度 | 依賴用戶與權限模型 | 命名空間/cgroup，需正確配 cap、只讀層 | 更強默認邊界，出口與密鑰注入可中心化 |
| 可觀測性 | 直接看進程與日誌路徑 | docker logs、inspect、健康檢查 | 多一層代理/側車，需統一關聯 request id |
| 升級路徑 | 包管理器/腳本 | 拉鏡像、compose 版本釘死 | 同步釘 Sandbox 運行時與 OpenClaw 鏡像 |
| 性能開銷 | 最低 | 中 | 中高（視實現與策略） |
| 典型代價 | 宿主被誤操作風險 | 卷 uid、DNS、OOM（見站內專文） | 策略配錯導致「全站不可達」類故障 |
~/.openclaw 掛載檢查，再調 Sandbox 策略。
3. 落地步驟（≥5 步）：從釘版本到健康檢查
下列順序強調「可審計」，省略具體鏡像名以免與你的 fork 不一致；請替換為當前官方文檔推薦標籤。
- 釘死三角：Docker Engine/CLI 版本、OpenClaw 鏡像 digest、Sandbox 策略版本（若有）寫入 Runbook，CI 或 Ansible 只部署該三元組。
- 分離卷職責：配置目錄、workspace、日誌目錄分卷或分子路徑；避免把宿主整個 home 掛進沙箱。權限仍建議對齊容器內運行用戶（常見 uid 1000）。
- 聲明資源上限：為網關進程設內存與 CPU 上限，並預留約 20% 餘量給短時模型突發；Mac 雲若同機還跑構建，顯式錯峰。
- 網絡與出口：列出 OpenClaw 必需的域名（模型 API、通道 Webhook、包索引等），其餘默認拒絕或走企業代理；密鑰經代理或運行時注入，避免寫進只讀層鏡像。
- 健康檢查與啟動順序：
18789（或你映射的埠）在宿主與容器內分別探測；start_period覆蓋冷啟動拉模型或編譯緩存的時間。 - 驗收快照：保存一次「成功啟動」的
openclaw status輸出、關鍵環境變量哈希（不含密鑰）與 Sandboxes 策略文件版本號，便於回滾對比。
示意（偽代碼級，勿照抄為生產唯一真值）：
4. Mac 雲 7×24：日誌、重啟策略與防火牆
雲上默認沒有人在屏幕前點「允許」，因此要把自動重啟與日誌輪轉寫進 launchd 或 systemd 外層編排：內層容器策略變更失敗時，避免無限重啟風暴——用指數退避或熔斷告警。
安全組/防火牆需同時放行：SSH 管理面、網關映射埠、以及企業代理出口。若你只放行 22 與 18789 卻忘了模型 API 的 HTTPS 出口，症狀與 DNS 問題極像，優先用「容器內 curl -v 對照宿主機」分層。
5. 可引用基線（經驗值，需按套餐調整）
- 內存：僅網關+輕量通道時，許多團隊以 4GB 容器上限為起點；並發技能或本地模型同機時上調到 8GB+ 並單獨監控。
- 磁碟：鏡像層、Sandbox 臨時空間與日誌建議獨立於系統卷；低於約 10GB 可用時拒絕自動升級任務。
- CPU：為避免與
xcodebuild同機爭用，網關容器 2 vCPU 起，並用 cgroup 保證最低份額。 - 埠：對公網暴露網關時務必疊加鑑權與配對策略；僅內網則優先 SSH 隧道收斂暴露面（與站內生產加固文一致）。
6. FAQ：啟動失敗時先查 Sandboxes 還是先 doctor？
問：容器秒退，日誌只有一行權限錯誤？ 先卷與 uid，再看 Sandboxes 是否禁止了寫路徑——順序與 Exit 137 專文一致。
問：進程在但通道全掛？ 先 DNS/出口白名單，再 openclaw doctor 看網關與通道配置分層。
問：升級 OpenClaw 後 Sandbox 策略失效？ 比對發行說明中網絡與文件路徑變更；保留上一份策略 Git 標籤可快速 diff。
完全在筆記本上跑 Sandboxes 易受睡眠與本地策略影響；純 Windows/WSL 混搭又常帶來路徑與權限長尾。Docker 抽象層雖能統一交付，但會增加排障維度與性能折損——當你要把 OpenClaw 當7×24 業務網關而不是玩具時，在專用 Apple 硬體上的 Mac 雲節點通常比臨時拼湊環境更省心：SSH 習慣與 Linux 運維對齊，同時保留官方工具鏈與穩定內核組合。若你已在常規 Docker 上踩過 OOM 與卷權限坑，可繼續閱讀站內 OpenClaw Docker 典型故障修復文，把 cgroup、DNS 與 doctor 階梯和本文 Sandbox 策略接成一條完整鏈路。