我是在一台跑了好几年的 Ubuntu 服务器上把 OpenClaw 从裸进程迁到 Docker 容器之后才真正体会到什么叫“睡得着觉”。之前很长一段时间OpenClaw 的模型 API 密钥就躺在项目目录下的.env文件里宿主机上任何有 shell 权限的人、任何一个被拖到日志里的报错、甚至一个不小心写进 Git 仓库的 commit都能让密钥“裸奔”到外面。这篇不是 OpenClaw 入门教程而是分享我如何用 Docker 给 OpenClaw 搭一个真正意义上的沙盒让 API 密钥不再裸奔。如果你也跑着这个 agent或者手里握着好几个渠道的密钥这篇文章应该够你直接照着抄作业。1. 先搞清楚一件事你的密钥到底暴露在哪1.1 本地部署的密钥通常放在哪OpenClaw 这类 agent 框架部署的时候要接的东西比想象中多。除了最核心的模型 API KeyClaude、千问这类模型服务如果你接了飞书、Teams、Telegram 或者其他渠道每个渠道都有自己的 Bot Token、App Secret、Webhook 校验参数。再加上 Obsidian 插件、浏览器自动化工具零零总总十几个敏感凭证一点也不夸张。这些凭证默认放哪里最常见的就是项目根目录下的.env文件或者openclaw.json这类配置文件里。我见过不少人的.env就是直接复制官方示例改的里面清清楚楚写着ANTHROPIC_API_KEY对应的明文 Key。问题在于这个.env文件和代码是放在同一个目录里的如果哪天不小心把它 commit 进 Git 仓库或者用scp同步到别的机器上那这个 Key 就等于公开了。1.2 三种典型的“裸奔”姿势我把这几年的踩坑总结成三种姿势你可以对照检查一下自己中了几条。第一种是“密码散步”型。.env文件虽然名字带着env但它本质上就是个纯文本文件里面的内容是明文。项目里为了调试方便经常会写各种小的 Python 脚本或者 shell 脚本去临时加载这个文件脚本一多谁也记不清哪些地方引用了。最夸张的一次我在服务器上用grep -r sk-ant /home/搜了一下发现密钥出现在三个不同的调试文件里其中还有一个是 Jupyter Notebook。第二种是“日志裸奔”型。OpenClaw 在跑的时候日志量不算小尤其接上飞书、Teams 之后每条消息、每个工具调用都会记录下来。一旦某个功能报错框架会把当时的环境变量、请求参数打出来排错。如果你调用了外部模型 API 时把Authorization头打进日志密钥跟着请求日志一起被写进文件这时候就算文件权限设置得再严它也已经在磁盘上“裸奔”了。第三种是“邻居可见”型。很多人的服务器上不止跑一个服务有网页、有数据库、有监控脚本。如果 OpenClaw 是以普通用户身份跑在宿主机上那么同机器上的其他服务、其他用户只要拿到一点权限就能直接读你的/home/user/.openclaw/目录。容器在这里能挡住一部分但挡不住根源——密钥必须以某种形式存在关键在于限制它的可见范围和读取权限。1.3 沙盒到底挡了什么Docker 的沙盒说到底是一套隔离机制。它用 Linux 命名空间把进程、文件系统、网络隔离开再配合 cgroups 做资源限制让容器里的进程以为自己在一台独立的机器上。放在 OpenClaw 这个场景里最直接的收益是宿主机上的其他进程默认看不到容器内部的文件.env里的密钥不会因为隔壁服务被攻破而顺势泄露。但这里必须说清楚沙盒不是银弹。密钥最终还是要在某个地方落盘或者注入容器只是改变了它的存储位置和可见边界。你依然需要管好宿主机上的.env文件权限、轮换机制、日志脱敏这些事情。把 Docker 当“保险柜”没问题但保险柜的钥匙不能挂在柜门上。2. 为什么我选 Docker 而不是裸进程或者虚拟机2.1 容器隔离不是玄学是组合拳很多人听到“隔离”就想到虚拟机觉得得给 OpenClaw 单独开一台机器。其实没必要。容器用的隔离是操作系统层面的进程看到的文件系统是隔离的进程列表是隔离的网络栈是隔离的。OpenClaw 跑在容器里它访问到的/app、/home/openclaw都是容器自己的视图宿主机上其他路径它是看不到的。我用一个类比解释虚拟机是给每个租客一套独立的房子有完整的水电煤气和墙体安全但开销大容器是给每个人一个独立的集装箱箱子内部你随便布置但港口、吊车这些基础设施是共享的。对于 OpenClaw 这种单体 Python 应用容器的隔离级别完全够用而且启动速度、内存开销都比虚拟机低一个数量级。这套组合拳具体由几部分构成文件系统隔离容器镜像打包了 OpenClaw 和它的全部依赖宿主机上不需要装 Python、Node 这些东西。进程隔离容器里的 PID 命名空间独立你在容器里kill进程不会影响宿主机。网络隔离容器有自己独立的网络栈可以决定哪些端口暴露给宿主机、哪些只在容器内部通信。资源限制通过cpus、memory参数限制 OpenClaw 能占用的资源防止它某个功能失控时把机器拖垮。2.2 一鱼多吃跨平台、可复现、好升级选 Docker 还有一个很现实的理由OpenClaw 的官方镜像已经有人维护拉下来就能跑不用自己在宿主机上折腾 Python 虚拟环境、依赖冲突、系统服务配置。之前我在另一台 Debian 上用 systemd 托管 OpenClaw 进程升级版本要先停服务、拉代码、装依赖、改配置哪一步出错都可能让 agent 失联。换成 Docker 之后升级就是拉一个新的镜像、重新docker compose up -d的事。跨平台也很重要。我在 Windows 笔记本上调试、在 Linux 服务器上长期运行两边的行为不能有太大差异。Docker 把运行环境标准化了只要 Docker 能装OpenClaw 的环境就是一致的。这种可复现性对于 agent 项目来说比什么都珍贵——它让“在我机器上好好的”这句话不再成立。2.3 数据流和目录规划装之前先把数据流捋清楚。OpenClaw 在运行时需要读写以下几类数据配置数据模型参数、渠道信息、密钥通过环境变量注入不落盘。会话数据某个 session 的历史对话、上下文状态。日志数据运行日志、渠道消息记录。插件数据如果是 Obsidian 等插件可能还要读本地 Markdown 文件。我的规划是这样把容器内的/app/openclaw目录挂载到宿主机上的一个数据目录日志单独挂载这样即使容器删了重建会话记录和日志都还在。密钥走环境变量注入不放到挂载目录里。这样布局的优点是数据目录的权限可以单独收紧宿主机上的备份流程也只针对这个目录不会把密钥一起备份走。3. 从零到一把 OpenClaw 关进容器3.1 前置准备Docker 环境安装这一步本身不复杂但踩坑的人相当多尤其 Windows。Linux 和 macOS 通常直接装 Docker Engine / OrbStack 就行Windows 的话一般装 Docker Desktop它依赖 WSL2 后端。Windows 用户装 Docker Desktop 最常见的问题是启动报错virtualization support not detected。这个通常是因为 BIOS 里的虚拟化没开或者 WSL2 核心组件没装好。解决思路是三步走先检查系统信息里虚拟化是否启用再到“启用或关闭 Windows 功能”里打开“适用于 Linux 的 Windows 子系统”和“虚拟机平台”最后安装 WSL2 更新包。装完重启基本能解决。Linux 用户相对省心但要注意一点不要图省事直接用 root 跑容器。Docker 允许把用户加入 docker 组来避免每次 sudo但加入 docker 组本身就等于授予了该用户 root 权限因为可以挂载宿主机目录。所以如果机器上有多人使用这个口子要谨慎开。3.2 用 docker-compose 定义沙盒我强烈建议用docker-compose.yml而不是一条条敲docker run因为 OpenClaw 的启动参数、环境变量、挂载项、安全配置加起来有十几项写在 compose 文件里可读、可版本管理、可一键重建。这是我的 compose 文件标注了每个安全项的作用version: 3.8 services: openclaw: image: openclaw/openclaw:latest container_name: openclaw-sandbox restart: unless-stopped env_file: - .env environment: - OPENCLAW_HOME/app/openclaw - OPENCLAW_LOG_LEVELinfo volumes: - ./data:/app/openclaw - ./logs:/var/log/openclaw networks: - openclaw_net read_only: true tmpfs: - /tmp security_opt: - no-new-privileges:true cap_drop: - ALL cap_add: - CHOWN - SETGID - SETUID logging: driver: json-file options: max-size: 10m max-file: 3 networks: openclaw_net: driver: bridge重点说几个很多人容易忽略的选项。read_only: true会把容器的根文件系统挂载为只读。也就是说容器里的进程无法往/下写任何东西这能挡住不少恶意脚本试图在容器里落盘的骚操作。但 OpenClaw 本身可能要写临时文件所以我把/tmp声明为tmpfs让它在内存里读写容器重启就清空。cap_drop: ALL配合cap_add是 Linux 能力机制的精简用法。默认容器会有很多系统能力但 OpenClaw 作为一个聊天 agent绝大多数都用不到。ALL全部丢弃之后再加回CHOWN、SETGID、SETUID这几个基础能力保证它读写挂载目录时不会因为权限问题报错。这就相当于给进程发了一张只写着“允许改文件属主”的工牌其他权限一概不给。no-new-privileges: true则是禁止进程通过setuid之类的机制获得更高权限进一步封死提权路径。这些参数组合在一起就算 OpenClaw 的某个功能被外部输入诱导执行了恶意命令它能干的事也被限制在一个很小的圈子里。3.3 密钥注入的两种方式密钥注入是整篇的核心。OpenClaw 需要哪些密钥因渠道而异但思路是一样的不要把密钥写死在镜像里也不要把密钥放进挂载目录。第一种方式就是用上面的env_file。.env文件放在宿主机上路径与 compose 文件同级Docker 会在启动容器时把里面的变量注入到容器环境里。.env文件本身的权限要设为600只允许当前用户读写。这是最轻量的做法适合单机个人部署。第二种方式是 Docker Secrets。如果你用的是 Docker Swarm 模式可以把密钥存到 Swarm 的 secret 存储中容器里会以 /run/secrets 的方式读取。单机 Docker 不在 Swarm 模式下也能用 secret但不如 Swarm 场景成熟。我不建议个人部署为了一个 agent 上 Swarm杀鸡用牛刀。所以我的推荐是单机就用env_file 文件权限多机、多人协作才考虑 Secret 管理方案。不管哪种方式都要注意一点容器内的进程如果打印环境变量密钥有可能跟着进日志。所以要在 compose 的logging里设置日志轮转限制单个日志文件大小和数量。我上面配置了单文件 10M、最多 3 个文件这个量级对 OpenClaw 来说足够用日志多了自动清理不会把密钥堆积到磁盘上。3.4 启动、验证、确认密钥被关住了配置写完启动的命令很简单docker compose up -d docker compose logs -f看到日志里正常输出启动信息、频道注册成功基本就起来了。但重点在验证阶段。我习惯做两步验证。第一步确认 OpenClaw 容器内确实拿到了需要的密钥docker exec openclaw-sandbox env | grep API_KEY这一步只是证明变量到位了不能证明安全。所以第二步也是我强烈建议做的从宿主机上确认无法轻易读取容器内文件系统的数据。docker exec openclaw-sandbox cat /proc/1/environ容器 PID 1 进程的环境变量里就有注入的密钥但这个命令需要docker exec权限而这个权限本身是 Docker 用户才有的。也就是说通过容器命令读取是可能的但这不是普通系统用户能做到的。和之前直接cat /home/user/.env相比访问门槛提高了一大截。如果你想进一步收紧还可以在 compose 里把容器暴露给宿主机网络的端口限制到最小。如果 OpenClaw 不需要外部回调我通常不映射任何端口到宿主机只让它在 bridge 网络里对外主动访问模型服务和渠道服务。这样宿主机上扫描端口也找不到它。4. 从“不裸奔”到“更难偷”的进阶加固4.1 最小权限是一切的出发点前面 compose 里的cap_drop、read_only、no-new-privileges都属于最小权限原则的落地。在容器层面我自己的经验是两个方向还可以再挖一层进程用户和挂载目录权限。默认情况下容器里的进程是以 root 身份跑的。虽然容器 root 不等于宿主机 root但它对容器内部有完全控制权。OpenClaw 官方镜像可能没有内置非 root 用户或者内置了但你没用。我建议在 Dockerfile 或 compose 的user字段里指定一个普通 UID比如user: 1000:1000然后把挂载到容器里的数据目录属主改成这个 UID。这样即使容器被攻破进程拿到的也是一个普通用户权限对挂载目录之外的输出只能干瞪眼。宿主机上的数据目录和.env文件的权限也要卡死。.env用chmod 600data目录用chmod 700并且owner别是共享账号。这些都是几分钟能做完的事但对整体安全性提升非常明显。4.2 密钥轮换与泄露后的应急流程很多人的密钥问题不是被偷而是怀疑被偷了但不知道怎么处理。我的建议是建立一套简单到可以背下来的应急流程。首先给每个渠道的密钥一个唯一标识。模型 API 的 Key 用环境变量的名称区分比如ANTHROPIC_API_KEY和DASHSCOPE_API_KEY分开放。渠道 Bot Token 之间不要复用。这样轮换的时候只需要改对应那一个。一旦怀疑泄露操作顺序是这样立即在模型服务商控制台吊销旧 Key签发新 Key。更新宿主机上的.env文件。重启容器docker compose up -d。检查 OpenClaw 日志确认新配置生效、没有报 401 认证错误。排查泄露来源翻 Git 历史、看日志文件、检查是否有共享目录里出现过.env。这个流程里最容易忽略的是第 2 步之前就要重命名.env的旧文件避免它继续暴露在默认路径。我习惯把旧的改名成.env.bak.20250101再操作防止手滑。4.3 日志和监控里的脱敏即使容器环境很干净OpenClaw 本身有时候也会把不该打的东西打到日志里。尤其当你接的渠道多、插件多某个第三方插件可能在请求时把 Authorization 头打印出来。我自己的做法是在日志落盘之前做一道过滤。最直接的方式是设置OPENCLAW_LOG_LEVEL和信息脱敏相关的环境变量很多框架都有内置的敏感信息遮蔽。如果你的版本没有也可以用日志收集层面的替换把常用的 Key 前缀比如sk-ant、sk-等在日志输出前替换成***。还有一个实操细节错误上报。如果接入了 Sentry 这类错误监控服务它会默认收集环境变量、请求头这些内容。在初始化时要把send_default_pii关掉并且把 Key 字段直接标记为tags里不要采集的变量名。我之前就遇到过 OpenClaw 某个插件主动往 Sentry 上报请求体差点把 Key 传出去。4.4 定期体检用工具扫描密钥有没有漏手动检查终究会漏我建议用 gitleaks 这类工具定期扫一遍代码仓库和数据目录。它本质上就是扫描常见的密钥格式比如sk-ant-[0-9A-Za-z]、AKIA[0-9A-Z]这些特征一旦匹配就报告出来。扫描命令大概是这样的我用的是最简单的 Git 仓库扫描gitleaks detect --source . --report-path leak_report.json -v这个工具本身不复杂但价值很高它能帮你在 commit 之前发现.env是否被误提交。我把这个扫描加到了备份后自动执行的脚本里每次备份完扫一次有告警就发通知。这算是我目前用的最“值”的安全小基建。5. 避坑记录实测中经常遇到的坑5.1 session file locked最容易复现的 OpenClaw 报错如果你在容器里和宿主机上同时跑了两个 OpenClaw 进程指向同一个数据目录大概率会遇到这个错误agent failed before reply: session file locked (timeout 60000ms)原因很简单OpenClaw 的某个 session 文件被第一个进程锁住了第二个进程在超时时间内拿不到锁。我遇到的场景是容器重启后旧进程还没退出新的容器又起来抢同一个挂载目录。解决办法是按顺序排查docker ps看是不是有多个容器实例在跑。ps aux | grep openclaw看宿主机上有没有裸进程残留。确认只有一个进程后再删掉 session 目录下的.lock文件注意先备份。这个问题在 Docker 场景下特别好解决因为服务编排能保证同一时间只启动一个副本。但如果你在数据目录里看到了.lock不要直接手删先确认持有锁的进程到底死没死。有一次我嫌麻烦直接删了结果有个旧会话状态损坏恢复起来更费劲。5.2 Docker Desktop 启动失败虚拟化与 WSL2Windows 上装 Docker Desktop不少人卡在启动阶段。日志里可能是virtualization support not detected或者WSL 2 installation is incomplete。这个坑我在两台 Windows 机器上各踩了一次归纳下来就是三件事BIOS / UEFI 里的虚拟化必须打开Intel VT-x / AMD-V。Windows 功能里要启用“虚拟机平台”和“适用于 Linux 的 Windows 子系统”。WSL2 内核更新包要装好。如果你用的是老一点的 CPU还要注意 Hyper-V 和第三方虚拟化软件比如某些安卓模拟器的冲突这两个不能同时启用。在 Windows 上最稳妥的顺序是先关闭其他虚拟化软件安装 WSL再装 Docker Desktop。这套顺序走完启动失败的概率会低很多。5.3 容器内网络不通或者 API 调用超时OpenClaw 容器访问外部 API 超时先查 DNS。容器默认的网络模式是 bridge它会复用宿主机的 DNS 配置。如果你在宿主机上改了/etc/resolv.conf容器的 DNS 也可能跟着变。排查命令docker exec openclaw-sandbox cat /etc/resolv.conf docker exec openclaw-sandbox ping api.example.com如果 ping 不通但 DNS 解析正常再看宿主机的防火墙和代理。很多服务器上开了透明代理容器里的流量如果没走到代理隧道就可能被防火墙 drop。另一种常见情况是网络的 MTU 不一致会导致大包传输失败这种要按 MTU 问题来调。我自己遇到一次比较诡异的现象宿主机一切正常OpenClaw 容器里调用模型 API 时好时坏后来发现是 Docker bridge 网络的 DNS 解析偶尔超时。解决办法是给 compose 加一个固定的 DNSdns: - 223.5.5.5 - 8.8.8.8加完之后问题立刻消失。这个经验我后来在好几台机器上验证过相当有效。5.4 镜像下载慢的处理国内网络环境下直接拉openclaw/openclaw这类镜像有时候会很慢甚至超时。最常见的解决办法是配置镜像加速器。在 Docker Desktop 的 Docker Engine 配置里或者在 Linux 的/etc/docker/daemon.json里加上 registry-mirror 的地址{ registry-mirrors: [https://docker.m.daocloud.io] }改完重启 Docker 再拉镜像速度会明显提升。这里提醒一句不要用来路不明的公共镜像加速器地址优先选有信誉的大平台提供的服务并且确认它的域名和运营方对得上。加速器只影响拉取速度不影响镜像内容校验但安全起见还是谨慎选择。5.5 OpenClaw 本身的两个小坑最后补充两个 OpenClaw 应用层面的问题虽然不是容器相关的但在我把 OpenClaw 搬进 Docker 后也跟着出现过干脆一起写了。第一个是飞书输出被截断。OpenClaw 在飞书里输出长文本时经常被截断这不是网络问题而是飞书消息接口本身的长度限制。解决办法是在配置里拆分消息或者调整输出分段参数。我在 Docker 里跑和在宿主机裸跑遇到的表现一模一样所以确认是应用层行为和沙盒无关。第二个是Channel 选择问题。OpenClaw 支持多种渠道但同一时间建议只把确实在用的 Channel 打开。在 Docker 环境下如果你把 Teams、飞书、Telegram 全部 enabled容器日志里会有大量的连接重试和认证报错看着很像环境出问题其实是没配置对应的 Bot 密钥。按需开启能省下不少排查时间。我个人的体会是把 OpenClaw 装进 Docker 这一步本身不难难的是把“密钥不能裸奔”这个意识真正落到每个环节上。容器给了你一个很干净的边界但边界之内怎么做、边界之外怎么守还是得自己先想清楚。如果你刚接触这套组合建议先照着我上面的 compose 起一个容器跑两天把日志、挂载、密钥注入都摸一遍再考虑要不要加更多安全项。等你习惯了容器化的操作节奏再回头看那些把密钥直接写在宿主机配置文件里的日子你会庆幸自己早一步搬进了沙盒。