前言
这篇我把自己踩了N个坑总结的OpenClaw安全管控方案全分享： 容器化部署隔离权限、IP白名单控制面板访问、token用量告警、 行为日志全追溯，所有配置代码直接复制就能用，自托管玩家必看！
权限问题
1）openclaw可以修改主机上的文件，拿笔者的环境来说，一台debian 13的操作系统上安装的openclaw，安装完成之后它可以随意修改操作系统的文件：
要是别有用心之人能与openclaw对话，直接给你来个 rm -rf /*
2）可以修改自己的配置文件
配置文件也只不过是操作系统上的一个普通文件而已
3）重启某些服务
该服务并不是systemctl托管的，它自己去ps去查找相关信息，并且完成了重启
迁移至容器
刚才的演示中，已经暴露了openclaw的权限问题，如果不加以控制，那openclaw有可能成为潜在的风险，损害电脑上的重要资料
那怎么解决这个问题呢？将openclaw限制在容器当中，可执行的命令、可以修改的文件都受到了限制
-
将本机的~/.openclaw，全部复制到新的路径，为docker启动作为数据目录，也是将原有的配置全部迁移到docker中
cp -rf ~/.openclaw /data/openclaw_docker
-
docker启动脚本
docker run --name openclaw \
-p 18789:18789 \
-u 1000:1000 \
-v ./openclaw_docker:/home/node/.openclaw \
ghcr.io/openclaw/openclaw:latest
-
迁移完成之后验证
docker exec -it openclaw openclaw tui
-
修改web访问
> cat openclaw.json | jq '.gateway.bind'
"lan" # 原为localhost
改了之后要小心了，整个lan都可以访问gateway页面，还是很危险的
-
明确指定哪些地址可以访问 Web 控制台。这提供了最好的安全性
"gateway": {
"port": 18789,
"mode": "local",
"bind": "lan",
"controlUi": {
"allowedOrigins": [
"http://localhost:18789",
"http://127.0.0.1:18789"
]
},
...
}
笔者配置了只允许127.0.0.1来访问gateway页面
token限制
多模型接入之后，最容易踩的坑就是token超量，笔者之前开着verbose模式跑了个文档梳理任务，一晚上刷了几十万token，账单直接起飞，所以一定要加限制。
1）会话级token上限
防止单次对话无限生成、或者反复调用工具刷token，直接在配置里加会话token阈值：
{
"agents": {
"defaults": {
"compaction": {
"reserveTokensFloor": 20000, // 上下文窗口剩余20k token时自动压缩
"maxSessionTokens": 100000 // 单个会话最多累计10万token，超过自动重置
}
}
}
}
超过阈值之后会话会自动触发压缩，或者直接重置，避免无限累加。
2）单模型每日配额限制
如果你用的是收费模型，可以给每个模型加单日最大token限制，超了自动切到备用模型：
{
"models": {
"providers": {
"litellm": {
"api": "openai-completions",
"baseUrl": "http://localhost:4000/v1",
"apiKey": "xxx",
"maxTokensPerDay": 500000, // 单日最多用50万token
"fallbackModel": "litellm/qwen-plus" // 超量自动切到通义千问
}
}
}
}
笔者亲测这个配置救了好多次，再也不用担心跑任务跑超支了。
3）litellm跟踪token
如果是通过litellm来管理大模型key，那使用litellm来跟踪token是最好的
跟踪openclaw行为
可以查看~/.openclaw/agents/<id>/sessions/*.jsonl日志，Agent 做了什么？调了哪些工具？传了什么参数？都可以在该文件中找到。
笔者习惯加个定时任务，每天把日志导出一份到备份目录，万一出了问题直接回溯，连操作时间点都对得上，非常方便。
缩减memory，避免过度联想
记忆多了也有副作用：笔者之前遇到过，给A项目配置的服务器地址，过了半个月问B项目的配置，助手直接把A项目的地址搬出来了，还说得有鼻子有眼，差点踩了线上事故。就是因为记忆库里的内容太多，语义检索的时候把相关的内 容都拉出来了，导致回答串了。
所以一定要限制记忆的范围，避免过度联想：
1）限制自动加载的记忆天数
默认启动会加载今天+昨天的记忆，可以改成只加载今天的，或者完全不自动加载历史记忆：
{
"agents": {
"defaults": {
"memory": {
"loadRecentDays": 1 // 只加载当天的记忆，历史记忆需要手动查询
}
}
}
}
如果你的场景不需要长期记忆，直接设成0，启动完全不加载历史记录，最清爽。
2）关闭会话历史索引
默认记忆搜索会把所有历史会话记录都索引进去，不想让旧会话的内容被检索到，可以关闭：
{
"agents": {
"defaults": {
"memorySearch": {
"sources": ["memory"] // 只索引MEMORY.md和memory/下的文件，不索引会话日志
}
}
}
}
改完之后只有你手动写到记忆文件里的内容才会被检索，会话里的临时内容不会进索引，避免串扰。
3）定期清理过期记忆
写个脚本定时删除超过30天的记忆文件，还有清理向量索引：
#!/bin/bash
# 清理30天以上的记忆
find ~/.openclaw/workspace/memory/ -name "*.md" -mtime +30 -delete
# 重建向量索引
sqlite3 ~/.openclaw/memory/main.sqlite "VACUUM;"
加个cron每周跑一次，记忆库永远都是最新的内容，不会有陈年旧料出来捣乱。
4）按项目拆分记忆
不同项目的记忆不要都堆在根MEMORY.md里，新建子目录拆分：
memory/
├── project-a/
│ └── config.md
├── project-b/
│ └── config.md
└── 2026-03-17.md
查询的时候指定路径，就不会把两个项目的配置搞混了。
联系我
至此，本文结束
在下才疏学浅，有撒汤漏水的，请各位不吝赐教...
本文来自博客园，作者：it排球君，转载请注明原文链接：https://www.cnblogs.com/MrVolleyball/p/19732739
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须在文章页面给出原文连接，否则保留追究法律责任的权利。
来源：https://www.cnblogs.com/MrVolleyball/p/19732739 |
发表于 2026-3-18 10:57:00
