如何在私有 VPS 上运行 OpenClaw，而不暴露你的密钥和本地文件

怎样才算相对安全地运行 OpenClaw？

如果你准备把 OpenClaw 放进持续运行的 Agent 工作流里，一个相对稳妥的默认做法是：把它部署到私有 VPS，而不是日常办公的笔记本；把 API 密钥留在服务器环境变量里；默认收紧入站访问；只给 Agent 开放它真的需要的文件、工具和消息渠道。这样做的价值，不是为了显得更专业，而是出了问题时，事故影响面会小很多。

OpenClaw 的吸引力在于，它能把 Agent、文件、终端、频道和工具接进一个真的能用的工作流里。也正因为这样，一旦它开始读文件、调 API、接 Slack 或 Telegram、执行自动化步骤，你把它跑在哪里，就不再只是方便不方便的问题，而是一个很具体的安全决策。

为什么不建议直接跑在笔记本上？

把 OpenClaw 直接运行在个人 MacBook 或办公桌面的最大问题，不是“不能跑”，而是信任边界过于混杂。个人电脑通常同时保存了高价值的人类数据和高自治的 Agent 运行时，而这两者放在同一台机器上，本身就会放大风险。

常见风险包括：

• 个人 SSH 密钥和云凭证就在同一台机器上
• 浏览器登录态、Cookie、桌面 App 会话容易被同一系统用户访问
• 下载目录、桌面、文档和源码仓库暴露过宽
• 工作与私人消息渠道混在一起
• 快速安装社区技能或实验性工具时，隔离通常不足

如果只是本地 Demo、本地调试或者短时验证，本机运行完全没问题；但只要你准备让 OpenClaw 长期在线，私有 VPS 往往是更干净的默认起点。

更安全的 OpenClaw 架构应该是什么样？

一个更稳妥的部署方式，通常包含三层思路：把 Agent 放进专用主机、把密钥和配置独立管理、把工具和文件访问范围收窄。

层	建议做法	为什么重要
计算环境	专用 VPS 或私有 VM	避免和日常机器混用，降低误触面
密钥管理	环境变量或 secrets manager	不把提供商密钥写进仓库或脚本
网络边界	默认只开 SSH，其余按需开放	降低意外暴露与扫描面
存储范围	只挂载专用工作目录	限制 Agent 的可读写范围
工具集成	只接入必要的渠道和 MCP 工具	减少提示注入或错误操作的影响
模型访问	用统一网关或固定 provider 配置	便于审计、切换和轮换密钥

一个典型的布局会是这样：

手机 / Slack / Telegram
          |
          v
      OpenClaw
          |
          v
   私有 VPS 或私有 VM 边界
          |
   +------+------+
   |             |
   v             v
允许的工具      模型网关
与 MCP Server   或 Provider API

这个结构的重点不在于组件有多少，而在于边界是不是清楚。你希望任何一个模块出问题时，只能碰到它本来就该碰到的那一小块资源。

第一步：从一台干净的私有服务器开始

如果你准备长期运行 OpenClaw，请先给它准备一台只为 AI 工作负载服务的 Linux 主机。除非你本来就在做非常明确的分区隔离，否则不要把它和个人备份、生产数据库、其他业务服务、内部控制台混装在一起。

最低基线建议：

• 干净的 Ubuntu 或 Debian 主机
• 单独的非 root 管理用户
• 只允许 SSH 密钥登录
• 打开防火墙
• 开启基础安全更新

示例命令：

adduser claw
usermod -aG sudo claw

mkdir -p /home/claw/.ssh
chmod 700 /home/claw/.ssh

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw enable

如果你用的是 GetClaw 这类私有 AI 基础设施，很多基础隔离工作会轻松不少，因为这台机器从一开始就被当成 AI 运行环境，而不是办公和实验混在一起的个人系统。

第二步：把 OpenClaw 安装到独立目录

不要把运行时直接塞进一个杂乱的 home 目录。更好的做法，是让 OpenClaw 有一个明确、单独、可审计的工作路径。

sudo mkdir -p /opt/openclaw
sudo chown claw:claw /opt/openclaw

cd /opt/openclaw
git clone https://github.com/openclaw/openclaw.git .

这样做的意义在于，Agent 运行时通常会慢慢长出日志、缓存、临时文件、工具输出和记忆文件。把这些东西都收进一个可预测的目录树里，后面会省很多事：

• 权限审计
• 备份与迁移
• 故障排查
• 目录级访问限制

第三步：把 API 密钥留在服务器，而不是仓库里

不要把 OpenAI、Anthropic、Telegram、Slack 或 webhook 密钥写进仓库里的示例配置，也不要把真实 .env 文件和代码混放。最基本的做法，是把密钥保存在服务器端，并只在运行时注入。

例如：

sudo mkdir -p /etc/openclaw
sudo chmod 700 /etc/openclaw

sudo tee /etc/openclaw/openclaw.env >/dev/null <<'EOF'
OPENAI_API_KEY=replace_me
ANTHROPIC_API_KEY=replace_me
SLACK_BOT_TOKEN=replace_me
TELEGRAM_BOT_TOKEN=replace_me
EOF

sudo chmod 600 /etc/openclaw/openclaw.env
sudo chown root:root /etc/openclaw/openclaw.env

这只是最低可接受模式。如果你本来就有 Secrets Manager，那会更好。关键原则是：密钥不应该跟着仓库、截图、测试脚本或聊天记录四处流动。

第四步：明确限制 Agent 能碰到什么

