如果你手上有一台云服务器，正琢磨怎么部署一个稳定、可扩展的自动化任务服务，那 OpenClaw 值得看一眼。它不像传统 Cron 那样只能把命令写在系统配置里，而是把“什么时间触发”“执行什么任务”“结果往哪存”拆成了清晰的模块，配合 HTTP API 可以随时远程调度。这篇文章我就从零开始，把 OpenClaw 在云服务器上的完整安装过程过一遍，包括资源规划、依赖安装、源码编译、服务账户初始化、systemd 托管和反向代理接入。适合刚拿到云服务器的新手，也适合想把 OpenClaw 从容器迁移到裸机部署的老手。
在写命令之前，我先把几个容易踩坑的点放在前面：
OpenClaw 的官方仓库很多时候只维护源码，不提供预编译包，所以最通用、最可控的安装方式是从源码编译。这篇指南基于常见的 Linux 发行版展开，命令在 Ubuntu/Debian 系下可以直接复制运行，其他发行版把包管理器换成对应的即可。
1. 部署在云服务器前，先把资源账算清楚
很多人的第一个冲动是拿到服务器就直接敲安装命令，结果编译到一半进程被系统杀掉，或者服务跑起来之后磁盘被日志塞满。我建议先花五分钟把需求想清楚，这五分钟能省下后面一整天的折腾。
1.1 内存与磁盘如何估算
OpenClaw 本身是一个服务端程序，编译阶段和运行阶段的资源需求差别很大。
- 编译阶段：用默认的
make -j$(nproc)并行编译时，每路编译任务大概需要 150MB 到 300MB 内存。一台 2 核的云服务器如果并行编译 2 个任务，保守估计需要 1GB 以上可用内存，实际在 4GB 内存的机器上编译最从容。 - 运行阶段：服务启动后常驻内存约 200MB 到 500MB，具体取决于你配置的并发 worker 数和任务队列长度。如果你的任务里有大量文件处理或者 HTTP 请求，内存会随之上涨。
- 磁盘空间：源码目录、编译产物、运行日志三块加起来，预留 5GB 比较安全。其中编译产物大约占 1GB，日志默认路径在
/var/log/openclaw下，如果不做轮换，一个月下来可能涨到几个 GB。
我给的保守建议是：最低配置选 2 核 4GB 内存、40GB 磁盘的云服务器。如果你打算用 OpenClaw 同时跑定时任务和 Webhook 触发，这个配置在后端没问题。
1.2 网络端口与安全组规划
云服务器通常有一层安全组（或者叫防火墙规则），这层规则在系统防火墙之前生效。很多人只想着把服务端口打开，结果把 OpenClaw 的 API 端口直接暴露到公网，这是很危险的。
安全组规划原则只有一条：只暴露你真正需要暴露的端口。
OpenClaw 服务本身监听在内网地址（比如127.0.0.1），然后通过 Nginx 反向代理对外提供 HTTP/HTTPS 服务。因此安全组只需要开放：
| 端口 | 用途 | 建议开放范围 |
|---|---|---|
| 22 | SSH 管理 | 仅你的固定 IP，不要设为 0.0.0.0/0 |
| 80 | HTTP（可选，用于证书验证） | 0.0.0.0/0 |
| 443 | HTTPS 主入口 | 0.0.0.0/0 |
| 8024 | OpenClaw API（内部使用） | 不对公网开放，仅本机或内网 |
如果你在安全组里看到8024端口开着，说明你已经把自己暴露在风险里了。OpenClaw 的控制接口如果带 token 还好，但谁也不能保证 token 不会泄露。所以最好的方式就是让这个端口只在云服务器内部可见，外面的人根本摸不到。
2. 环境准备：一份不会再缺依赖的检查清单
环境准备是整个安装过程里最容易“缺胳膊少腿”的环节。OpenClaw 依赖的库比较多，少一个，编译到一半就会报错。我把检查清单按顺序写清楚，你照着执行就行。
2.1 系统更新与基础工具
以 Ubuntu 22.04 为例，先做系统更新和基础工具安装：
sudo apt update sudo apt upgrade -y sudo apt install -y build-essential cmake git curl pkg-config libssl-dev libyaml-dev每个包的作用我简单解释一下：
build-essential：包含 gcc、g++、make，是编译 C/C++ 程序的必需品。cmake：OpenClaw 使用 CMake 作为构建系统，必须安装。git：从仓库拉取源码。pkg-config：编译时查找依赖库的头文件和链接参数。libssl-dev：OpenClaw 的 HTTPS 支持依赖 OpenSSL。libyaml-dev：解析 YAML 配置文件时需要。
安装完成后检查一下核心工具版本：
gcc --version cmake --version make --version如果cmake版本低于 3.20，建议从 CMake 官方仓库安装新版本，否则 OpenClaw 的构建脚本可能直接拒绝执行。
2.2 为编译预留 Swap 空间
很多云服务器默认没有 Swap 分区，或者 Swap 很小。编译大项目时，如果内存不够，内核的 OOM Killer 会优先挑占用内存最多的进程杀掉，而cc1plus（g++ 的编译器进程）往往是最大受害者。
一个很实用的办法是临时创建一个 Swap 文件：
sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile你可以用free -h确认 Swap 是否生效。这 2GB 不需要一直保留，编译完了想删掉也完全没问题。只不过我一般会留着它，因为后续跑任务或者日志缓冲区偶尔也会用到。
如果你用的云服务器是 SSD 云盘，Swap 的读写性能足够支撑编译过程。但注意，不要在生产环境下依赖 Swap 来跑业务，它只是临时缓冲。
2.3 确认网络与时间同步
OpenClaw 的任务调度依赖系统时间，如果服务器时钟偏移太厉害，定时任务可能提前或延后执行。安装前执行一次：
sudo timedatectl set-ntp true timedatectl status确保NTP synchronized: yes。另外，云服务器的默认软件源有时候下载很慢，可以在安装依赖前换成离你较近的镜像源，但不是必须的，跳过也不影响安装。
3. 拉源码、编译、装好的完整命令行流程
环境准备好了，接下来进入正题。我会把每一步命令都写出来，并且告诉你每步大概会看到什么输出，方便你判断是否正常。
3.1 获取源码与切换版本
先建立一个/opt目录下的工作区：
cd /opt sudo git clone https://code.example.com/openclaw/openclaw.git注意，这个仓库地址只是示例，你实际操作时用 OpenClaw 官方公布的真实仓库地址。克隆完成后：
cd openclaw git tag -l这一步会列出所有发布版本。我建议你选一个带v前缀的稳定版本，比如v0.9.2，而不是直接编译默认分支的最近提交，因为主分支很可能处于开发中状态，功能不稳定。
git checkout v0.9.23.2 编译安装与常见输出解析
OpenClaw 的构建流程是标准的 CMake 流程：
mkdir -p build && cd build cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local make -j$(nproc)-j$(nproc)会让 make 使用所有 CPU 核心并行编译，速度最快。如果你只有 2 核且内存吃紧，可以改成make -j1，虽然慢，但不容易被 OOM 杀掉。
编译顺利的话，终端会滚动大量的[ xx%]进度信息，最后出现：
[100%] Built target openclaw然后执行安装：
sudo make install安装完成后验证：
openclaw --version如果能看到版本号，恭喜，编译安装这一步已经过了。如果提示command not found，多半是/usr/local/bin不在系统 PATH 中，执行一次export PATH=/usr/local/bin:$PATH临时解决，长期可以在~/.bashrc里追加。
3.3 编译期最常见的三个报错
我把实际编译中容易遇到的情况整理成一个速查表：
| 报错信息 | 原因 | 解决方案 |
|---|---|---|
fatal error: yaml.h: No such file or directory | 缺 libyaml 开发包 | sudo apt install libyaml-dev |
c++: fatal error: Killed signal terminated program cc1plus | 内存不足，编译器被 OOM 杀死 | 添加 Swap，并用make -j1降低并发 |
Could not find a package configuration file provided by "OpenSSL" | 缺 OpenSSL 开发包 | sudo apt install libssl-dev |
遇到这些不要慌，缺什么装什么。编译安装这种事，报错信息永远是第一线索。
4. 跑起来只是开始，配置文件和服务账户这样调
很多教程到“编译完”就结束了，但真正的运维难点全在配置和权限上。如果直接以 root 用户运行 OpenClaw，后续日志、数据目录、任务执行都会出现权限混淆。我们必须从一开始就把服务账户分好。
4.1 创建专用系统用户与目录结构
用一个无登录权限的系统用户来运行 OpenClaw：
sudo useradd --system --home /var/lib/openclaw --shell /usr/sbin/nologin openclaw创建三个目录，分别放配置、数据和日志：
sudo mkdir -p /etc/openclaw sudo mkdir -p /var/lib/openclaw sudo mkdir -p /var/log/openclaw sudo chown -R openclaw:openclaw /var/lib/openclaw /var/log/openclaw注意，/etc/openclaw可以把所有者设为 root，配置文件不应该允许运行用户随意修改。
4.2 生成 Token 并编写主配置文件
OpenClaw 的 HTTP API 通常需要一个 token 认证。用系统自带的 OpenSSL 生成一个足够长的随机串：
openssl rand -hex 32输出结果复制保存，待会写进配置。
创建一个最小可用的配置文件/etc/openclaw/openclaw.yml：
server: listen: 127.0.0.1 port: 8024 token: "替换成你生成的随机字符串" storage: path: /var/lib/openclaw max_size_mb: 1024 worker: concurrency: 2 timeout_seconds: 300 log: level: info file: /var/log/openclaw/openclaw.log max_size_mb: 100 max_backups: 5关键点逐一解释：
listen: 127.0.0.1：只监听本机回环地址。这是安全边界，外面的流量无法直接访问 API。port: 8024：默认端口。你可以改成任何未占用的端口。token：请求 API 时通过Authorization: Bearer <token>传递。storage.path：OpenClaw 存储任务状态和队列数据的位置，必须属于 openclaw 用户。worker.concurrency：同时执行的任务数。2 表示最多同时跑两个任务，太大容易把 2 核机器跑满。log.file：指向日志文件，并设置轮换参数。
4.3 为什么要监听回环地址，而不是监听 0.0.0.0
我遇到不少同学为了让外网直接访问，把listen改成了0.0.0.0。这样确实省了反向代理，但问题也来了：API 端口暴露在公网上，等于把控制大门敞开。一旦 token 被扫到，别人就能任意触发你的任务执行，云服务器很容易变成挖矿肉鸡。
正确的姿势是服务监听本机，由 Nginx 做一层 TLS 反向代理。这样外面只能看到 443 端口，OpenClaw 本身从网络层隔离。就算 Nginx 被攻破，攻击者也要先搞定本机的用户权限，安全等级完全不一样。
5. systemd 托管：开机自启和日志轮换一次搞定
直接用nohup openclaw serve &跑服务是最粗暴的方式，但云服务器重启后服务不会自动恢复，进程崩溃了也无人拉起。用 systemd 管理才是生产环境的标配。
5.1 服务单元文件编写
创建/etc/systemd/system/openclaw.service：
[Unit] Description=OpenClaw Automation Service After=network.target [Service] User=openclaw Group=openclaw ExecStart=/usr/local/bin/openclaw serve --config /etc/openclaw/openclaw.yml Restart=on-failure RestartSec=5 LimitNOFILE=65536 [Install] WantedBy=multi-user.target几个配置项的意义：
User/Group：指定运行账户，避免 root 权限。Restart=on-failure：进程崩溃后自动拉起，间隔 5 秒。LimitNOFILE=65536：提高文件描述符上限，防止任务产生大量并发连接时超过默认 1024 的限制。After=network.target：等网络就绪后再启动。
写入文件后重新加载 systemd：
sudo systemctl daemon-reload sudo systemctl enable --now openclawenable --now会同时完成开机自启和立即启动。查看运行状态：
sudo systemctl status openclaw输出中看到Active: active (running)就说明服务已经在跑了。
5.2 日志查看与 logrotate 配置
systemd 会把服务进程的标准输出和标准错误收进 journal，同时 OpenClaw 自己也会写日志文件。两种方式我一般都会用：
查看最新日志：
journalctl -u openclaw -f查看指定时间范围的日志：
journalctl -u openclaw --since "10 minutes ago"不过 journal 日志默认不持久化到硬盘，重启云服务器后旧日志可能会丢。所以配置里的log.file是主要的日志来源。为了不让这个文件无限增长，写一个 logrotate 配置/etc/logrotate.d/openclaw：
/var/log/openclaw/openclaw.log { daily rotate 7 compress missingok notifempty copytruncate }copytruncate很重要：复制日志内容并清空原文件，这样不用重启 OpenClaw 也能完成轮换。如果直接用rename方式，OpenClaw 还握着旧文件的 inode，日志会继续往旧文件写，导致磁盘空间不释放。
5.3 服务启动失败时的常规检查路径
如果systemctl status显示启动失败，不要慌，按顺序排查：
sudo systemctl status openclaw sudo journalctl -u openclaw -n 50 --no-pager通常会看到两类原因：一是配置文件语法错误，二是目录权限不对。配置文件检查可以用openclaw config check命令（具体看版本支持），目录权限则确认/var/lib/openclaw和/var/log/openclaw属主是否为 openclaw：
ls -ld /var/lib/openclaw /var/log/openclaw如果不是，执行之前的chown命令修复即可。
6. 安装完怎么验证，还有我踩过的四个坑
服务启动成功不等于万事大吉。我习惯按下面这套自检流程过一遍，确认 API 可用、代理转发正常，才敢说“安装完成”。
6.1 命令行自检清单
首先在本机测试 API 是否响应：
curl -H "Authorization: Bearer 你的token" http://127.0.0.1:8024/health正常情况下会返回类似{"status":"ok"}的 JSON。如果连接拒绝，检查服务是否在运行、端口是否被占用：
ss -lntp | grep 8024接着配置 Nginx 反向代理。创建一个站点配置/etc/nginx/sites-available/openclaw.conf：
server { listen 80; server_name your.domain.com; location / { proxy_pass http://127.0.0.1:8024; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }启用这个配置并重载 Nginx：
sudo ln -s /etc/nginx/sites-available/openclaw.conf /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx然后从你的本地电脑访问http://your.domain.com/health，确认能够通过域名访问到 API。
给域名加上 TLS 加密后，80 端口可以设一个 301 跳转到 443，Nginx 配置里用监听 443 的 server 块承接原来的 location 内容即可。证书申请我不展开，按你云服务商提供的免费证书流程走就行。
6.2 我踩过的四个坑，提前帮你排掉
第一个坑是编译时内存不足。我最早用的 1 核 2G 云服务器，运行make -j2直接 OOM。后来改成make -j1并加了 2G Swap，才顺利编译通过。所以如果你手头的机器比较丐，不要怀疑 OpenClaw 有问题，先降并发，再补 Swap。
第二个坑是 systemd 服务里指定了User=openclaw，但忘记给/var/lib/openclaw目录变更属主。服务启动后，OpenClaw 尝试写数据库文件时直接报Permission denied。这个坑在日志里看得很清楚，但如果你没设log.file，只能从 journal 里捞。
第三个坑是端口被占用。有一次我在同一台服务器上部署了两个实例，后一个一直启动失败。用ss -lntp一看，发现前一个实例还占着端口。如果你也想跑多实例，务必给每个实例分配不同的端口和数据目录。
第四个坑跟日志有关。我一度以为服务没在运行，因为日志文件一直不涨。结果发现配置里把log.level设成了error，而服务正常运行时的 info 级别日志全被过滤掉了。调试阶段建议先用debug级别，确认稳定后再调回info。
最后再分享一点实际使用中的体会
我在云服务器上反复部署过几次 OpenClaw 之后，最大的感受是：它的安装过程其实不难，难的是把服务边界收得干净、权限分得清楚。好的部署不追求一步到位，而是愿意花半小时把 systemd、日志轮换、反向代理都配好，后面才真正省心。
如果你只是临时调试，直接跑一个前台进程也没问题。但如果要用在生产环境，请一定把服务账户、监听地址和防火墙规则这些基本功做扎实。一台配置得当的云服务器，跑 OpenClaw 可以很久都不用再碰它。希望这篇指南能让你少走几趟弯路，装上之后，接下来的任务调度、API 接入就都是水到渠成的事了。
