共享内存 · 内存峰值 · 能力白名单 · 症状树与六步 Runbook
OpenClaw 在 Docker 里跑通 Gateway 之后，一旦挂上需要打开网页、截图、自动化填表或运行无头 Chromium 的 Skill，负载形态会从「长驻 Node 进程」跃迁到「浏览器渲染栈 + 临时文件 + 峰值内存」。本文写给在 VPS 上自建、却被间歇性白屏、随机崩溃或 OOM 卡住的同学：先用症状对照表把 shm_size、mem_limit 与能力集对齐到可观测信号，再按六步 Runbook把变更写进可回滚的 Compose profile。读完你会拿到一张可打印的评审页，并能与 Exit 137 起步排障、Compose 生产基线分工阅读。
很多团队第一次把 OpenClaw 搬上 VPS 时，验证路径停留在「通道能回消息、doctor 全绿」。这只能证明控制面与模型链路大致健康，并不能证明浏览器类 Skill在容器 cgroup 与默认虚拟文件系统约束下同样健康。无头浏览器会在短时间内制造大量匿名映射与 GPU/合成缓冲占用；当这些占用撞上 Docker 默认的 64MB /dev/shm 或偏低的内存上限时，表现往往不是立刻 Exit 137，而是页面空白、标签页崩溃、截图超时、偶发僵死，从而被误判为「模型慢」或「网站反爬」。
把「能打开首页」当成压测通过：单页加载与多步登录、滚动截长图、并发多标签是不同阶的内存与 shm 压力；未压测就上线会在业务高峰突然爆。
忽略 /dev/shm 与宿主机内存的耦合：容器内 Chromium 会优先把大块缓冲放在共享内存；docker stats 里 RSS 看似不高，但 dmesg 已出现 oom-kill 或 cgroup 限流。
能力集复制粘贴：为绕过沙箱直接加 SYS_ADMIN 等宽能力，短期能跑通，长期把「浏览器漏洞」放大成「宿主机面」；评审材料里又写不出取舍理由。
与反代、allowedOrigins 混为一谈：控制面板报 non-loopback、WebSocket 断开与浏览器进程崩溃是不同故障树；先读 网络排障文 再回来看本节，避免三角排障。
单实例堆满「重页面 + 重 Skill」：同一 OpenClaw 栈里既跑高频通道又跑重浏览器任务，缺少分实例或错峰策略，会在夜间批处理时把白天稳定的配置打穿。
把上述五条写成变更单上的「禁止项」与「必须压测项」，比事后在群里问「谁改了我的 compose」要便宜一个数量级。下一节用矩阵把参数与症状钉在一起，值班同事不用读完全部文档也能先止血。
下面这张表刻意用「你肉眼看到的症状」做行索引，而不是用参数名做索引——因为线上事故往往从现象进入。请把表头打印在运维笔记本扉页；每次调参只允许改一格并记录前后 docker stats 与 Gateway 日志片段，避免同时动三处导致无法二分。
| 你看到的症状 | 优先核对 | 常见根因与动作 |
|---|---|---|
| 间歇白屏、Aw Snap、标签页崩溃 | shm_size、/dev/shm 使用率 | 默认 64MB 过小；先试 512m→1g，并限制并发页面数 |
| 进程直接消失、Exit 137 | mem_limit、宿主机 swap、oom_kill 计数 | 浏览器峰值 + Node 常驻叠加超过 cgroup；按峰值上调或拆分实例，见 Exit 137 文 |
| 启动即报权限/设备相关错误 | cap_add、devices、seccomp 配置 | 对比官方 compose 片段；缺什么补什么，而不是一次性全开特权 |
| CPU 打满但页面不前进 | 是否启用软件渲染、是否无限重试导航 | 限制重试与超时；检查 Skill 是否在死循环刷新 |
| 仅特定站点失败 | TLS 指纹、HTTP/2、地区出口 | 与浏览器资源无关时，转到网络与出口拨测，不在本节堆参数 |
浏览器类 Skill 的稳定性，本质是峰值内存 + 共享内存 + 能力白名单三件事是否写进了可审计配置；其它「玄学优化」都要让位。
社区与官方 Docker 文档在 2026 年仍普遍建议为带浏览器自动化的栈配置更大的 shm_size（常见基线为 512MB 至 1GB 量级）并配合明确的内存上限，而不是依赖默认 compose 模板。你不需要背具体数字，但需要把「默认不够」写进团队共识，并在容量规划里为夜间批处理窗口单独留 headroom。
下列顺序与 Compose 生产基线 对齐：先做观测，再改配置，再压测，再归档。任何一步输出请粘贴到工单，避免「口头同步」。
冻结镜像标签：在变更浏览器参数前，先 docker compose pull 的行为写入备注；生产环境应钉扎 GHCR 具体 digest 或版本号，而不是漂移在 :latest。
采集 baseline：对同一 Skill 连续跑三次，记录 docker stats 峰值、容器内 df -h /dev/shm、以及 Gateway 相关日志窗口。
只改 shm：把 shm_size 提到 512m 或 1g，保持其它变量不变，重跑三次同一 Skill。
再调 mem_limit：若仍有 137 或 oom_kill，按 25% 步进上调 mem_limit，并核对宿主机是否禁止 swap 导致过早杀进程。
能力集最小化：若官方片段要求特定 cap_add 或设备映射，逐项核对「缺它会报什么错」；能不加 SYS_ADMIN 就不加。
归档与回滚点：把通过的 compose 片段与镜像 digest 提交到仓库；回滚命令写为 compose down && compose up -d 的可复制块。
services:
openclaw:
image: ghcr.io/openclaw/openclaw:<pin-a-digest-not-latest>
shm_size: "1g"
mem_limit: "4g"
# 仍建议控制面监听 127.0.0.1，由反代对外提供 TLS
# 与 json-file 轮转、healthcheck 对齐见生产基线文
提示：若同一宿主机要并行第二套浏览器更重的栈，请先阅读 多实例隔离 的端口与卷命名，再复制本 Runbook，避免两套 compose 抢同一数据目录。
这一节只收录能在配置或监控里点名的事实，避免「感觉浏览器不稳定」这类不可审计表述。数字是经验量级，请用你自己的压测覆盖团队真实 Skill。
shm_size 视为与 mem_limit 同等重要的字段；从 512MB 起步、在截图/长页面场景验证后再考虑 1GB 档，是 2026 年社区文档里最常见的可落地区间。healthcheck 的 start_period 过短，会把「仍在编译/预热」误判为不健康并不断重启，症状像随机抽风。具体字段与 json-file 轮转请回到 Compose 生产基线 对齐。注意：不要在同一变更单里同时调整反代证书、模型密钥与浏览器资源三件套；三角变更会让回滚无法二分。TLS 与反代路径请见 反代 TLS 文。
当你已经能把参数调到「白天稳定」，下一步要问的是组织与容量：是否允许同一 OpenClaw 实例在夜间跑重浏览器批处理。把这个问题留到事故后讨论，成本远高于提前用表决策。
| 模式 | 适用 | 主要风险 |
|---|---|---|
| 单实例混合 | 个人玩具到小型试点；Skill 轻量、无长截图链路 | 峰值叠加不可见；一次 OOM 同时影响通道与工具链 |
| 浏览器独立 profile | 同一机器两套 compose，分卷分端口 | 需要严格执行隔离清单；见多实例文 |
| 专用 24/7 节点 | 团队生产；需要可预期 SLA 与独占资源 | 成本上移，但换来可签字容量与审计材料 |
在「自建 VPS + 手工调参」路径上，短期确实灵活；但当 OpenClaw 要进入多人共用、夜间批处理、以及需要向业务方证明容量与回滚的阶段，临时组合往往缺三样东西：独占资源、标准化镜像与工单化变更。此时把重浏览器与通道控制面拆到可预期规格的 24/7 节点，并把 Compose 片段与压测记录当作交付物，通常比继续在单台小内存机器上堆参数更划算。对要把 iOS 构建、桌面接力与 Agent 常驻放在独占、地区与网络档位可预期环境的小团队，VpsMesh 的 Mac Mini 云端租赁通常是更优解：便于为浏览器峰值预留内存与磁盘、并与既有 Mac Mesh 协作 叙述对齐；价格见 价格页，自助路径见 帮助中心。
Chromium 系渲染与缓冲会大量使用共享内存；过小会出现间歇性白屏或标签页崩溃，而 CPU 指标仍看似正常。请先把 shm_size 提到 512m 或 1g 再谈其它优化，并与 Exit 137 起步排障 中的内存条目交叉核对。
并非所有场景都需要；优先按官方 compose 片段用最小权限验证。若确需特权，请把业务理由与威胁模型写进变更单。更多通道侧加固见 生产加固清单。
共用 Gateway 时，浏览器峰值会放大「谁改了 mem_limit」的冲突；请把本表的 shm 与内存行写进团队端口与资源表，并与 多 API Key 分舱文 的 Runbook 合并评审。