1. 项目拆解：OpenClaw（Clawdbot）为什么要跑在云端
OpenClaw（很多人叫它 Clawdbot）本质上是一个自动化智能体框架，你可以把它理解成一个“带爪子的机器人管家”：它负责监听消息、读取任务、调用各种 API 和工具，最终替你完成一系列自动化操作。Clawdbot 则是这套框架的服务端形态，通常以守护进程的方式常驻运行，等待外部请求进来，再按配置好的规则去执行动作。
我第一次部署的时候也纠结过：为什么不能直接跑在自己电脑上？能跑，但问题很明显。本地机器关机、断网、睡眠，服务就没了；家里宽带没有固定公网 IP，外部要回调你的服务非常麻烦；一旦你人在外面，想远程看一眼运行状态，还要先解决内网访问的问题。把 OpenClaw 放到云服务器上，等于给这个机器人找一个 7×24 小时不休息的“工位”，只要云厂商不宕机，它就一直在线。
选择京东云，主要是三个理由：一是对新手的计费方式比较友好，按量付费和包年包月可以随时切换，不用一上来就买一大坨资源；二是控制台的中文界面和指引做得比较清楚，SSH 密钥、安全组、防火墙这些概念都有可视化入口，对没接触过云服务器的人很友好；三是它的公网 IP 带宽对小流量应用来说够用，OpenClaw 这种机器人进程本身对带宽要求不高，真正吃资源的是它调用的模型推理服务和日志存储。
这个项目适合谁？适合第一次接触“把应用部署到云服务器”的新手，也适合已经能本地跑通 OpenClaw、但需要把它搬到公网做长期服务的人。这篇操作步骤会从买服务器开始，一直讲到日志排查，尽量让你少走我踩过的那些坑。全文基于我在京东云 Linux 实例上的实测流程整理，不同版本的 OpenClaw 镜像可能路径略有差异，但核心思路是一致的。
2. 部署前的准备：云服务器、安全组与远程连接
2.1 选配置：轻量应用服务器还是云主机？
京东云上常见的选择有两类：一类是“轻量应用服务器”，面板集成度高，适合个人项目；另一类是“云主机 CVM”，网络和磁盘可以更精细地调整。OpenClaw 这种应用，我建议优先选轻量应用服务器，原因很简单：它的镜像市场里通常自带 Docker、Ubuntu 等常用环境，能省去早期初始化的一堆命令。
配置方面，我的经验是“起步 2 核 4G”，磁盘 40G 起步。别看 OpenClaw 本身编译后可能就几百 MB，但它运行过程中要拉模型元数据、写日志、缓存临时文件，时间长了磁盘很容易被日志塞满。如果你还打算在同一台服务器上跑本地大语言模型（比如 Ollama），那内存最好直接 8G 以上，否则模型推理会把进程直接挤爆。
地域选择上，国内地域（北京、上海、广州）延迟低，但如果你只是拿来做自动化任务，对延迟不敏感，选哪都行。我更推荐离你日常管理时段近的地域，或者直接选当前有活动折扣的地域，省下来的钱可以拿来升带宽。
2.2 安全组：这一步不做，后面什么都连不上
新手最容易卡住的第一关不是装系统，而是“服务器买了，SSH 连不上”。京东云控制台里，新实例默认会给你配一个安全组，但默认规则往往只放行了部分端口。你需要在控制台找到“安全组”页面，确认以下几条规则：
| 方向 | 协议 | 端口 | 来源 | 用途 |
|---|---|---|---|---|
| 入方向 | TCP | 22 | 你的本地 IP 或 0.0.0.0/0 | SSH 远程登录 |
| 入方向 | TCP | 80 | 0.0.0.0/0 | HTTP 访问 |
| 入方向 | TCP | 443 | 0.0.0.0/0 | HTTPS 访问 |
| 入方向 | TCP | 8080 | 0.0.0.0/0 | OpenClaw 默认 Web 管理端口 |
提示：如果只是自己调试，来源 IP 建议写你当前网络的公网 IP，别图省事直接写 0.0.0.0/0，否则服务器会被扫描工具盯上，天天有人尝试爆破 SSH。
我见过太多人折腾了半天，最后发现是安全组没放行 22 端口。这个很基础，但真的很坑。改完安全组规则后，规则一般几秒内生效，不用重启机器。
2.3 SSH 连接工具与基础环境检查
Windows 用户我建议直接用系统自带的 PowerShell 或者 Windows Terminal，输入ssh root@你的公网IP就能连；macOS 用户直接打开终端。不熟悉命令行的也可以用 Xshell、FinalShell 这类带图形界面的工具，上传文件、看日志会更直观。
连上之后，先跑一遍环境检查，确认系统是什么版本、有没有装 Docker：
cat /etc/os-release uname -a which docker || echo "docker not installed" which git || echo "git not installed"如果是 Ubuntu 22.04 或 Debian 12，后面步骤最顺。如果是 CentOS，命令里apt要对应改成yum或dnf，Docker 安装方式也不同。我的建议是：新手直接选 Ubuntu 镜像，别给自己添乱。
3. 实操步骤：从零把 OpenClaw 装到京东云
3.1 更新系统与安装基础依赖
登录后第一件事，把系统包索引更新一遍，然后安装编译工具和常用依赖。这个步骤不是走形式，OpenClaw 的安装脚本会检查git、curl、python3这些基础组件，缺了会直接中断。
sudo apt update && sudo apt upgrade -y sudo apt install -y git curl wget python3 python3-pip python3-venv build-essentialPython 版本建议 3.10 以上。怎么确认？python3 --version，如果版本太低，后续装 Python 依赖时会报 “requires Python >= 3.10” 之类的错误。别用系统自带的旧版硬扛，可以直接加 deadsnakes PPA 装新版本，但这属于进阶操作，新手建议直接选预装高版本 Python 的系统镜像。
Docker 的部分我单独拿出来说，因为 OpenClaw 官方现在最省事的部署方式就是跑容器。用 Docker 的好处是依赖隔离，你本地再怎么折腾 Python 环境，容器里都是干净的一层。安装 Docker 的推荐方式是用官方脚本：
curl -fsSL https://get.docker.com | sudo sh sudo systemctl enable --now docker docker --version脚本执行完会自动把 Docker 服务拉起来，并设置开机自启。如果 Docker Hub 拉镜像很慢，需要配置国内镜像加速器，在/etc/docker/daemon.json里加 registry-mirrors 配置，然后重启 Docker。这一步不是必须的，但实测下来对拉取速度的提升非常明显。
3.2 拉取 OpenClaw 项目与镜像
基础环境就绪后，开始拉项目文件。我习惯把服务放在/opt/openclaw目录下，而不是 root 家目录，这样目录职责清晰，后续升级、备份都不容易误伤。
sudo mkdir -p /opt/openclaw cd /opt/openclaw sudo git clone https://github.com/openclaw/openclaw.git .如果你拿到的不是源码，而是一个现成项目包，直接解压到/opt/openclaw也行。关键是确认目录里有docker-compose.yml或Dockerfile，这是后面启动的依据。
如果官方提供镜像，也可以跳过源码克隆，直接拉镜像。判断办法是看项目文档里有没有docker pull的命令。以 Docker Compose 部署为例，项目里通常会自带编排文件，包含数据库、缓存、应用服务三个容器。为什么 OpenClaw 要连带数据库一起跑？因为它需要存储任务记录、对话历史、配置状态，用 SQLite 或 PostgreSQL 都行，但容器化之后统一由 Compose 管理最省心。
3.3 编写 OpenClaw 配置文件
部署 OpenClaw 最核心的部分是配置文件。通常是一个config.yaml或.env文件，里面定义了机器人监听端口、日志级别、后台任务开关、以及你要接入的模型 API。不同版本的字段名可能不一样，但整体逻辑大同小异。
我提供一个经过本地验证的通用配置示例（具体字段以你下载到的那版文档为准）：
server: host: 0.0.0.0 port: 8080 debug: false log: level: info dir: /var/log/openclaw storage: type: sqlite path: /opt/openclaw/data/openclaw.db model: provider: openai-compatible base_url: http://127.0.0.1:11434/v1 api_key: dummy model_name: qwen2.5:7b这里的0.0.0.0是重点：如果你是给外部提供 Web 管理界面或 API 回调，监听地址必须写成0.0.0.0，不能写127.0.0.1，否则外部请求进不来。端口要和安全组放行的端口对应，我用的是 8080。
模型接入部分，OpenClaw 本身不生产算力，它需要一个“大脑”。你可以选择云厂商的模型 API，也可以指向自己部署的本地大模型服务（比如 Ollama）。如果只想体验流程，先用公共 API 是最快的；想追求私密性和长期零 API 费用，在同一台服务器上装 Ollama 更合适。我这个示例就指向了本机的 Ollama 服务。
写配置文件的时候权限也要注意。config.yaml如果包含 API Key、Token 之类的东西，记得把文件权限改成只有 root 可读：
sudo chmod 600 /opt/openclaw/config.yaml很多人忽略这一步，结果配置文件里躺着明文密钥，服务器被入侵后直接泄露。这不是危言耸听，云服务器上每分钟都有扫描器在找暴露的配置文件。
3.4 启动 OpenClaw 并用 systemd 守护
配置写好后，启动容器。如果项目带 Docker Compose 文件，命令是：
cd /opt/openclaw sudo docker compose up -d如果项目只提供一个 Dockerfile，你需要先自己构建镜像：
sudo docker build -t openclaw:latest . sudo docker run -d --name openclaw \ -p 8080:8080 \ -v /opt/openclaw/data:/opt/openclaw/data \ -v /opt/openclaw/config.yaml:/app/config.yaml \ --restart unless-stopped \ openclaw:latest为什么不直接用docker run一把梭跑完？因为容器进程会跟着 Docker 服务走，但 Docker 服务本身在系统重启后不一定自动恢复。所以更稳妥的做法是写一个 systemd 服务单元，让系统管 Docker，让 Docker 管 OpenClaw，层层守护。
创建/etc/systemd/system/openclaw.service：
[Unit] Description=OpenClaw Service Requires=docker.service After=docker.service network-online.target [Service] ExecStart=/usr/bin/docker start -a openclaw ExecStop=/usr/bin/docker stop openclaw Restart=always RestartSec=10 [Install] WantedBy=multi-user.target然后执行：
sudo systemctl daemon-reload sudo systemctl enable openclaw sudo systemctl start openclaw这个服务单元的意义在于：只要服务器开机，Docker 就启动，Docker 启动后自动拉起 OpenClaw 容器；万一进程崩溃，Restart=always会让它 10 秒后自动重启。省去了你半夜被报警消息吵醒的烦恼。
启动后过十几秒，查看容器状态：
sudo docker ps sudo docker logs --tail 100 openclaw看到类似started、listening on 0.0.0.0:8080的输出，就说明起来了。此时在浏览器访问http://你的公网IP:8080，应该能看到管理界面或健康检查响应。
3.5 配置域名与 HTTPS 证书自动续期
直接拿 IP 加端口访问能用，但不安全、也不好看。我给 OpenClaw 配了一个域名，然后用 Caddy 自动申请 HTTPS 证书。为什么不手写 Nginx + Certbot？因为 Caddy 会把“监听 443、申请证书、自动续期、反向代理到后端 8080”这几件事全部自动做完，对新手极其友好。
假设你的域名是bot.example.com，安装 Caddy 后写一个Caddyfile：
bot.example.com { reverse_proxy 127.0.0.1:8080 }然后重启 Caddy。首次访问时，Caddy 会自动申请证书并配置 HTTPS，后续证书快到期时它会自动续期，不需要你手动跑任何 cron 任务。这里提醒一句：域名解析记录要先做好，A 记录指向服务器公网 IP，等 DNS 生效后再启动 Caddy，否则证书申请会失败。
有朋友问我为什么不用自签名证书，我的回答是：浏览器会警告，外部服务对接也麻烦。能自动申请免费证书，就别自找麻烦。
4. 部署之后的常态化运维：验证、日志、升级与卸载
4.1 健康检查：判断“活着”和“健康”是两回事
很多新手看到容器在跑就以为万事大吉，其实“进程活着”和“服务健康”是两码事。我习惯用三个层面做检查：第一层看端口是否有响应，第二层看进程有没有报错，第三层看业务功能能不能跑通。
先看端口：
sudo ss -tlnp | grep 8080然后看容器内进程：
sudo docker exec openclaw ps aux再看日志里有没有周期性异常。最直接的功能验证是调一次健康检查接口，或者让机器人执行一个最简单的测试任务，确认模型调用链路是通的。这一步很关键，因为模型 API 经常出现密钥过期、额度耗尽、模型名称写错这类事，而这些问题在容器启动初期不一定暴露。
4.2 日志管理：不要等到磁盘满了才想起来看日志
OpenClaw 跑久了，日志文件会越来越大。容器里进程直接往 stdout 写日志的话，默认会被 Docker 的 json-file 驱动接管，积攒到一定程度会占满磁盘。我建议在 Docker 配置里加上日志轮转，修改/etc/docker/daemon.json：
{ "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "5" } }改完重启 Docker，新容器的日志会被限制在 250MB 以内。如果是已经跑起来的容器，需要重建才会生效，或者直接用 systemd 的journalctl限制方式。日常排查日志，用这两条命令就够：
journalctl -u openclaw -f sudo docker logs --tail 200 openclaw4.3 升级 OpenClaw：别盲目拉最新镜像
OpenClaw 迭代速度很快，新功能往往靠升级获得，但升级也是翻车高发区。我的流程是：先备份数据目录，再拉新代码、重新构建镜像、跑测试任务，最后才切流量。
sudo cp -r /opt/openclaw/data /opt/openclaw/data.bak.$(date +%Y%m%d) cd /opt/openclaw sudo git pull sudo docker compose up -d --build如果是用docker run方式，则需要先停旧容器、删掉旧容器、再用新镜像启动。注意：docker compose up -d会检测到配置变化自动重建容器，但数据卷里的数据库文件不会丢，前提是你没有把数据写到容器可写层里。把数据放到宿主机的挂载目录，是升级不出事的前提。
4.4 卸载 OpenClaw：走干净，不留垃圾
卸载也是有不少人问的。虽然标题是部署，但我还是把卸载一起说了。如果是 Compose 部署的：
cd /opt/openclaw sudo docker compose down sudo rm -rf /opt/openclaw sudo systemctl disable openclaw sudo rm /etc/systemd/system/openclaw.service sudo systemctl daemon-reload如果是docker run方式：
sudo docker stop openclaw sudo docker rm openclaw sudo docker rmi openclaw:latest注意一点：docker compose down默认不会删数据卷，所以如果你确定不再使用，要手动删掉命名卷或宿主机目录。要不要留数据，取决于你是否打算以后恢复。我通常建议保留至少一周再清，免得后悔。
5. 常见问题排查与实测避坑
5.1 高频错误与解决办法速查
下面这组问题是我在部署和帮朋友排查时遇到频率最高的，按症状列出来方便对照。
| 症状 | 可能原因 | 解决办法 |
|---|---|---|
| SSH 连不上 | 安全组未放行 22 端口 | 去京东云控制台加规则 |
| 容器一直重启 | 配置文件字段名错误 | docker logs看报错，对照版本文档 |
| 8080 端口无法访问 | 安全组没放行 / 监听地址写成了 127.0.0.1 | 改配置为 0.0.0.0，放行端口 |
| 启动报磁盘不足 | 日志占满磁盘 | 清理/var/lib/docker，加日志轮转 |
| 模型请求超时 | API 地址写错 / 本地模型加载慢 | 先用 curl 测base_url，看返回 |
| 升级后功能异常 | 数据迁移失败或依赖不兼容 | 回滚到备份，等下一个稳定版本再升 |
我在 JD cloud 上最常碰到的是第一项和第三项，全都是配置层面的低级错误，但排查起来确实让人头疼。建议部署前先画一个简单的访问链路图：浏览器 → 域名 → Caddy/443 → OpenClaw/8080 → 模型服务。链路哪一段断了，就去查哪一段，思路会清晰很多。
5.2 内存与算力规划：OpenClaw 能只用 API 算力吗
很多人的疑问是“OpenClaw 是不是必须接一个大型模型 API 才有意义”。答案是否定的。OpenClaw 本身只是一个控制框架，它需要“算力来源”，但来源可以是远程 API，也可以是本地模型。如果你只是为了跑通流程，接公共 API 最快；如果你想完全不依赖外部服务，在同一台云服务器上装 Ollama，然后拉一个 7B 或 14B 模型，OpenClaw 的base_url指向本地端口即可。
注意，本地模型很吃内存。7B 模型量化版大约需要 6~8G 内存，14B 模型需要 14G 以上。如果你买的是 2 核 4G 的服务器，老老实实用外部 API 更实际，不要强行上本地模型。我自己的方案是：京东云服务器管 OpenClaw 和消息收发，模型推理放在另外一台高内存机器上，用内网地址通信。这样做的好处是互不干扰，模型升级不会影响 OpenClaw 稳定性。
5.3 数据备份：最简单但最容易被忽略的事
部署完成后，OpenClaw 的记录都存储在数据库里。我经历过一次误删数据卷，虽然任务配置还能重新写，但历史记录全没了，那种感觉真的很难受。现在我的备份策略是每天凌晨用 cron 打包数据目录，保留最近 7 份。
#!/bin/bash BACKUP_DIR=/opt/backups TIMESTAMP=$(date +%Y%m%d-%H%M%S) tar czf "$BACKUP_DIR/openclaw-$TIMESTAMP.tar.gz" -C /opt/openclaw data config.yaml find "$BACKUP_DIR" -name "openclaw-*.tar.gz" -mtime +7 -delete把脚本存为/opt/backup-openclaw.sh并加执行权限，然后用crontab -e加一行：
0 3 * * * /opt/backup-openclaw.sh恢复也很简单，解压后覆盖回原目录、重启容器即可。这个习惯在某个深夜救过我一次，从那以后我再也不嫌备份麻烦。
5.4 安全加固：云服务器上别裸奔
OpenClaw 部署到公网后，你面对的不只是正常用户，还有大量自动扫描机器人。我的做法有三条：第一，SSH 禁止 root 密码登录，改用密钥登录；第二，让 OpenClaw 跑在独立用户下，而不是 root；第三，配置只放行必要的端口，其他全部关闭。像 22 端口我甚至会限制来源 IP，只允许自己常用的出口 IP 访问。
有人觉得这些操作太繁琐，但真实情况是：只要服务器有公网 IP，扫描是必然的。与其等到被攻破再补救，不如一开始就花十分钟把安全基线打好。我自己在京东云上测过一台裸奔的测试机，挂出去不到 24 小时就有几百条失败登录记录，这不是段子，是常态。
6. 结尾：一些我自己的实操体会
最后分享一点个人感受。OpenClaw 部署本身不复杂，真正的复杂度在于“让它稳定地长期跑下去”。我第一次部署的时候，以为只要容器启动成功就结束了，结果栽在日志占满磁盘、安全组忘记放行、模型 API 地址写错这三个问题上，每一项都花了至少半小时排查。
如果你现在刚开始折腾，我建议按这个顺序来：先用 Docker 跑通，再配 systemd，再上路由和 HTTPS，最后再加模型和自动化任务。步子别迈太大。每一步都验证成功了再进下一步，回头排查时你才会知道问题出在哪一段。
一个小技巧：把你的操作命令记录成一个笔记，尤其是每次改动前后的配置文件差异。这能让你在升级回滚、问题定位时节省大量时间。很多人觉得记笔记没必要，但等你需要回退配置、或者隔了一个月再维护这套系统时，你会感激当时的自己。
这套部署方案在京东云上实测下来很稳，我自己的实例已经连续跑了三个月，除了升级时会手动重启，平时没再管过它。希望这篇流程也能帮你少踩几个坑。
