简介OpenClaw 自托管个人 AI 代理的安全加固指南代码包面向已部署或计划自部署 OpenClaw 的开发者、运维人员提供从安装初始检查到生产环境落地的完整风险收敛方案涵盖配置、权限、监控与应急等多个层面。资源共 3 个文件包含 HTML 格式的详细说明文档、.inscode 配置文件与 .gitignore 忽略规则压缩包整体仅 13KB轻量便携便于按需查阅。内容覆盖安装后应立即执行的基础安全检查、核心配置文件的密钥与权限加固、最小权限原则实施、Prompt Injection 防护流程、第三方插件安全审查以及生产环境部署要点并补充成本监控与 Token 用量管理建议。随包附带的完整安全加固 Checklist 可引导使用者逐项核查每一项配置将已知高危漏洞、越权访问和数据泄露风险降至可接受水平。目前已有 90 人学习下载可供自托管 OpenClaw 的实践者直接对照实施。 先把结论放在前面OpenClaw这阵子热度确实高接入微信、钉钉、本地模型、Active Memory、多模型切换玩法一大堆。但玩几天之后你会发现一个尴尬的事实——绝大多数人部署OpenClaw就是默认配置一键起Control UI裸奔在公网IP上API密钥明文躺在配置文件里服务直接拿root跑着。这哪是智能体这分明是给攻击者准备的智能靶场。这篇指南不聊功能玩法专门聊怎么把OpenClaw的暴露面收住。内容涵盖网络层、应用层、数据层、行为层、运维监控五个维度最后附上几个部署和加固时高频报错的排查实录。如果你已经部署了OpenClaw或者正打算部署建议从头到尾过一遍哪怕只做到其中两三步安全性也能提升一大截。1. 先搞清楚OpenClaw的暴露面在哪里1.1 默认部署下的三大裸奔点OpenClaw本质上是一个常驻运行的智能体服务它通常包含核心调度、Control UI、技能插件、Active Memory存储这几个组件。默认配置下最容易出问题的就是下面这几个位置暴露面默认状态风险等级Control UI 监听地址通常绑定所有网卡0.0.0.0或公网可达高API密钥存储明文写在配置文件或环境变量中高运行权限直接以root或管理员账号运行高文件目录权限用户目录下权限为默认值如755中技能/工具调用默认全部启用或缺乏人工确认机制中Control UI是最致命的那个。它是一个Web控制面板能查看对话记录、管理技能、调整模型参数。一旦裸露在公网任何人都能打开你的控制面板等于把智能体的驾驶座让出去了。我见过不少人在云服务器上部署完OpenClaw顺手把安全组里的所有端口放行了然后用http://服务器IP:端口直接访问控制台——这种情况下连密码都不需要配置里甚至没有默认认证。1.2 为什么智能体比普通Web服务更危险如果你只部署过一个普通的Web服务可能觉得端口暴露就暴露呗里面又没有值钱数据。但OpenClaw这类智能体框架不一样它具备三样普通Web服务没有的东西第一是工具调用能力。OpenClaw能执行shell命令、读写文件、调用外部API如果攻击者拿下了控制面板就等于拿到了一台可以执行任意命令的机器。第二是长期记忆。Active Memory会把对话历史、文档摘要、甚至你粘贴过的密钥片段存下来这些敏感信息一旦泄露比单纯的数据被删还麻烦。第三是模型输出通道。通过提示注入攻击攻击者可以诱导模型输出系统提示词、内部配置甚至API密钥这在缺乏输出过滤的情况下很容易发生。所以OpenClaw的安全加固不能只按传统Web服务的思路来做必须把智能体行为本身当成边界的一部分来约束。1.3 加固路线图最小暴露面原则我的思路很简单每多一个暴露面风险就多一分。尽量把所有服务收敛到本机或内网对外只保留必要的入口比如HTTPS端口然后在这个入口后面叠加认证、权限收敛和审计。具体路线是网络层监听地址反向代理防火墙→ 应用层认证密钥管理技能授权→ 数据与行为层记忆保护沙箱隔离运行用户→ 运维层日志监控备份。下面各节逐一展开。2. 网络层加固把Control UI从公网上摘下来2.1 修改监听地址和端口第一步也是立竿见影的一步让OpenClaw只监听本机回环地址127.0.0.1而不是监听所有网卡。以常见配置文件方式为例server: host: 127.0.0.1 port: 1234如果你是通过环境变量启动一般是这样的export OPENCLAW_HOST127.0.0.1 export OPENCLAW_PORT1234不同版本的OpenClaw配置项名称可能有差异但思路一样把监听地址限制在回环接口上。这样无论云服务器安全组怎么配外部都无法直接访问Control UI。我见过不少人跳过了这一步直接配反向代理结果代理和后端服务都能从公网访问等于白配。改完配置之后重启服务然后用下面两条命令验证# 查看监听地址 ss -lntp | grep 1234 # 本机访问测试 curl http://127.0.0.1:1234看到127.0.0.1:1234而不是0.0.0.0:1234这步就算到位了。2.2 用反向代理把流量收进TLS隧道服务只监听本机之后你需要一个对外入口。这里我的建议是用反向代理对外提供HTTPS访问。Caddy和Nginx都可以个人项目我优先推荐Caddy因为Caddy会自动申请和续期证书配置短对维护成本敏感的个人部署非常友好。Caddy配置示例openclaw.example.com { reverse_proxy 127.0.0.1:1234 }就这么几行。Caddy会自动申请Lets Encrypt证书自动HTTPS你不需要自己管理私钥和证书文件。如果你的Control UI依赖WebSocket做实时推送Caddy默认会处理升级头不需要额外配置。如果你已经有一套Nginx基础设施Nginx版本也不复杂server { listen 443 ssl; server_name openclaw.example.com; ssl_certificate /etc/nginx/ssl/openclaw.crt; ssl_certificate_key /etc/nginx/ssl/openclaw.key; location / { proxy_pass http://127.0.0.1:1234; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; } }注意proxy_set_header Upgrade和Connection那两行缺少了WebSocket连接会失败Control UI可能表现为加载中但进不去。这一步还有一个容易被忽略的收益TLS加密。没有TLS时API密钥和认证Token都是明文在网络上传输的局域网内抓包就能看到。有了HTTPS这层风险就消除了。2.3 防火墙规则只放必要端口即使做了反向代理防火墙还是得设一道防线。以ufw为例建议的规则是这样的sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22/tcp # SSH管理端口 sudo ufw allow 80/tcp # HTTP用于Caddy自动申请证书 sudo ufw allow 443/tcp # HTTPS sudo ufw enable这里有个细节如果你的服务器上只有OpenClaw这一个服务并且不打算用Caddy那连80和443都不用开直接只允许SSH访问就行访问时用SSH隧道转发。SSH隧道方式适合个人临时访问不适合长期多人使用但比暴露公网靠谱得多ssh -L 1234:127.0.0.1:1234 useryour-server然后浏览器访问http://127.0.0.1:1234就能打开Control UI了。数据全程走SSH加密隧道等于省掉了反向代理这一层。3. 应用层加固认证、密钥和技能权限3.1 给Control UI加一把正经的锁很多OpenClaw版本默认不带认证或者只带一个很简单的静态Token。不管版本支持哪种方式你都应该显式配置认证令牌而不是依赖默认状态就安全。生成一个足够强的随机Tokenopenssl rand -hex 32 # 输出示例2f8c1e9b4c7b4a3a8d1e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6然后把它通过环境变量或配置文件注入export OPENCLAW_AUTH_TOKEN把这里替换成上面生成的随机值这里要说明一下不要配置完Token就认为万事大吉。Token只解决谁能访问控制界面的问题不解决控制界面里的操作是否合规的问题。它还应该配合HTTPS一起使用否则Token会在明文传输中被截获。Caddy或Nginx做掉TLS之后Token的安全性才有保障。再强调一个最常见的坑不要把Token写死在代码里然后提交到git仓库。代码仓库一旦公开Token就等于公开了。正确的做法是放进.env文件并把.env写进.gitignore。3.2 API密钥管理别让密钥躺在配置里OpenClaw接入多模型时需要配置各种provider的API密钥这是另一个高频泄露点。我看到过的典型错误是直接在config.yaml里这么写providers: openai: api_key: sk-xxxxxxxxxxxxxx这还不是最糟的。最糟的是有人把这个文件发了博客、贴了GitHub Gist。密钥一旦泄露被刷爆只是时间问题有些人甚至几小时内就能收到账单警告。我的做法是密钥一律走环境变量比如export OPENAI_API_KEYsk-xxxx export DEEPSEEK_API_KEYsk-yyyy然后在配置文件中引用变量而不是写死值。OpenClaw通常支持${VAR}语法或者你在启动脚本里用Dotenv加载。文件权限也很关键cp .env.example .env chmod 600 .env chown openclaw:openclaw .env600权限意味着只有属主能读写其他用户无法访问。这个习惯和SSH私钥的权限管理是同一个道理。如果机器上有多个服务、密钥量比较大还可以考虑用系统的密钥环Secret Store或专门的密钥管理工具。但说实话对个人项目来说环境变量加文件权限已经能满足绝大部分需求不必一上来就把基础设施搞复杂。3.3 技能和工具调用能做不等于该做OpenClaw的Skills机制允许你给智能体挂载各种工具从网页搜索、天气查询到Shell执行、文件操作。安全的基本原则是默认全关按需开放。你可以在配置中设置启用的技能白名单。下面是一个示例skills: enabled: - web_search - weather_query - calendar_read disabled: - shell_exec - ssh_connect - file_delete - docker_manage这里我建议的原则是凡是涉及写操作或命令执行的技能尽量不开或者开启时增加人工确认步骤。比如Shell执行类技能如果OpenClaw支持执行确认机制就打开它。没有确认机制的版本宁可不装这个技能。还有一个思路是把高危工具和高权限模型绑定隔离。比如日常对话用普通模型不挂Shell技能需要代码操作时用一个单独的专用配置和沙箱环境。虽然配置起来麻烦一点但能有效避免一句话prompt把服务器清空这种事故。4. 数据与行为安全给智能体装上刹车4.1 Active Memory里的敏感数据要上锁OpenClaw的Active Memory是一大卖点它让智能体拥有跨会话的长期记忆。但这也意味着对话中提到的API地址、内网路径、账号信息、密钥片段都可能会被持久化存储。如果这个存储目录本身没有防护等于把敏感信息打包放在门口。至少需要做两件事。第一目录权限收紧chown -R openclaw:openclaw ~/.openclaw chmod -R 700 ~/.openclaw第二如果底层存储用的是SQLite或其他数据库文件可以考虑启用加密方案。SQLite本身可以通过SQLCipher这类加密扩展来加密也可以在应用层面把高敏感字段加密后再存。个人项目上如果嫌麻烦至少要做到数据库文件不对其他用户开放读取权限备份文件也加密后再转移到其他机器。4.2 用容器把智能体圈在围栏里不管OpenClaw的代码写得多么小心只要你把它跑在宿主机上且开了Shell技能就可能存在风险。最有效的缓解措施是容器化运行把它关进一个资源受限的围栏。一个参考的docker-compose.ymlversion: 3.8 services: openclaw: image: openclaw/openclaw:latest restart: unless-stopped ports: - 127.0.0.1:1234:1234 environment: - OPENCLAW_AUTH_TOKEN${OPENCLAW_AUTH_TOKEN} - OPENAI_API_KEY${OPENAI_API_KEY} volumes: - ./data:/home/openclaw/.openclaw security_opt: - no-new-privileges:true pids_limit: 200 mem_limit: 1g read_only: true tmpfs: - /tmp这里面几个参数值得展开说一下。ports只映射到127.0.0.1容器对外的世界只有一个回环地址no-new-privileges防止容器内进程提升权限pids_limit限制进程数防止fork炸弹mem_limit限制内存上限read_only把根文件系统设为只读只有通过volume挂载的目录可以写。这一套组合拳打下来即使智能体行为被诱导失控造成的破坏也被限制在极小范围内。不用Docker的话也可以用Firejail或bwrap做类似的动作但配置成本和兼容性都要花时间去调不如Docker来得干脆。4.3 专用运行用户别让root背这个锅如果不用容器直接跑在宿主机上那至少创建一个专用低权限用户来运行服务。这一步在Linux上很简单sudo useradd -r -s /usr/sbin/nologin openclaw sudo chown -R openclaw:openclaw /opt/openclaw sudo chown -R openclaw:openclaw ~openclaw/.openclaw如果通过systemd管理OpenClaw服务还可以加一层隔离配置。在/etc/systemd/system/openclaw.service.d/security.conf中写入[Service] Useropenclaw Groupopenclaw NoNewPrivilegestrue ProtectSystemstrict ProtectHomeread-only PrivateTmptrue其中ProtectSystemstrict会让整个系统目录变成只读ProtectHomeread-only让用户目录也只能读不能写。这样即使OpenClaw被攻破攻击者也很难去篡改系统文件或者其他用户的文件因为它根本没有写权限。这个思路用一句话概括给进程分配够用但不宽裕的权限出问题时连干坏事的手都伸不出去。5. 监控审计与异常发现把动静盯起来5.1 日志开启与轮转很多安全事件不是当时就能发现的而是事后复盘时从日志里找到蛛丝马迹。OpenClaw默认的日志级别可能只有error级别这对于排查问题够用但对于安全审计明显不足。建议在配置中把日志级别调到info甚至更细logging: level: info file: /home/openclaw/.openclaw/logs/openclaw.log日志文件如果不做轮转几个月下来会膨胀到几十GB。配置logrotate是标准做法/home/openclaw/.openclaw/logs/*.log { daily rotate 7 compress missingok notifempty copytruncate }copytruncate这个参数很关键它先复制日志文件再清空原文件不会让OpenClaw进程需要重启才能继续写日志避免日志轮转导致服务中断。5.2 一个简单的异常探测脚本完整的威胁检测系统对个人项目来说太重了。我推荐写一个简单的健康检查脚本用crontab定期跑重点监控三件事端口监听状态、关键文件是否被改动、最近登录失败次数。示例脚本/opt/openclaw/check_health.sh#!/bin/bash # 1. 检查Control UI是否只监听回环地址 LISTEN_OUTPUT$(ss -lntp | grep :1234) if echo $LISTEN_OUTPUT | grep -q 0.0.0.0\|::; then echo [ALERT] Control UI is listening on all interfaces! fi # 2. 检查配置目录是否有异常新增文件 find /home/openclaw/.openclaw -type f -mtime -1 -newer /opt/openclaw/.baseline 2/dev/null # 3. 检查最近的登录失败记录 FAILED_LOGINS$(journalctl -t sshd --since 24 hours ago | grep Failed password | wc -l) if [ $FAILED_LOGINS -gt 50 ]; then echo [ALERT] Too many failed SSH logins in 24h: $FAILED_LOGINS fi然后加到crontab*/10 * * * * /opt/openclaw/check_health.sh /var/log/openclaw_health.log 21这一步不需要做到多智能目的是让异常情况能被看到。安全领域的共识是检测到问题比完全没有视野强一万倍。5.3 备份必须加密备份这个动作本身没有争议但很多人的备份是明文tar包直接扔到对象存储或者另一台机器上。如果备份内容包含了Control UI的数据库、Active Memory数据、配置文件那备份文件本身就是敏感数据。我的做法是备份后直接加密。用tar配合gpgtar czf - /home/openclaw/.openclaw | gpg --symmetric --cipher-algo AES256 -o openclaw-backup-$(date %F).tgz.gpg或者用restic这类工具它天然支持加密存储和增量备份恢复也很方便。选哪个不重要重要的是建立规律备份的习惯并且偶尔演练一下恢复流程——没有验证过可恢复性的备份出问题时才发现用不了才是最绝望的。6. 常见报错与安全排查实录6.1 Control UI启动失败did not start这个报错很常见表现形式是服务正常、但浏览器访问Control UI时提示启动失败。排查顺序建议如下# 1. 确认后端进程是否在监听预期端口 ss -lntp | grep 1234 # 2. 确认本机访问是否正常 curl -I http://127.0.0.1:1234 # 3. 查看服务日志 journalctl -u openclaw -n 50如果是通过反向代理访问先本地curl确认后端没问题再检查代理配置。这里容易踩的坑是WebSocket代理头没配置前面Nginx那段配置里的Upgrade字段表现就是页面打开了一部分但实时推送不工作看起来像没启动。6.2 Agent报错unknown model: deepseek这个报错在配置多模型时非常典型。OpenClaw会报agent failed before reply: unknown model: deepseek含义是模型中继器不认识你填的模型名称。大多数情况是模型名和provider的模型ID不匹配。解决方式是确认当前模型服务商支持的确切模型标识比如某些平台要填deepseek-chat而不是deepseek。在配置provider的模型映射时尽量用官方文档里的模型ID原文不要自己起别名。还有一种情况是零Token模式下配置的模型名是自定义的需要检查模型服务是否真的支持。这个报错本身不是安全问题但它暴露的根因——配置混乱、凭据绑定错误——可能导致请求打到非预期的模型服务上去从安全角度也值得认真清理配置。6.3 Windows文件锁导致的资源清理失败Windows部署时有一个高频报错failed to remove ~\.openclaw: error: ebusy: resource busy or locked, unlink。这是因为OpenClaw的进程还在运行相关文件被句柄占用卸载或重装时无法删除。正确做法是先停止服务并结束进程再删除文件Stop-Service openclaw -ErrorAction SilentlyContinue Stop-Process -Name openclaw -Force -ErrorAction SilentlyContinue Start-Sleep -Seconds 3 Remove-Item -Recurse -Force $HOME\.openclaw这里有一个安全意识问题如果目录里有Active Memory数据删除前要确认不需要保留或者先备份加密。很多人一看到ebusy就直接rm -rf结果连同记忆数据一起删掉了后悔都来不及。6.4 Node运行时缺失node runtime not foundWindows下安装OpenClaw时有时会报oneclaw node runtime not found。这通常是Node.js未安装或者版本太旧。OpenClaw依赖Node运行时来做前端和部分后端逻辑需要Node 18。这里需要特别注意不要为了省事直接以管理员身份全局安装Node也不要用被篡改的安装包。从官方渠道下载安装包或者用nvm这类版本管理工具安装既能解决运行时缺失问题也能避免供应链投毒。安装完成之后重新打开终端运行node -v验证版本再执行OpenClaw的安装命令。写在最后我做OpenClaw部署和加固走了不少弯路。第一次部署完之后拿nmap扫了下云服务器发现1234端口公网直接可以访问Control UI连个密码都没有那种感觉真的很吓人。后来花了一个周末把反向代理、Token认证、专用用户、容器资源限制、日志告警这套全部补上之后再跑就没有出过什么问题。安全这件事说到底不是追求绝对不可攻破而是把攻击成本抬到对方不愿意承担的高度。哪怕是只做了监听地址改为127.0.0.1和加一个随机Token这两步你也已经比绝大多数人安全了。每次升级OpenClaw之后建议重新检查一遍监听端口、目录权限和Token配置这套检查流程值得养成习惯。本文还有配套的精品资源点击获取 OpenClaw安全加固指南：收敛暴露面与五大防护实践
简介OpenClaw 自托管个人 AI 代理的安全加固指南代码包面向已部署或计划自部署 OpenClaw 的开发者、运维人员提供从安装初始检查到生产环境落地的完整风险收敛方案涵盖配置、权限、监控与应急等多个层面。资源共 3 个文件包含 HTML 格式的详细说明文档、.inscode 配置文件与 .gitignore 忽略规则压缩包整体仅 13KB轻量便携便于按需查阅。内容覆盖安装后应立即执行的基础安全检查、核心配置文件的密钥与权限加固、最小权限原则实施、Prompt Injection 防护流程、第三方插件安全审查以及生产环境部署要点并补充成本监控与 Token 用量管理建议。随包附带的完整安全加固 Checklist 可引导使用者逐项核查每一项配置将已知高危漏洞、越权访问和数据泄露风险降至可接受水平。目前已有 90 人学习下载可供自托管 OpenClaw 的实践者直接对照实施。 先把结论放在前面OpenClaw这阵子热度确实高接入微信、钉钉、本地模型、Active Memory、多模型切换玩法一大堆。但玩几天之后你会发现一个尴尬的事实——绝大多数人部署OpenClaw就是默认配置一键起Control UI裸奔在公网IP上API密钥明文躺在配置文件里服务直接拿root跑着。这哪是智能体这分明是给攻击者准备的智能靶场。这篇指南不聊功能玩法专门聊怎么把OpenClaw的暴露面收住。内容涵盖网络层、应用层、数据层、行为层、运维监控五个维度最后附上几个部署和加固时高频报错的排查实录。如果你已经部署了OpenClaw或者正打算部署建议从头到尾过一遍哪怕只做到其中两三步安全性也能提升一大截。1. 先搞清楚OpenClaw的暴露面在哪里1.1 默认部署下的三大裸奔点OpenClaw本质上是一个常驻运行的智能体服务它通常包含核心调度、Control UI、技能插件、Active Memory存储这几个组件。默认配置下最容易出问题的就是下面这几个位置暴露面默认状态风险等级Control UI 监听地址通常绑定所有网卡0.0.0.0或公网可达高API密钥存储明文写在配置文件或环境变量中高运行权限直接以root或管理员账号运行高文件目录权限用户目录下权限为默认值如755中技能/工具调用默认全部启用或缺乏人工确认机制中Control UI是最致命的那个。它是一个Web控制面板能查看对话记录、管理技能、调整模型参数。一旦裸露在公网任何人都能打开你的控制面板等于把智能体的驾驶座让出去了。我见过不少人在云服务器上部署完OpenClaw顺手把安全组里的所有端口放行了然后用http://服务器IP:端口直接访问控制台——这种情况下连密码都不需要配置里甚至没有默认认证。1.2 为什么智能体比普通Web服务更危险如果你只部署过一个普通的Web服务可能觉得端口暴露就暴露呗里面又没有值钱数据。但OpenClaw这类智能体框架不一样它具备三样普通Web服务没有的东西第一是工具调用能力。OpenClaw能执行shell命令、读写文件、调用外部API如果攻击者拿下了控制面板就等于拿到了一台可以执行任意命令的机器。第二是长期记忆。Active Memory会把对话历史、文档摘要、甚至你粘贴过的密钥片段存下来这些敏感信息一旦泄露比单纯的数据被删还麻烦。第三是模型输出通道。通过提示注入攻击攻击者可以诱导模型输出系统提示词、内部配置甚至API密钥这在缺乏输出过滤的情况下很容易发生。所以OpenClaw的安全加固不能只按传统Web服务的思路来做必须把智能体行为本身当成边界的一部分来约束。1.3 加固路线图最小暴露面原则我的思路很简单每多一个暴露面风险就多一分。尽量把所有服务收敛到本机或内网对外只保留必要的入口比如HTTPS端口然后在这个入口后面叠加认证、权限收敛和审计。具体路线是网络层监听地址反向代理防火墙→ 应用层认证密钥管理技能授权→ 数据与行为层记忆保护沙箱隔离运行用户→ 运维层日志监控备份。下面各节逐一展开。2. 网络层加固把Control UI从公网上摘下来2.1 修改监听地址和端口第一步也是立竿见影的一步让OpenClaw只监听本机回环地址127.0.0.1而不是监听所有网卡。以常见配置文件方式为例server: host: 127.0.0.1 port: 1234如果你是通过环境变量启动一般是这样的export OPENCLAW_HOST127.0.0.1 export OPENCLAW_PORT1234不同版本的OpenClaw配置项名称可能有差异但思路一样把监听地址限制在回环接口上。这样无论云服务器安全组怎么配外部都无法直接访问Control UI。我见过不少人跳过了这一步直接配反向代理结果代理和后端服务都能从公网访问等于白配。改完配置之后重启服务然后用下面两条命令验证# 查看监听地址 ss -lntp | grep 1234 # 本机访问测试 curl http://127.0.0.1:1234看到127.0.0.1:1234而不是0.0.0.0:1234这步就算到位了。2.2 用反向代理把流量收进TLS隧道服务只监听本机之后你需要一个对外入口。这里我的建议是用反向代理对外提供HTTPS访问。Caddy和Nginx都可以个人项目我优先推荐Caddy因为Caddy会自动申请和续期证书配置短对维护成本敏感的个人部署非常友好。Caddy配置示例openclaw.example.com { reverse_proxy 127.0.0.1:1234 }就这么几行。Caddy会自动申请Lets Encrypt证书自动HTTPS你不需要自己管理私钥和证书文件。如果你的Control UI依赖WebSocket做实时推送Caddy默认会处理升级头不需要额外配置。如果你已经有一套Nginx基础设施Nginx版本也不复杂server { listen 443 ssl; server_name openclaw.example.com; ssl_certificate /etc/nginx/ssl/openclaw.crt; ssl_certificate_key /etc/nginx/ssl/openclaw.key; location / { proxy_pass http://127.0.0.1:1234; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; } }注意proxy_set_header Upgrade和Connection那两行缺少了WebSocket连接会失败Control UI可能表现为加载中但进不去。这一步还有一个容易被忽略的收益TLS加密。没有TLS时API密钥和认证Token都是明文在网络上传输的局域网内抓包就能看到。有了HTTPS这层风险就消除了。2.3 防火墙规则只放必要端口即使做了反向代理防火墙还是得设一道防线。以ufw为例建议的规则是这样的sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22/tcp # SSH管理端口 sudo ufw allow 80/tcp # HTTP用于Caddy自动申请证书 sudo ufw allow 443/tcp # HTTPS sudo ufw enable这里有个细节如果你的服务器上只有OpenClaw这一个服务并且不打算用Caddy那连80和443都不用开直接只允许SSH访问就行访问时用SSH隧道转发。SSH隧道方式适合个人临时访问不适合长期多人使用但比暴露公网靠谱得多ssh -L 1234:127.0.0.1:1234 useryour-server然后浏览器访问http://127.0.0.1:1234就能打开Control UI了。数据全程走SSH加密隧道等于省掉了反向代理这一层。3. 应用层加固认证、密钥和技能权限3.1 给Control UI加一把正经的锁很多OpenClaw版本默认不带认证或者只带一个很简单的静态Token。不管版本支持哪种方式你都应该显式配置认证令牌而不是依赖默认状态就安全。生成一个足够强的随机Tokenopenssl rand -hex 32 # 输出示例2f8c1e9b4c7b4a3a8d1e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6然后把它通过环境变量或配置文件注入export OPENCLAW_AUTH_TOKEN把这里替换成上面生成的随机值这里要说明一下不要配置完Token就认为万事大吉。Token只解决谁能访问控制界面的问题不解决控制界面里的操作是否合规的问题。它还应该配合HTTPS一起使用否则Token会在明文传输中被截获。Caddy或Nginx做掉TLS之后Token的安全性才有保障。再强调一个最常见的坑不要把Token写死在代码里然后提交到git仓库。代码仓库一旦公开Token就等于公开了。正确的做法是放进.env文件并把.env写进.gitignore。3.2 API密钥管理别让密钥躺在配置里OpenClaw接入多模型时需要配置各种provider的API密钥这是另一个高频泄露点。我看到过的典型错误是直接在config.yaml里这么写providers: openai: api_key: sk-xxxxxxxxxxxxxx这还不是最糟的。最糟的是有人把这个文件发了博客、贴了GitHub Gist。密钥一旦泄露被刷爆只是时间问题有些人甚至几小时内就能收到账单警告。我的做法是密钥一律走环境变量比如export OPENAI_API_KEYsk-xxxx export DEEPSEEK_API_KEYsk-yyyy然后在配置文件中引用变量而不是写死值。OpenClaw通常支持${VAR}语法或者你在启动脚本里用Dotenv加载。文件权限也很关键cp .env.example .env chmod 600 .env chown openclaw:openclaw .env600权限意味着只有属主能读写其他用户无法访问。这个习惯和SSH私钥的权限管理是同一个道理。如果机器上有多个服务、密钥量比较大还可以考虑用系统的密钥环Secret Store或专门的密钥管理工具。但说实话对个人项目来说环境变量加文件权限已经能满足绝大部分需求不必一上来就把基础设施搞复杂。3.3 技能和工具调用能做不等于该做OpenClaw的Skills机制允许你给智能体挂载各种工具从网页搜索、天气查询到Shell执行、文件操作。安全的基本原则是默认全关按需开放。你可以在配置中设置启用的技能白名单。下面是一个示例skills: enabled: - web_search - weather_query - calendar_read disabled: - shell_exec - ssh_connect - file_delete - docker_manage这里我建议的原则是凡是涉及写操作或命令执行的技能尽量不开或者开启时增加人工确认步骤。比如Shell执行类技能如果OpenClaw支持执行确认机制就打开它。没有确认机制的版本宁可不装这个技能。还有一个思路是把高危工具和高权限模型绑定隔离。比如日常对话用普通模型不挂Shell技能需要代码操作时用一个单独的专用配置和沙箱环境。虽然配置起来麻烦一点但能有效避免一句话prompt把服务器清空这种事故。4. 数据与行为安全给智能体装上刹车4.1 Active Memory里的敏感数据要上锁OpenClaw的Active Memory是一大卖点它让智能体拥有跨会话的长期记忆。但这也意味着对话中提到的API地址、内网路径、账号信息、密钥片段都可能会被持久化存储。如果这个存储目录本身没有防护等于把敏感信息打包放在门口。至少需要做两件事。第一目录权限收紧chown -R openclaw:openclaw ~/.openclaw chmod -R 700 ~/.openclaw第二如果底层存储用的是SQLite或其他数据库文件可以考虑启用加密方案。SQLite本身可以通过SQLCipher这类加密扩展来加密也可以在应用层面把高敏感字段加密后再存。个人项目上如果嫌麻烦至少要做到数据库文件不对其他用户开放读取权限备份文件也加密后再转移到其他机器。4.2 用容器把智能体圈在围栏里不管OpenClaw的代码写得多么小心只要你把它跑在宿主机上且开了Shell技能就可能存在风险。最有效的缓解措施是容器化运行把它关进一个资源受限的围栏。一个参考的docker-compose.ymlversion: 3.8 services: openclaw: image: openclaw/openclaw:latest restart: unless-stopped ports: - 127.0.0.1:1234:1234 environment: - OPENCLAW_AUTH_TOKEN${OPENCLAW_AUTH_TOKEN} - OPENAI_API_KEY${OPENAI_API_KEY} volumes: - ./data:/home/openclaw/.openclaw security_opt: - no-new-privileges:true pids_limit: 200 mem_limit: 1g read_only: true tmpfs: - /tmp这里面几个参数值得展开说一下。ports只映射到127.0.0.1容器对外的世界只有一个回环地址no-new-privileges防止容器内进程提升权限pids_limit限制进程数防止fork炸弹mem_limit限制内存上限read_only把根文件系统设为只读只有通过volume挂载的目录可以写。这一套组合拳打下来即使智能体行为被诱导失控造成的破坏也被限制在极小范围内。不用Docker的话也可以用Firejail或bwrap做类似的动作但配置成本和兼容性都要花时间去调不如Docker来得干脆。4.3 专用运行用户别让root背这个锅如果不用容器直接跑在宿主机上那至少创建一个专用低权限用户来运行服务。这一步在Linux上很简单sudo useradd -r -s /usr/sbin/nologin openclaw sudo chown -R openclaw:openclaw /opt/openclaw sudo chown -R openclaw:openclaw ~openclaw/.openclaw如果通过systemd管理OpenClaw服务还可以加一层隔离配置。在/etc/systemd/system/openclaw.service.d/security.conf中写入[Service] Useropenclaw Groupopenclaw NoNewPrivilegestrue ProtectSystemstrict ProtectHomeread-only PrivateTmptrue其中ProtectSystemstrict会让整个系统目录变成只读ProtectHomeread-only让用户目录也只能读不能写。这样即使OpenClaw被攻破攻击者也很难去篡改系统文件或者其他用户的文件因为它根本没有写权限。这个思路用一句话概括给进程分配够用但不宽裕的权限出问题时连干坏事的手都伸不出去。5. 监控审计与异常发现把动静盯起来5.1 日志开启与轮转很多安全事件不是当时就能发现的而是事后复盘时从日志里找到蛛丝马迹。OpenClaw默认的日志级别可能只有error级别这对于排查问题够用但对于安全审计明显不足。建议在配置中把日志级别调到info甚至更细logging: level: info file: /home/openclaw/.openclaw/logs/openclaw.log日志文件如果不做轮转几个月下来会膨胀到几十GB。配置logrotate是标准做法/home/openclaw/.openclaw/logs/*.log { daily rotate 7 compress missingok notifempty copytruncate }copytruncate这个参数很关键它先复制日志文件再清空原文件不会让OpenClaw进程需要重启才能继续写日志避免日志轮转导致服务中断。5.2 一个简单的异常探测脚本完整的威胁检测系统对个人项目来说太重了。我推荐写一个简单的健康检查脚本用crontab定期跑重点监控三件事端口监听状态、关键文件是否被改动、最近登录失败次数。示例脚本/opt/openclaw/check_health.sh#!/bin/bash # 1. 检查Control UI是否只监听回环地址 LISTEN_OUTPUT$(ss -lntp | grep :1234) if echo $LISTEN_OUTPUT | grep -q 0.0.0.0\|::; then echo [ALERT] Control UI is listening on all interfaces! fi # 2. 检查配置目录是否有异常新增文件 find /home/openclaw/.openclaw -type f -mtime -1 -newer /opt/openclaw/.baseline 2/dev/null # 3. 检查最近的登录失败记录 FAILED_LOGINS$(journalctl -t sshd --since 24 hours ago | grep Failed password | wc -l) if [ $FAILED_LOGINS -gt 50 ]; then echo [ALERT] Too many failed SSH logins in 24h: $FAILED_LOGINS fi然后加到crontab*/10 * * * * /opt/openclaw/check_health.sh /var/log/openclaw_health.log 21这一步不需要做到多智能目的是让异常情况能被看到。安全领域的共识是检测到问题比完全没有视野强一万倍。5.3 备份必须加密备份这个动作本身没有争议但很多人的备份是明文tar包直接扔到对象存储或者另一台机器上。如果备份内容包含了Control UI的数据库、Active Memory数据、配置文件那备份文件本身就是敏感数据。我的做法是备份后直接加密。用tar配合gpgtar czf - /home/openclaw/.openclaw | gpg --symmetric --cipher-algo AES256 -o openclaw-backup-$(date %F).tgz.gpg或者用restic这类工具它天然支持加密存储和增量备份恢复也很方便。选哪个不重要重要的是建立规律备份的习惯并且偶尔演练一下恢复流程——没有验证过可恢复性的备份出问题时才发现用不了才是最绝望的。6. 常见报错与安全排查实录6.1 Control UI启动失败did not start这个报错很常见表现形式是服务正常、但浏览器访问Control UI时提示启动失败。排查顺序建议如下# 1. 确认后端进程是否在监听预期端口 ss -lntp | grep 1234 # 2. 确认本机访问是否正常 curl -I http://127.0.0.1:1234 # 3. 查看服务日志 journalctl -u openclaw -n 50如果是通过反向代理访问先本地curl确认后端没问题再检查代理配置。这里容易踩的坑是WebSocket代理头没配置前面Nginx那段配置里的Upgrade字段表现就是页面打开了一部分但实时推送不工作看起来像没启动。6.2 Agent报错unknown model: deepseek这个报错在配置多模型时非常典型。OpenClaw会报agent failed before reply: unknown model: deepseek含义是模型中继器不认识你填的模型名称。大多数情况是模型名和provider的模型ID不匹配。解决方式是确认当前模型服务商支持的确切模型标识比如某些平台要填deepseek-chat而不是deepseek。在配置provider的模型映射时尽量用官方文档里的模型ID原文不要自己起别名。还有一种情况是零Token模式下配置的模型名是自定义的需要检查模型服务是否真的支持。这个报错本身不是安全问题但它暴露的根因——配置混乱、凭据绑定错误——可能导致请求打到非预期的模型服务上去从安全角度也值得认真清理配置。6.3 Windows文件锁导致的资源清理失败Windows部署时有一个高频报错failed to remove ~\.openclaw: error: ebusy: resource busy or locked, unlink。这是因为OpenClaw的进程还在运行相关文件被句柄占用卸载或重装时无法删除。正确做法是先停止服务并结束进程再删除文件Stop-Service openclaw -ErrorAction SilentlyContinue Stop-Process -Name openclaw -Force -ErrorAction SilentlyContinue Start-Sleep -Seconds 3 Remove-Item -Recurse -Force $HOME\.openclaw这里有一个安全意识问题如果目录里有Active Memory数据删除前要确认不需要保留或者先备份加密。很多人一看到ebusy就直接rm -rf结果连同记忆数据一起删掉了后悔都来不及。6.4 Node运行时缺失node runtime not foundWindows下安装OpenClaw时有时会报oneclaw node runtime not found。这通常是Node.js未安装或者版本太旧。OpenClaw依赖Node运行时来做前端和部分后端逻辑需要Node 18。这里需要特别注意不要为了省事直接以管理员身份全局安装Node也不要用被篡改的安装包。从官方渠道下载安装包或者用nvm这类版本管理工具安装既能解决运行时缺失问题也能避免供应链投毒。安装完成之后重新打开终端运行node -v验证版本再执行OpenClaw的安装命令。写在最后我做OpenClaw部署和加固走了不少弯路。第一次部署完之后拿nmap扫了下云服务器发现1234端口公网直接可以访问Control UI连个密码都没有那种感觉真的很吓人。后来花了一个周末把反向代理、Token认证、专用用户、容器资源限制、日志告警这套全部补上之后再跑就没有出过什么问题。安全这件事说到底不是追求绝对不可攻破而是把攻击成本抬到对方不愿意承担的高度。哪怕是只做了监听地址改为127.0.0.1和加一个随机Token这两步你也已经比绝大多数人安全了。每次升级OpenClaw之后建议重新检查一遍监听端口、目录权限和Token配置这套检查流程值得养成习惯。本文还有配套的精品资源点击获取