OpenClaw 不需要访问你的整台机器，也不需要能遍历所有目录才有价值。更好的办法，是只创建几个明确的工作目录，让 Agent、技能和 MCP Server 只在这些范围里活动。

例如：

mkdir -p /opt/openclaw/workspace
mkdir -p /opt/openclaw/logs
mkdir -p /opt/openclaw/data

然后把工具和文件访问范围指向这些目录，而不是这些高风险位置：

• 你的个人 home 目录
• 共享团队网盘或通用挂载目录
• 生产 SSH 密钥目录
• 浏览器 profile 目录
• 密码管理器导出文件

想让 Agent 更安全，最有效的办法之一就是让它能碰到的资源更少，也更清楚。

第五步：只接入真正需要的消息渠道

OpenClaw 的一大优势，是可以把 Agent 接到 Slack、Telegram、WhatsApp、Discord 等渠道。但“支持很多渠道”不等于“第一天就要全部接上”。

更稳妥的上线方式通常是：

1. 先从一个内部渠道开始，例如内部 Slack bot
2. 先验证提示词、工具权限、日志与错误恢复
3. 稳定后再加第二个渠道
4. 把外部用户可接触的渠道放到后面

这样做能减少入口面，也能减少因为某条消息、某个用户行为、某个坏提示词，把 Agent 带进危险动作的概率。

第六步：把 MCP Server 和第三方技能视为信任边界

很多团队在 OpenClaw 这类 Agent 环境里，真正放大风险的并不是模型本身，而是工具层。MCP 很有用，因为它让 Agent 能标准化地访问工具和上下文；但正因为如此，它也经常成为风险放大的入口。

在启用任何 MCP Server 或第三方技能前，至少问清楚：

• 它到底能调用哪些命令或 API？
• 它需要写权限吗，还是只读就够？
• 它持有哪些凭证？
• 它能读哪些目录？
• 它能访问公网吗？
• 它是否会把不可信网页、文档或消息转换成真实工具动作？

2026 年 MCP 安全已经成为主流议题，原因就在这里：一个“看起来只是帮忙接工具”的组件，实际上可能拥有文件系统、浏览器、终端、云资源和内部服务的桥接能力。安全默认值应该是只读起步，再按工作流需求逐步放权。

第七步：用进程管理器托管 OpenClaw

不要把 OpenClaw 长期挂在一个你希望永远别断开的终端标签页里。使用 systemd 或类似进程管理器，可以让它更稳定地重启、记录日志并统一读取环境变量。

例如：

[Unit]
Description=OpenClaw
After=network.target

[Service]
User=claw
WorkingDirectory=/opt/openclaw
EnvironmentFile=/etc/openclaw/openclaw.env
ExecStart=/usr/bin/npm run start
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

启用方式：

sudo systemctl daemon-reload
sudo systemctl enable openclaw
sudo systemctl start openclaw
sudo systemctl status openclaw

这会让你的运行环境更接近“可运维服务”，而不是一个临时实验。

第八步：多模型场景尽量走统一网关

如果你的 OpenClaw 同时接多个模型提供商，最好不要把密钥、路由和模型选择逻辑散落在多处配置中。更稳妥的方式，是统一通过一个模型网关访问不同 Provider。

模型网关的好处通常包括：

• 统一密钥管理
• 更清晰的用量记录
• 故障切换更容易
• 请求格式更一致
• 更容易做 provider 限流和轮换

这对于 OpenClaw 这类 Agent 运行环境尤其重要，因为一旦工作流开始跨渠道、跨技能、跨模型运行，分散的配置会让审计和排障难度明显提高。

一份适合上线前的检查清单

在你把 OpenClaw 放进长期运行状态之前，至少确认以下事项：

• OpenClaw 运行在独立 VPS 或独立 VM 上
• SSH 只允许密钥登录
• 防火墙默认拒绝入站
• 密钥不在仓库中
• Agent 只能访问指定工作目录
• 只接入已经评估过的消息渠道
• MCP Server 默认只读
• 服务由进程管理器托管
• 日志可审计
• 多模型接入有统一网关或统一配置边界

Bottom line

如果你只是做一次性的本地实验，把 OpenClaw 跑在自己的电脑上并没有问题。但如果你想让它持续在线、接入真实渠道、读写真实文件、调用真实工具，那么更安全的默认值，几乎总是：专用私有 VPS、收紧密钥与目录范围、只接入必要渠道、把 MCP 和技能当成真实信任边界来管理。

真正的差别不在于“VPS 听起来更高级”，而在于一旦出问题，受影响的是一台被认真收敛过的 Agent 主机，而不是你整个日常工作环境。

如果你想进一步延伸这条路线，可以继续看 MCP 安全、私有 AI 云部署 和 多模型网关。

FAQ

OpenClaw 放在 VPS 上会更安全吗？

通常会。因为 VPS 的边界更清晰，网络策略、文件范围、用户权限和服务托管方式都更容易收紧。

最大的安全错误是什么？

把 OpenClaw 长期运行在一台同时保存主力 SSH 密钥、浏览器登录态、私人文件和多个工作仓库的日常电脑上。

一开始就需要很多 MCP Server 吗？

不需要。更稳妥的做法是从少量、只读、边界清楚的工具开始，再逐步增加。

来源与说明

• OpenClaw 的核心定位是自托管、多渠道的 AI Agent 运行环境，因此部署边界会直接影响安全边界。
• 这篇文章强调的是运行时隔离、密钥管理、目录收敛和工具信任边界，而不是单纯的“如何把服务跑起来”。
• 延伸阅读：MCP 安全、私有 AI 云、多模型网关。