在 VPS 上安全运行 OpenClaw

OpenClaw 是什么，以及为什么要先加固它

OpenClaw 是一款自托管的 AI 代理（AI agent）。您在自己的服务器上运行它，把它连接到一个大语言模型，它就能执行 shell 命令、控制浏览器、读写您的文件，并根据您从聊天应用发去的消息采取行动。这种触及范围正是这款工具的全部意义所在，同时也是它的全部风险所在。一个能执行任意命令的代理，其安全程度只取决于它所运行的机器，以及您为它设置的种种限制。

有两个事实为本指南定下了基调。第一，OpenClaw 的设计就是要由您来加固。它的安全模型把严格的工具策略、沙箱隔离和谨慎的权限管理这份责任交给了运维者，而不是依赖某个安全的默认设置。第二，该项目已经发生过一起严重的安全事件：2026 年 3 月，四天之内披露了九个安全问题，其中包括一个严重的提权漏洞 CVE-2026-32922，评分高达 9.9（满分 10）。这两个事实都不意味着您应当避开 OpenClaw。它们意味着您不该图省事地运行它，而本指南讲的正是谨慎的做法。

也有好消息。OpenClaw 已经替您做出了一个安全的选择：它的网关，也就是控制一切的那个单一进程，默认监听在回环地址（loopback）上，因此除非您特意去暴露它，否则它无法从互联网访问到。下文的大部分工作，就是保持它维持这种状态，并在真的出问题时把影响范围（blast radius）限制到最小。

给 OpenClaw 一个自己的非特权用户

绝不要以 root 身份运行代理。如果 OpenClaw 以 root 运行，一旦出了任何问题，无论是程序缺陷、一条恶意指令，还是上文那样的 CVE，造成的破坏都没有上限。请创建一个专用的系统用户，不给它登录 shell，也不给 sudo，然后以该用户身份运行代理：

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

OpenClaw 拥有的一切都放在 /opt/openclaw 目录下，归该账户所有。这是最重要的一步，其原理与 以非特权用户运行服务 中讲到的完全一致：代理所运行的那个账户，就是它能破坏的一切的上限。

安装 OpenClaw

OpenClaw 以 npm 包的形式发布，因此如果服务器上还没有 Node.js，请先安装它。全局安装该包，这样 openclaw 二进制文件就会加入每个用户的 PATH，然后运行一次性的初始化引导步骤：

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

以 openclaw 用户身份运行引导，意味着代理的配置会落在它的主目录 /opt/openclaw 里，而不是 root 的目录里。该项目还提供了一个 curl -fsSL https://openclaw.ai/install.sh | bash 安装脚本，用一行命令完成同样的安装。请在引导过程中跳过 --install-daemon 标志：它会注册 OpenClaw 自带的服务，而您下文构建的加固版 systemd 单元更为严格。

让网关保持在回环地址上，并置于防火墙之后

网关默认绑定到 127.0.0.1。就让它待在那儿。几乎没有任何理由把那个端口发布到互联网上，那样做等于把一条通往一个专门执行命令的进程的远程入口，交给任何发现它的人。

在机器前面放一道默认拒绝（default-deny）的防火墙，这样就不会有东西被意外暴露：

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

这里有两个陷阱要避开。一道只覆盖 IPv4 的防火墙，可能会让同一个服务在 IPv6 上完全敞开，这正是坑了许多人的 IPv6 防火墙漏洞。另外，如果您需要从自己的笔记本访问网关，不要去开放那个端口。请通过 VPN 或 SSH 隧道去访问它，这样代理就永远不会监听在开放的互联网上。

隔离它的密钥

OpenClaw 需要一个 API 密钥，用于连接您所使用的那个语言模型。这个密钥能花掉您的钱，还能通过代理以您的名义采取行动，所以请把它当作密码来对待。别让它出现在单元文件里，也别放进任何代码仓库。把它放在一个只有 OpenClaw 用户能读取的文件里：

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

systemd 单元通过 EnvironmentFile 加载该文件，因此密钥能到达进程，却从不会出现在命令行、日志或您的 shell 历史记录中。

以加固后的 systemd 服务运行它

在 systemd 下运行代理，能带来自动重启、通过 journalctl 输出的干净日志，以及最重要的一点——一整套内核级的沙箱选项，即使进程被攻破，也能收缩它所能触及的范围。对代理而言最要紧的几项是：NoNewPrivileges，让它永远无法获得新权限；ProtectSystem=strict，让文件系统除您允许写入之处外一律只读；PrivateTmp，给它一个自己隔离的临时目录；以及 ProtectHome，让它无法读取各个主目录。

在这里生成一份完整的加固单元，然后把它复制到 /etc/systemd/system/openclaw.service：

该单元启动 openclaw gateway，也就是控制代理的那个长期运行的进程；如果 which openclaw 在您的服务器上显示的是另一个路径，请相应调整 ExecStart。关于这些指令，以及 daemon-reload 和 enable --now 的完整讲解，见 把程序作为 systemd 服务运行。粘贴好单元之后的简短版本：

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

也要加固前门

一台代理机器的安全程度，只取决于它周围那台服务器。再加两层就能收尾。把 SSH 改为仅密钥认证并禁用 root 登录，正如 VPS 上的 SSH 加固 中所讲，这样您用来管理机器的那个账户就无法被暴力破解。然后加上 Fail2ban，把那些猛敲每个公开端口的扫描器赶走。这两者都不直接触及 OpenClaw，但都切断了攻击者用来到达它的路径。

有意识地保持更新

2026 年 3 月的那批披露，是保持更新最清楚不过的理由。代理里的提权漏洞远比普通 Web 应用里的严重得多，因为代理本身就已经在执行命令。请留意项目的发布动态，尽快应用安全更新，把 OpenClaw 的升级当作例行维护，而不是可以一拖再拖的事情。

为了搞清楚您到底在加固什么，一个 OpenClaw 式代理的架构 会逐一讲解它的各个组成部分，而 在 VPS 上构建你自己的 AI 代理 则涵盖了任何代理都具有的大致形态。

FAQ

在公网 VPS 上运行 OpenClaw 安全吗？

可以安全，前提是您对它做了加固。OpenClaw 的强大是设计使然：它执行 shell 命令、控制浏览器，因此随意配置确实危险，而且该项目已经出过一个严重的 CVE（2026 年 3 月的 CVE-2026-32922）。它的安全模型指望您这位运维者去加上各种限制。请以非特权用户身份运行它，让它的网关保持在回环地址上、置于默认拒绝的防火墙之后，隔离它的 API 密钥，并把它作为加固后的 systemd 服务来运行。

我该把 OpenClaw 网关暴露到互联网上吗？

不该。网关默认绑定到回环地址，您应当让它待在那儿。它是控制代理的那个单一进程，因此一个被暴露的网关就是一条通往某个专门执行命令之物的远程通道。如果您需要远程访问它，请使用 VPN 或 SSH 隧道，而不是去开放那个端口。

OpenClaw 该以什么用户身份运行？

一个专用的系统用户，没有登录 shell，也没有 sudo，绝不用 root。如果代理被攻破，它的用户账户就是破坏程度的上限，所以那个账户应当只拥有它自己在 /opt/openclaw 这类目录下的文件，此外别无其他。

我该如何确保 OpenClaw 的 API 密钥安全？

把它们存放在一个只有 OpenClaw 用户可读的文件里（权限 600），并用 systemd 的 EnvironmentFile 把它加载进服务。让密钥远离单元文件、远离您的 shell 历史记录，也远离任何 git 仓库。一旦您怀疑它泄露过，就轮换它。