折腾了两周，总算是把OpenClaw完完整整地从本地搬到了云服务器上。这个以单个配置文件驱动的AI代理运行时框架，能把多家模型服务商的API接入、会话管理、工具调用、对外接口这些能力收敛到一个极简的工程里，本地跑起来确实轻松，但当你真想让它在后台全天候待命，或者打算在任何地方随时连上去用的时候，本地部署的种种限制就全冒出来了。这篇内容就是一次完整的云上OpenClaw部署复盘，从买服务器到跑通HTTPS访问，覆盖选型、安装、配置、上线、排障全流程，适合有一定Linux基础、想把OpenClaw真正用起来的开发者参考。
1. 为什么非得把OpenClaw搬到云上
1.1 本地部署的三个绕不开的痛点
先说本地跑OpenClaw的体验。我在笔记本上部署的时候，核心流程其实几分钟就能跑通：拉代码、装依赖、填配置、起服务，然后就可以在终端里跟它对话了。但真正用起来之后，问题一个接一个地冒出来。
第一个痛点是开机问题。笔记本不可能24小时长开，合上盖子、系统休眠、断电，服务就断了。OpenClaw这种工具有一个特点，只有它持续在线，才能真正承担起“随时响应”的角色。你要是用它的API接口去做自动化任务，本地一断电，整个链路就瘫痪了。
第二个痛点是访问边界。本地服务默认绑定在127.0.0.1，就算改成0.0.0.0，也只是在局域网里可用。上班路上、出差在外，想拿出手机看一眼它跑的任务状态，基本没戏。要做内网穿透也不是不行，但多一个节点就多一份折腾，而且穿透服务的传输质量、限速策略都是额外变量。
第三个痛点是隔离性。本地环境往往装了一堆开发工具，Python版本混乱、Node版本冲突，OpenClaw的依赖安装偶尔会遇到各种诡异的环境问题。在一个干净的云服务器上，你能得到一个纯粹的运行环境，出问题也好排查。
1.2 云上部署到底带来了什么改变
把OpenClaw放到云上，本质上是从“玩具模式”切换到“工具模式”。
云服务器带来的第一个直接好处是常驻在线。一次配置好之后，服务会随系统自动拉起，不需要任何人去手工干预。第二个好处是访问方式变得干净。一个公网IP加一个域名，配上HTTPS，你在任何地方、用任何设备都能访问到同一个服务，数据、会话历史全部集中在一处。第三个好处是你开始考虑运维这件事了，日志怎么收集、数据怎么备份、版本怎么升级，这些在本地部署时完全不会想的问题，云上部署都会逼你梳理清楚。
这里给一张对比表，可以直观感受差别：
| 对比维度 | 本地部署 | 云上部署 |
|---|---|---|
| 在线时间 | 受本机开关机影响 | 7×24小时常驻 |
| 访问范围 | 仅本机或局域网 | 公网任意位置 |
| 运行环境 | 与开发环境混杂 | 干净独立可复现 |
| 数据安全 | 依赖本地硬盘 | 可做异地备份策略 |
| 故障恢复 | 无守护机制 | 进程守护自动拉起 |
| 升级维护 | 手动且随意 | 有规范可回溯 |
我自己最深的感受是：上云之后，OpenClaw从一个“偶尔想起来玩一下的玩具”，变成了一个真正可以托付任务的基础服务。这个心态转变比技术上的改变更重要。
2. 云服务器选型：照着这个配置买不会翻车
2.1 核心规格怎么定
先说结论：我用的是一台2核4G内存、40G SSD磁盘、5Mbps带宽的云服务器，系统选的Ubuntu 22.04 LTS。从实际运行情况看，这个配置对OpenClaw来说属于“宽裕但不浪费”的状态。
CPU方面，OpenClaw本身不是一个重计算应用，模型推理发生在服务商的API侧，本机主要承担的是请求编排、上下文管理、工具调用逻辑这三件事。但要注意，如果你同时挂着多个会话，或者让OpenClaw并行执行多个工具任务，CPU占用会明显上升。2核是底线，预算充足直接上4核也行，反正差价不大。
内存这里要重点说。OpenClaw的常驻内存占用主要来自三块：运行时本身的进程开销、每个活跃会话的上下文缓存、以及模型客户端的连接池。实测下来，新启动时内存占用在600M到800M之间，跑了一段时间、积累了几十个会话之后，轻松突破1.5G。如果开了Web可视化界面，这个数字还会再往上走。所以4G内存是真的有必要，别买2G的，省下来的钱还不够你折腾的。
磁盘40G看起来不大，但要注意OpenClaw的会话记录和日志是持续写入的。默认配置下，每条对话的原始请求和响应都会落盘，方便后续排查。我跑了半个月，数据量大概在2G左右。40G至少能撑一年以上，如果后续要挂载本地向量库、存文档附件，建议直接加一块数据盘。
带宽5Mbps够不够？得看使用方式。如果只是终端对话和API调用，流量小到可以忽略；如果要通过Web界面上传文件、查看大体积日志，5Mbps会显得略慢，但也不是不能忍。带宽是云服务器上最难事后升级不心疼的配置，建议一开始就买到位，免得后期排队等客服改配置。
2.2 系统镜像、安全组与网络规划
系统镜像我推荐Ubuntu 22.04 LTS，理由很实际：它的软件源里能直接装到较新版本的Node.js和Python生态，OpenClaw相关依赖大多优先针对Debian系测试，出了兼容性问题也最容易搜到解决方案。用CentOS属于给自己找不痛快，别干这种事。
买完服务器第一件事不是SSH登录，而是先配置安全组。安全组是云平台的网络访问控制层，默认情况下你需要在控制台里放行需要的端口。我建议最少放行三个：
- 22端口，用于SSH登录，但建议来源IP限定为你自己的常用出口IP
- 80和443端口，用于HTTP/HTTPS访问Web网关
- 一个自定义高位端口，留给OpenClaw的管理API，也不建议对全网开放，只对你自己的IP放行
网络规划上有个细节容易踩坑：很多云平台默认会给你分配一个公网IP和一个内网IP，绑定服务的时候要确认到底监听了哪个网卡。OpenClaw配置文件里的host如果写成127.0.0.1，公网IP是怎么也访问不到的，必须写成0.0.0.0才能让外部流量走进来。
2.3 域名与访问入口的前置准备
OpenClaw上云之后真正的访问入口应该是一个域名，而不是裸IP。原因有三：一是裸IP访问没法自动签发HTTPS证书，传输全程明文，会话数据里有API密钥的话风险极大；二是IP一旦更换，所有客户端配置都要跟着改；三是浏览器和终端工具对域名的兼容性远比IP好。
域名购买和解析这里不展开了，各主流域名服务商的操作都差不多。你需要做的就是把一个二级域名解析到云服务器的公网IP上，记录类型选A记录，TTL设短一点，比如300秒，方便后续迁移服务器时快速切换。
我建议在开始部署之前就把域名解析做好，因为DNS的生效需要几分钟到几十分钟不等，你不想在配置完HTTPS之后傻等域名生效。
3. 从零开始：云上安装OpenClaw完整实录
3.1 初始化环境：从裸机到可运行
登录到服务器之后，第一件事是更新系统软件源并安装基础工具链。
sudo apt update && sudo apt upgrade -y sudo apt install -y curl git unzip build-essential然后是安装运行时环境。OpenClaw依赖Node.js和Python两套运行时，分别承担前端界面与服务端调度的职责。Node.js建议直接装20 LTS版本，Python装3.11以上。我用的安装方式是这样：
# 安装Node.js 20 LTS curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs # 安装Python 3.11及虚拟环境工具 sudo apt install -y python3.11 python3.11-venv python3-pip装完之后用两个命令验证版本，node -v、python3 --version都能正常输出就说明环境就绪。这里有个细节：不要用Ubuntu自带的老版本Python，尤其是3.10以下的版本，OpenClaw的某些依赖要求3.11以上，版本不对会在安装依赖阶段直接报错。
3.2 获取项目与安装依赖
环境准备好之后，把OpenClaw项目拉到服务器上。我习惯放在/opt目录下，与用户家目录分离，权限更清晰。
cd /opt git clone https://某代码托管平台/OpenClaw/OpenClaw.git cd OpenClaw拉代码的时候建议直接切到最新的稳定发布标签，而不是用默认分支。发布分支可能处于开发状态，API和配置项随时会变，影响后续排查。查看可用版本标签：
git tag -l git checkout 最新稳定版本标签接下来安装依赖。OpenClaw的前后端依赖是分开管理的，后端用Python的pip安装，前端用npm安装。我实际操作时是分两步跑的：
# 后端依赖 python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt # 前端依赖与构建 npm install npm run build依赖安装阶段最容易出问题的是pip源和npm源的访问速度。如果在国内云服务器上安装明显偏慢，可以临时切换到公共镜像源，安装完再切回去。这里有个取舍：镜像源里的包版本可能滞后，如果安装后运行报缺模块，优先检查是不是安装的版本不匹配。
3.3 配置OpenClaw主文件：逐项拆解
OpenClaw的灵魂在于它的配置文件。默认情况下，项目在根目录下有一个示例配置文件，你把它复制成正式配置：
cp config.example.yaml config.yamlOpenClaw的配置分为几个关键区块：服务监听、模型服务商、密钥引用、会话存储、工具开关。下面是经过我反复调优之后一份可以直接上生产的最小配置：
server: host: 0.0.0.0 port: 8080 providers: default_provider: base_url: https://api.某模型服务商.com/v1 api_key_env: OPENCLAW_API_KEY_DEFAULT default_model: 你订阅的模型标识 timeout_seconds: 120 storage: type: local path: /var/lib/openclaw/data session: idle_timeout_minutes: 30 max_context_messages: 40 tools: enable_web_search: false enable_file_ops: false先说server区块。host写0.0.0.0的意义前面提过，让外部流量能进入服务。port选8080的原因很简单，1024以下端口需要root权限，而我不建议直接用root跑服务，所以高位端口是更实际的选择。
providers区块是整个配置文件的核心。OpenClaw允许同时配置多家模型服务商，启动时它会逐个探测可达性，并在运行时根据你的输入自动选择最优通道。base_url指向服务商的API端点，api_key_env是关键：这里的值不是你真实的密钥，而是一个环境变量的名字。这样设计的好处是，配置文件里没有任何明文密钥，即使config.yaml不小心泄露，也不会直接暴露凭据。
storage区块指定会话数据的落盘位置。我特意把数据目录从项目目录中移出来，放到/var/lib下，这是为了方便后面做备份和升级——升级代码的时候不需要动数据目录，备份数据的时候也不需要碰代码目录。
tools区块是OpenClaw的扩展能力开关。初次部署阶段建议全部关掉，先把基础对话链路跑通，再逐个开启并测试，否则工具启用之后出现调用异常，你很难判断是配置问题还是工具本身的问题。
3.4 初始化密钥与守护进程
配置文件里引用了环境变量OPENCLAW_API_KEY_DEFAULT，接下来就要把这个环境变量注入到服务运行的环境里。我采用的方法是创建一个专门的环境文件：
sudo mkdir -p /etc/openclaw sudo tee /etc/openclaw/openclaw.env > /dev/null <<EOF OPENCLAW_API_KEY_DEFAULT=你的真实密钥填在这里 EOF sudo chmod 600 /etc/openclaw/openclaw.envchmod 600这一步非常关键，确保只有root和指定的服务用户能读取这个文件。千万不要把这个环境文件放在项目目录里，也不要放进git仓库，一旦泄露，别人就能拿着你的密钥去刷API额度。
接下来是用pm2守护OpenClaw进程。pm2是一个Node.js生态里的进程管理工具，它做的事情很简单：启动服务、崩溃自动拉起、开机自启、日志管理。安装和启动命令如下：
sudo npm install -g pm2 cd /opt/OpenClaw source .venv/bin/activate pm2 start python3 --name openclaw -- app.py pm2 save pm2 startuppm2 startup命令会生成一个系统服务配置，让pm2随服务器开机自动启动，从而实现OpenClaw的常驻运行。pm2 save则把当前进程列表固化下来，重启后能自动恢复。
第一次启动后，通过pm2 logs openclaw查看日志，看到服务监听在0.0.0.0:8080的提示，就说明核心服务已经起来了。
3.5 自检清单
服务起来不等于部署完成，我每次部署新实例都会按一个清单做自检，顺序执行，绝不跳步：
1. 本机访问：curl http://127.0.0.1:8080/health 2. 公网访问：从本地电脑curl http://服务器公网IP:8080/health 3. 模型连通：通过OpenClaw发送一条测试消息，确认模型服务商返回正常 4. 会话持久化：重启服务后，用测试账号查询历史会话，确认数据已落盘 5. 进程守护：手动kill掉服务进程，等待10秒，确认pm2自动拉起这五步全部通过，OpenClaw在云上的基础运行才算真正合格。其中第5步特别重要，它直接验证了“常驻”这个承诺。我第一次部署时就是跳过这步，结果某天服务挂了几个小时才发现，教训深刻。
4. 远程接入、Web网关与日常维护
4.1 三种常用接入方式及适用场景
OpenClaw在云上跑起来后，接入方式就变成了一个需要规划的问题。我在实际使用中主要用到三种方式，按使用频率排序分别是：
终端命令行接入。这是我日常使用频率最高的方式。OpenClaw自带命令行交互模式，你通过SSH登录服务器后，直接进入项目目录，激活虚拟环境，运行交互命令就能进入对话界面。这种方式的好处是零额外配置，你不需要为它专门折腾什么客户端工具，它跟Linux环境天然是一体的。
API接口接入。OpenClaw启动时会暴露一组管理API，供外部程序调用。比如你写了一个定时脚本，每天上午九点自动触发一次OpenClaw去执行某个数据整理任务，走的就是这条路。调用之前需要在配置文件里开启API认证，并在客户端请求头里带上访问令牌，避免被未授权的请求刷接口。
Web可视化界面接入。这个就比较适合非开发者场景了。OpenClaw自带一套轻量的Web管理界面，支持在浏览器里查看会话记录、修改部分运行参数、查看日志。你不需要在手机上装任何App，只要能打开浏览器就能访问。不过我对公网暴露Web界面这件事一直比较谨慎，通常只在需要临时查看时才开启访问，平时保持关闭。
4.2 Web网关层：把HTTP流量安全地接进来
刚才提到服务监听在8080端口，但你不想让别人直接访问裸端口，也不应该让Web界面裸奔在HTTP下。这里我加了一个Web网关层，承担两件事：自动申请和续期HTTPS证书、把指定域名的HTTP流量转发到OpenClaw的8080端口。
网关软件我用的是社区里成熟的Web服务软件。安装之后，配置一个站点指向OpenClaw服务即可，核心配置如下：
server { listen 80; server_name openclaw.你的域名.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; } }这个配置解决的是“用户通过域名访问时，网关自动把流量交给OpenClaw”这件事。HTTPS证书方面，这款Web软件支持自动申请和续期，首次配置完成后就不用手工干预了。这里有一个安全细节：配置完成后，一定要在安全组里把8080端口的公网访问权限关掉，只保留80和443。这样一来，外部流量只能从加密的HTTPS入口进来，绕开网关直接访问裸端口的路径就被堵死了。
4.3 日志、备份与版本升级
运行维护里最重要的三件事，我在这一节一次说清楚。
日志方面，pm2把OpenClaw的标准输出和标准错误都收进了统一日志目录。查看实时日志用pm2 logs openclaw，查找历史记录去日志目录翻文件。我习惯把所有应用日志做一个按天切割，这样日志文件不会无限膨胀，排查问题时也容易定位到具体某一天的异常。如果你看到日志里有请求超时的报错，第一反应不要慌，先去确认对应时段模型服务商是否出现大范围故障。
备份方面，最核心的是配置文件和数据目录。我用crontab做了一个每天凌晨的全量备份计划：
0 3 * * * tar -czf /backups/openclaw-$(date +\%Y\%m\%d).tar.gz /etc/openclaw /var/lib/openclaw /opt/OpenClaw/config.yaml这个备份脚本把密钥环境文件、会话数据和主配置打成一个压缩包，保留30天内的历史备份。做备份不是在赌自己会出问题，而是为了在出问题时能从容应对。
版本升级方面，我的操作流程是固定的：先停服务，再备份数据目录，接着拉最新代码、安装新依赖、重新构建前端，最后启动服务并跑一遍自检清单。整个流程控制在20分钟内，其中真正的动手时间不到5分钟，其余都是等待命令执行。升级中最容易翻车的是依赖冲突，所以每次升级后都要用pm2 restart openclaw重启进程，并观察日志确认新版本正常加载。
5. 高频问题与避坑实录
5.1 问题速查表
以下这些问题全部是我在部署和运行OpenClaw过程中真实遇到的，整理成速查表，方便大家直接定位。
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 公网IP访问不了服务 | host配置成了127.0.0.1 | 改成0.0.0.0并重启服务 |
| 访问提示端口被拒绝 | 安全组未放行对应端口 | 到云平台控制台添加入方向规则 |
| HTTPS证书签发失败 | 域名解析未生效 | 确认A记录指向本机IP并等待TTL生效 |
| 首次对话请求超时 | 网络与模型服务商端点连通性差 | 先用curl手动测试端点，确认能连通再排查其他 |
| 服务内存持续增长 | 长时间运行积累大量会话缓存 | 调整空闲会话超时参数并定时重启 |
| 升级后功能异常 | 新旧版本配置项不兼容 | 对照新版示例配置逐项核对参数名 |
| 日志乱码缺行 | 时区或编码不一致 | 执行timedatectl set-timezone Asia/Shanghai |
这里面最隐蔽的坑是第一个：host配置。很多人看到“安全组放行了、服务也在运行、本机curl也通”，但公网就是访问不了，最后发现是配置文件里的host写成了127.0.0.1，外部流量永远到不了服务进程。排查这类问题，记住一个顺序：先确认进程监听地址，再用本机curl测，最后才从外部测。
5.2 几个特别值得说的心得
第一个心得关于密钥管理。我见过不少教程里直接把API密钥写进配置文件，然后附上“为了演示方便”这样的免责声明。这个习惯一定要改。密钥一旦通过配置文件泄露，被刷掉的可都是真金白银的额度。用环境变量文件加chmod 600保护，成本极低，收益极高。
第二个心得关于安全组的最小化放行。OpenClaw默认会暴露管理端口，如果你不管它，等于在公网上开了一扇门。我的做法是：能用域名访问的就不要开IP端口，能限定来源IP的就不对全网放行。即使是SSH的22端口，也建议把来源限定到你自己的固定IP，能挡住绝大多数扫描尝试。
第三个心得关于数据备份的粒度。备份不只是对pl数据文件打压缩包，还要包含配置文件和数据目录，密钥环境文件更要单独保管。我见过有人备份了所有代码，唯独丢了config文件，恢复的时候等于从零开始调参。
第四个心得是：不要在凌晨部署生产服务。这不是迷信，是我吃了两次亏之后总结出来的。凌晨是人最疲惫的时候，出问题之后大脑反应速度和白天完全不在一个水平线上。部署窗口选在上午十点左右，留出足够的排障时间，比什么都强。
我自己在OpenClaw上云这件事里最大的体会是：真正的门槛不在于装依赖、改配置这些具体步骤，而在于意识到“一个需要持续在线的服务，就必须用持续在线的运维方式来对待它”。你把它当玩具，它就只能提供玩具级别的可靠性；你把它当工具，它才会回报你工具级别的价值。代码里没有魔法，所有可靠性都是配置出来、测试出来、备份出来的。希望这篇指南能让你在部署OpenClaw的路上少踩几个我踩过的坑。
