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

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

最稳妥的实践，是把 OpenClaw 运行在私有 VPS 上，而不是你的日常办公电脑上；把 API 密钥保存在服务器环境变量里；默认收紧入站访问；并且只给 Agent 开放它真正需要的文件、工具和消息渠道。这样做的核心价值，是在技能、MCP Server、提示注入或消息集成异常时，把影响范围压到最小。

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

因为个人电脑往往混合了高价值的人类数据和高自治的 Agent 运行时。

常见风险包括：

• 个人 SSH 密钥就在同一台机器上
• 浏览器登录态和 Cookie 可被本机用户访问
• 下载目录、桌面、文档和源码仓库过度暴露
• 工作与私人消息渠道混在一起

对 Demo 来说，本地运行没有问题；对持续运行的自动化来说，私有 VPS 更合适。

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

建议把 Agent 放在专用主机里，把密钥和工具边界拆开。

| 层 | 建议 | 原因 | |---|---|---| | 计算环境 | 专用 VPS 或私有 VM | 避免和日常机器混用 | | 密钥 | 环境变量或 secrets manager | 不把密钥写进仓库 | | 网络 | 默认只开 SSH | 减少意外暴露 | | 存储 | 专用工作目录 | 限制可读可写范围 | | 集成 | 只接入必要渠道 | 降低滥用面 |

实操重点

1. 用干净的 Linux 服务器部署 OpenClaw
2. 把运行目录独立到 /opt/openclaw
3. 把密钥放在服务器环境文件中，而不是仓库里
4. 只开放明确的工作目录
5. 按渠道分级授权，不要一次接入所有消息平台
6. 把 MCP Server 和第三方技能视为信任边界
7. 用 systemd 等进程管理器托管服务
8. 如需多模型，统一走一个模型网关

上线前检查清单

• OpenClaw 运行在独立 VPS 或 VM 上
• SSH 只允许密钥登录
• 防火墙默认拒绝入站
• 密钥不在仓库中
• Agent 只能访问指定目录
• 仅接入必要渠道
• MCP Server 默认只读
• 日志可审计

FAQ

OpenClaw 放在 VPS 上会更安全吗？

通常会。VPS 的边界更清晰，网络策略和文件范围也更容易收紧。

最大的安全错误是什么？

把 OpenClaw 跑在同时保存了主力 SSH 密钥、浏览器登录态和私人文件的日常电脑上。

来源与说明

• OpenClaw 的核心定位是自托管、多渠道的 AI Agent 运行环境。
• 延伸阅读：MCP 安全、私有 AI 云、多模型网关。