脑袋被门夹得好痛折腾了三个晚上，总算是把OpenClaw在阿里云服务器上跑通了。如果你正准备做同样的事，这篇内容应该能帮你把这三个晚上省下来。
先交代一下背景。我在本地电脑上跑OpenClaw跑了差不多一个月，功能上确实爽，微信让它查天气、定时让它在早上八点把新闻汇总发过来、让它把某个网页内容抓下来整理成摘要，这些都能干。但本地跑的毛病也很具体：笔记本一合盖它就下线，有一次出差三天，回来发现它第二天就掉线了，微信里的消息全积压着没人处理。定时任务更不省心，凌晨三点电脑早就自己休眠了，任务根本没机会执行。
后来我下了决心，把它整体迁到阿里云服务器上。迁移完成之后，OpenClaw相当于有了一个全天不关机的家，微信24小时在线，skill随装随用，想跑定时任务也不用再担心电脑睡眠。这篇文章就围绕这个迁移过程来写：服务器怎么选、环境怎么初始化、OpenClaw怎么装、模型怎么接、微信怎么连、skill怎么配，以及这一路上我踩过的坑。适合本地跑得心累想迁上云的人，也适合第一次接触OpenClaw、准备一步到位直接部署在云服务器上的新手。
1. 为什么OpenClaw要放到云服务器上，而不是就在本地跑
1.1 本地跑的几个真实痛点
我先把本地跑的体验拆开讲。
第一是在线时长。OpenClaw这类AI Agent工具的核心价值是“随时等着替你干活”，所以它必须是一个常驻进程。本地电脑的睡眠策略、合盖动作、系统更新重启，任何一样都能让它离线。你可能觉得“那我设置永不睡眠不就行了”，但实际上笔记本高负载跑一晚上，风扇声音和发热都让人难受，电池也会加速老化。
第二是网络环境不稳定。家庭宽带很难保证长时间稳定在线，路由器偶尔重启、运营商凌晨做线路调整，都会导致掉线。OpenClaw的微信登录状态和会话信息都依赖进程持续在线，一旦断开重连，很可能要重新扫码，这体验就很糟。
第三是定时任务与远程触发的可靠性。OpenClaw的定时任务是在进程内部调度的，进程死了任务就没了。本地电脑关了机，你在外面想通过手机让它做点什么，更是无从谈起。
这些问题的本质是：OpenClaw需要一个可靠、常驻、可控的运行环境，而个人电脑设计上就不是干这个的。
1.2 云服务器上的运行链路长什么样
迁到云服务器之后，整体链路其实不复杂：手机微信发消息给机器人，消息通过微信服务转发到云服务器上的OpenClaw进程；OpenClaw收到消息，解析意图，调用对应的skill或触发对话模型；模型返回结果后，OpenClaw再通过微信回复。定时任务则由OpenClaw内部的调度器触发，不依赖任何本地设备在线。
在云上，关键优势有三个。第一是7x24在线，服务器只要不欠费就一直在跑。第二是网络入口稳定，云服务器有固定公网IP，进程主动连接外部的微信服务，不像家里宽带那样依赖入站端口。第三是扩展性强，OpenClaw里的Chrome容器自动化、视频剪辑这类重型skill，在云服务器上跑比在个人笔记本上跑更稳定，磁盘和内存都给得足。
1.3 为什么我选了阿里云：和京东云、飞牛NAS的对比
部署之前我做过一轮对比，网上问“京东云服务器OpenClaw怎么用”“飞牛OpenClaw怎么装”的人也不少，我把几个能实际用上的方案放在一起比较：
| 方案 | 价格门槛 | 上手难度 | 主要优势 | 适合场景 |
|---|---|---|---|---|
| 阿里云轻量应用服务器 | 有学生机/新用户活动，门槛低 | 低，控制台直观 | 文档全、镜像丰富、国内接入稳定 | 大多数人首选 |
| 京东云云服务器 | 也有入门级实例 | 低 | 偶尔有大促，价格有惊喜 | 赶上活动、想省一点的人 |
| 飞牛NAS（fnOS） | 需要有NAS硬件 | 中等 | 数据在自己存储上，顺带当NAS用 | 家里已有NAS、不想再买云主机的人 |
| 本地电脑/旧笔记本 | 几乎为零 | 低 | 零成本 | 只做体验、不需要7x24在线的人 |
我最后选了阿里云，主要不是因为它性能比别家强多少，而是我需要的几个条件它都满足：国内节点访问微信服务延迟低、安全组规则清晰、轻量应用服务器带的监控面板对小白友好，而且学生机/新用户活动确实便宜。
提一个建议：如果你已经有NAS或者愿意折腾硬件，飞牛部署OpenClaw也可行；但如果目标就是“最快速度得到一个稳定在线的Agent”，云服务器始终是成本最低的选择。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 阿里云服务器选型与开箱初始化
2.1 实例规格、地域和带宽怎么选
先给一个可以直接抄作业的配置方案：
- 实例类型：轻量应用服务器（2核4G），或ECS入门款
- 地域：选离你常用区域最近的，比如你在华东就用杭州节点，在华南就用深圳节点
- 系统盘：40GB起步，如果要跑Chrome容器、攒日志较多，建议60GB
- 带宽：按固定带宽买，3Mbps到5Mbps足够。OpenClaw本体是消息处理服务，真正吃带宽的是浏览器自动化下载网页资源的场景
我不建议买太低配（比如1核1G）。OpenClaw本体不重，但Node.js运行时、浏览器自动化容器、日志缓存加在一起，1G内存很容易触发OOM，进程被系统杀掉，表现就是“不知道为什么又掉线了”。2核4G是比较舒服的起点，也用不了多少钱。
另外，如果之后想在自己服务器上跑Ollama这类本地模型，就需要考虑GPU实例。那价格会贵不少，所以一般建议模型调用走API，只有确实想离线推理的时候再考虑上GPU。
2.2 系统镜像：为什么我选Ubuntu 22.04 LTS
系统镜像我直接选了Ubuntu 22.04 LTS。原因很直接：它对开源工具的兼容性最好，apt包管理器和社区文档都非常成熟，遇到问题搜索一下基本都有答案。网上搜“ubuntu2204 cuda openclaw”能搜出一堆案例，说明很多人就是在这个组合下跑通的，这个组合的坑已经被踩得差不多了。
顺带提醒一句，不要选已经停止维护的CentOS 7，也不要选生命周期太短的版本。LTS版本能保证你在未来几年内不会因为系统源失效而被迫迁移。
2.3 安全组端口放行
这是新手最容易漏的一步。服务器买完后，默认安全组可能只放行了22端口（SSH），如果你直接启动OpenClaw，从浏览器访问Web管理界面时你会发现怎么都连不上。
需要放行的端口大致有这么几个：
- 22（SSH，远程登录用）
- 80和443（如果有Webhook或日后绑域名用）
- OpenClaw Web管理界面端口（默认一般是3000，具体以部署版本为准）
放行的时候不要对公网全放开。我个人的习惯是：80/443和3000端口先对“所有IPv4地址”放开，因为要随时随地访问；22端口则尽量只放行自己的办公网IP，或者至少设置一个足够强的密钥登录。如果你觉得管理界面不想暴露在公网，也可以把OpenClaw的配置里的管理界面绑定到127.0.0.1，然后用SSH隧道访问，只是麻烦一些。
2.4 SSH登录后的第一轮系统配置
新服务器到手，别急着安装。先把基础打牢：
bash复制# 用密钥或密码登录后，先更新软件源
sudo apt update && sudo apt upgrade -y
# 查看当前系统版本
cat /etc/os-release
# 创建日常使用的用户，不用root直接干活
sudo adduser claw
sudo usermod -aG sudo claw
# 配置SSH密钥登录（可选但推荐）
ssh-copy-id claw@你的服务器IP
还要处理两个很隐蔽的问题。
一个是时区。OpenClaw的定时任务依赖系统时间，如果服务器默认是UTC时区，你设置“每天早上8点推送”会变成“北京时间下午4点推送”。如果你发现任务在“错误的16点”跑了，其实任务没问题，是时区没设置对。直接统一设置为北京时间：
bash复制sudo timedatectl set-timezone Asia/Shanghai
timedatectl status
另一个是系统时间同步。云服务器默认会带NTP客户端，但有些源不太稳定，建议手动确认一下。国内云环境下，阿里云也提供了内网NTP服务，如果你在VPC内，可以把chrony的时间源指向内网NTP地址，延迟更低也更稳：
bash复制sudo apt install -y chrony
sudo systemctl enable --now chrony
做完这些，服务器才算准备好了。接下来就是正式安装OpenClaw。
3. 安装OpenClaw：一键脚本和Git源码两条路线
3.1 环境依赖：先把Node.js、Git、Docker补齐
OpenClaw对环境的依赖主要就三样：Node.js、Git、Docker。Docker不是所有功能都需要，但如果你想用Chrome容器自动化这类高级skill，它就是必须的。
Node.js建议装20 LTS或更高版本：
bash复制# 用NodeSource的源安装（比apt默认源版本新）
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs
node -v
Git一般系统自带，没有就装一个：
bash复制sudo apt install -y git
Docker的安装，国内节点直接用官方脚本可能会比较慢，可以选清华镜像源或阿里云镜像源的方式安装。装完记得设置开机自启：
bash复制sudo systemctl enable docker
sudo systemctl start docker
sudo usermod -aG docker claw
这里有一个很容易踩的细节：加入docker组之后，要让当前用户重新登录一次才能免sudo执行docker命令。如果你接下来直接跑OpenClaw安装脚本，脚本内部如果要调docker，就可能报权限错误。解决办法就是重新ssh登录一次，或者执行一下newgrp docker。
3.2 姿势一：官方安装脚本，适合快速跑通
如果只是想把OpenClaw用起来，推荐直接用官方安装脚本。安装过程会自动检查前面那几个依赖、把核心文件放到默认目录、生成基础配置、启动服务。
bash复制# 从官方文档获取最新安装脚本路径，下载并执行
curl -fsSL https://openclaw.dev/install.sh -o install.sh
chmod +x install.sh
./install.sh
执行完之后，安装脚本一般会打印出Web管理界面的地址和管理员账号信息。如果没有打印，就根据安装时的输出确认端口和默认账号。
注意：命令行里的具体URL要以你从官方文档拿到的为准，不要随便在搜索引擎上点一个来路不明的脚本。安装脚本会以你的用户权限执行，来源不明意味着风险不可控。
3.3 姿势二：指定Git安装方式，从GitHub main分支检出源码
官方安装脚本提供的参数不止“默认安装”一种。你可以通过安装脚本指定git安装方式，让它从GitHub的main分支检出源码进行安装。这是被问得最多的一个点，拆开说一下。
为什么有人要这么装？三个原因：
第一，想要最新功能。OpenClaw迭代速度很快，release版本可能滞后于main分支，一些新skill、新插件只在main分支里有。第二，要做二次开发。如果你打算自己改代码、给官方提PR，那肯定得从源码跑。第三，方便跟进版本。源码目录就是一个git仓库，升级时git pull拉一下就能拿到最新代码，比二进制覆盖式更新更直观。
具体的做法大致是这样（以官方安装脚本的--git参数为例，参数名以你实际拿到的脚本版本为准）：
bash复制# 使用安装脚本并指定git安装方式，从main分支检出源码
./install.sh --install-method git --branch main
脚本会把OpenClaw的源码clone到指定目录，然后自动执行依赖安装和初始化。和默认安装最大的区别在于：所有文件都是源码形态，而不是打包过的产物。
选择这种方式需要承担一个代价：main分支是开发者日常提交的代码，偶尔出现一个小bug很正常。如果你追求稳定，还是用release版本更稳妥。我的做法是：生产环境用release，想要尝鲜的话在另外一台机器或另一个目录里拉main分支。
3.4 用pm2让OpenClaw常住后台
无论用哪种方式装好，下一步都是把OpenClaw作为常驻服务跑起来。最简单粗暴的方式是nohup，但我不推荐，进程退出后没人拉起来。用pm2会更专业：
bash复制sudo npm install -g pm2
# 假设openclaw的可执行命令是openclaw
pm2 start openclaw --name openclaw -- start
pm2 save
pm2 startup
pm2 save会把当前进程列表保存下来，pm2 startup则会在系统重启后自动拉起pm2和里面的进程。这样即使服务器意外重启，OpenClaw也能自动恢复。
检查运行状态：
bash复制pm2 status
pm2 logs openclaw --lines 100
看到online状态就说明服务正常。
4. 大脑接线：模型配置、模型切换与computer use设置
4.1 大模型接入：先弄懂OpenClaw的模型配置结构
OpenClaw本身不内置大模型的“脑子”，它做的事情是对接模型、对接工具、执行流程。你需要把自己使用的模型API信息填进去。默认安装之后会有一个默认模型设置项，通常要填三样东西：API地址（Base URL）、API Key、模型名称。
如果你是跟着Web管理界面配置，一般会有一个“模型”或“Provider”设置页，可以添加多个模型通道。如果是改配置文件，一般会有一个yaml或json格式的文件来管理，字段大致是这样：
yaml复制models:
primary:
provider: openai
api_key: sk-xxx
model: gpt-4o
这里不把参数写死，因为OpenClaw支持的Provider一直在变。你只需要抓住一个核心逻辑：所有大模型服务商，本质上都是给你一个Base URL + API Key + 模型名，把这三个填对，OpenClaw就能用上它。
4.2 硅基流动这类API渠道的配置方法
刚看到热搜词里有“openclaw 硅基流动”，我猜大家是想用国内的模型API渠道。以硅基流动为例，它的API兼容OpenAI格式，OpenClaw里通常选择“OpenAI-compatible”这类Provider类型就能接入。
配置思路：
- Base URL：填写硅基流动提供的API地址，一般是
https://api.siliconflow.cn/v1（以官方文档为准） - API Key：到硅基流动控制台生成
- 模型名：选择你开通的模型，例如Qwen系列、DeepSeek系列等
配置完成之后，回到对话通道测试一句话，比如“你好，请用一句话介绍你自己”，观察返回是否正常。
这里多说一句：国内API渠道和海外API渠道在OpenClaw里的接入逻辑是一样的，区别只在于网络延迟和账号体系。如果你的OpenClaw部署在国内服务器，调用国内API渠道的延迟通常比调用海外API低很多，这是国内服务器部署的一个额外优势。
4.3 接本地Ollama：把模型跑在自己服务器上
有些人想完全离线使用，或者对数据隐私有要求，就会接Ollama。方法也不难：
- 在服务器上安装Ollama，拉取一个模型，比如
qwen2.5:7b - 启动Ollama服务：
bash复制
ollama pull qwen2.5:7b ollama serve - 在OpenClaw的模型配置里增加一个本地Ollama通道：
- Base URL：
http://127.0.0.1:11434 - 模型名：
qwen2.5:7b - API Key：本地Ollama一般不需要密钥，填一个占位符或留空
- Base URL：
- 把默认模型切到Ollama，测试对话。
必须提醒的是：用CPU跑Ollama很慢。7B级别的模型在纯CPU的云服务器上生成一个字可能要一两秒，体验比较难受。想顺畅使用本地模型，至少需要一块GPU。网上搜“ubuntu2204 cuda openclaw”就是这个场景，需要给Ubuntu 22.04装好NVIDIA驱动和CUDA，再让Ollama使用GPU推理。
这也是为什么大多数人的方案是“云服务器上用API模型，本地有显卡的机器再用Ollama”。
4.4 ccswitch：多模型之间的快速切换
热搜词里“openclaw ccswitch 切换模型”值得单独说一说。ccswitch是一个用于模型切换的skill或工具，它的价值在于：不同任务可以用不同模型，而不是所有请求都走同一个贵模型。
我的使用场景是这样的：日常简单问答、信息提取、摘要总结，用便宜的小模型；需要复杂推理、多步规划的任务，切到更强的大模型。手动去后台改配置很麻烦，ccswitch可以把切换动作变成一个对话指令：当我在微信里对OpenClaw说“切换到专业模型”，它就自动把当前会话使用的模型切过去。
配置ccswitch的时候，本质上配置的就是“每个档位对应哪个模型通道”。档位名字自己定，底层其实还是4.1节说的那三个要素：Base URL + API Key + 模型名。先把通道都接好，再在ccswitch里做映射，逻辑就很清晰了。
4.5 computer use（cau computer）设置
最后一个热搜词是“openclaw的cau computer如何设置”。这里的cau就是computer use的简称，意思是让OpenClaw获得操作计算机的能力，比如打开浏览器、点击页面、读取屏幕内容。
这个功能需要浏览器自动化环境。OpenClaw常见做法是准备一个容器化的Chrome（或Chromium），让OpenClaw通过调试端口控制它。设置的核心就是两个：浏览器环境准备和权限配置。
先拉一个带远程调试的浏览器镜像：
bash复制docker run -d --name chrome --network=host \
-e CHROME_REMOTE_DEBUGGING_PORT=9222 \
chromedp/headless-shell:latest
这里镜像名只是示例，实际镜像请以OpenClaw官方文档推荐的为准。不同版本对浏览器调试协议版本有要求，用错版本会出现“能启动但控制不了”的诡异问题。
然后在OpenClaw的computer use设置里，把浏览器连接地址填成http://127.0.0.1:9222，设置好操作白名单（允许访问哪些域名、拒绝哪些操作），保存后测试一个真实任务，比如“打开百度首页，搜索OpenClaw，把第一条结果的标题告诉我”。
computer use的强大之处在于它让Agent真正“动手”而不是只“动嘴”，但安全上要格外谨慎。不要给高权限，不要让机器人以管理员身份运行浏览器，更不要在配置里保存任何敏感站点的密码。
5. 微信插件实战：从扫码登录到稳定不掉线
5.1 接入流程
在OpenClaw里启用微信通道，一般流程是这样：
- 安装/启用微信插件（不同发行版插件管理入口不同，一般在Web管理界面或命令行）
- 启动后，插件会生成一个登录二维码
- 用手机微信扫一扫
- 手机上确认登录
- 看到“登录成功”日志，就完成了
为什么会有二维码？因为个人微信没有面向开发者的开放API，OpenClaw这类工具走的是个人微信的自动登录路径，扫码是唯一合理的授权方式。
登录成功后，建议先给机器人发一条普通消息测试。如果收到回复，说明微信通道通了，模型也通了；如果没有回复，按照后面的思路排查。
5.2 二维码图片加载不出来，卡在登录第一步怎么办
我遇到过的还有一种情况：不是扫了不通过，而是二维码图片根本显示不出来，Web管理界面里是一片空白或者一张裂图。
排查链路：
- 先看浏览器开发者工具的Network面板，请求二维码接口有没有报错。报500说明后端问题，报超时说明网络链路问题。
- 看服务日志，二维码接口出错常见原因是临时目录没有写入权限，或者图片服务依赖的本地端口没起来。
- 确认访问Web界面用的是服务器IP还是绑定的域名，如果用了HTTPS反向代理，可能有协议混用导致图片请求被浏览器拦掉。
一个很保险的临时办法：直接在服务器上查看二维码内容，在命令行里用ASCII方式打印二维码，用手机扫这个。这个方法救过我好几次，在Web界面抽风但服务正常的时候，命令行永远是最后一根救命稻草。如果你的环境里有qrencode，思路就是读取二维码内容的文本，再用qrencode -t ANSIUTF8渲染到终端。
5.3 消息不回复：从日志到进程的完整排查链路
微信接入最让人头疼的问题就是：扫码都成功了，但过了一阵子发现发消息不回复。
先说结论：这类问题的排查顺序应该是“收没收到、回没回、卡在哪、被谁拦”。
第一步，看日志。OpenClaw的日志里能看到微信消息的收发记录。如果日志里根本没有收到消息的痕迹，说明消息根本没进到OpenClaw进程里，问题出在微信侧的连接状态，通常需要重启微信插件或者重新登录。
第二步，确认进程状态。用pm2看进程是否还活着。如果进程没了，大概率是OOM或者异常退出，去翻系统日志：
bash复制sudo journalctl -u pm2-openclaw --since "1 hour ago"
dmesg | grep -i oom
第三步，排查会话残留。如果日志里有“会话残留”“session conflict”之类的提示，说明上一次登录的会话没被正确清理，影响了新的登录状态。解决办法是把微信插件进程完整停掉，清掉缓存目录里的会话数据，再重新启动、重新扫码。
第四步，注意消息频率。个人微信通道的逻辑里，短时间内高频消息会被服务端视为异常，表现为消息发出去但机器人没有任何反应，这就是常说的“触发了服务端风控或会话残留”的常见场景。遇到这种情况，先停止高频消息，等一段时间再测试。另外检查你的OpenClaw里有没有循环任务在自动发消息，如果有，把频率调到正常范围。
这里必须说清楚：任何自动化工具使用个人微信通道都存在一定的服务端限制风险，这是客观机制，不是哪个产品能绕开的。使用的时候遵守合理频率、不发送违规内容、保持账号正常活跃状态，能大幅降低这类问题的概率。
5.4 让微信通道更稳定的几个习惯
再分享几个我实践中觉得有用的点：
- 保持同一IP：云服务器IP是固定的，这本身就是稳定因素。不要频繁切换服务器地域，频繁跨地登录很容易被识别为异地登录。
- 避免多处同时登录：OpenClaw进程在云服务器上跑，手机上就不要再用同号登录微信网页版之类的入口，避免会话互相挤掉。
- 定期重启：长时间运行的进程会有内存碎片或连接老化的问题，我一般每周重启一次OpenClaw，让微信连接重新建立。用pm2的定时重启可以做到：
bash复制这行配置让OpenClaw每天凌晨4点自动重启一次，非常省心。pm2 restart openclaw --cron-restart "0 4 * * *"
6. Skill生态、Chrome容器与版本升级
6.1 Skill怎么装
OpenClaw的技能体系是它的灵魂。没有skill它只是个对话机器人，装上skill它才变成一个能干活的Agent。
装skill的方式主要有三种：
- 在Web管理界面里的skill市场浏览、搜索、一键安装。
- 命令行安装：
bash复制
openclaw skill install 技能名 - 手动放置：把下载或自己写的skill目录放到指定的skills目录，然后重启进程。
第三种方式适合自己写skill。你会看到skill本质上就是一个包含配置和脚本的目录，里面定义了触发条件、执行逻辑、依赖的工具。只要格式正确，重启之后OpenClaw就能识别。
6.2 值得一试的Skill推荐
根据我自己的使用体验和社区里大家讨论比较多的，整理几个：
| Skill方向 | 场景示例 | 依赖提醒 |
|---|---|---|
| 新闻/信息汇总 | 定时抓取多个源，生成摘要推送到微信 | 需要网络稳定 |
| 网页内容抓取 | 把URL发给机器人，自动提取正文并结构化输出 | 需要设置来源域名白名单 |
| 自动视频剪辑 | 通过ffmpeg自动处理视频片段、拼接、导出 | 需要安装ffmpeg，吃CPU和内存 |
| 妙想skill | 创意生成、灵感启发类玩法 | 社区第三方开发，先看说明再装 |
安装之前建议先看skill的描述和依赖。很多skill不是装完就能跑，它背后依赖某些工具（比如ffmpeg、pandoc），需要先在系统里装好。
6.3 容器控制Chrome的底层逻辑
回到之前computer use提到的Chrome容器。为什么一定要用容器？
第一是隔离性。浏览器是攻击面很大的软件，让它跑在容器里，即使被恶意网页利用了漏洞，影响范围也被限制在容器内。第二是状态管理。一个容器可以保留一套浏览器配置，不同的自动化任务可以对应不同的容器，互不干扰。第三是清理方便。Chrome跑久了会产生成堆的缓存和临时文件，容器直接销毁重建，一分钟就能回到干净状态。
实操中，容器和OpenClaw之间的连接是通过调试端口（默认9222）实现的。OpenClaw向这个端口发CDP（Chrome DevTools Protocol）命令，控制页面的加载、点击、截图等操作。配置的重点是端口不要冲突，容器网络模式要能和宿主机互通。
6.4 版本升级：不要一直停在旧版
OpenClaw更新速度很快，旧版本的bug可能在新版已经修复。尤其微信通道这种依赖外部协议对接的功能，服务端一调整，旧版可能就失联了。
如果你是源码安装，升级比较简单：
bash复制cd openclaw目录
git pull origin main
npm install
pm2 restart openclaw
如果你是用官方脚本默认安装的，升级前先看一下官方文档的升级说明，寻找脚本自带的升级参数，比如./install.sh --update（以官方脚本实际参数为准）。
升级完成之后，建议做三件事：看一眼pm2 status确认进程起来了；发一条测试消息确认微信通道正常；测一个平时常用的skill确认没有回归。这三件事花不了两分钟，但能避免“升级了一周之后才发现早就出了问题”的尴尬。
7. 部署后最值得记住的几个排障经验
7.1 Web管理界面打不开
现象：浏览器输入http://服务器IP:3000，页面一直转圈或拒绝连接。
排查链路：
- 先确认服务进程是否在监听：
ss -lntp | grep 3000，如果有listen记录，说明服务起来了。 - 如果没监听，看pm2状态，可能进程没起来，翻日志。
- 如果服务在监听但外面连不上，查两个地方：安全组是否放行了3000端口；服务器系统防火墙（ufw/firewalld）是否拦截了端口。
- 如果你在配置里把管理界面绑定到了
127.0.0.1，那外部是必然连不上的，需要用SSH隧道访问，或者改为0.0.0.0。
一个常见坑：阿里云有两种防火墙概念，一种是云控制台里的安全组，另一种是轻量应用服务器控制台里的“防火墙”页签，两处都要放行才行。很多人在安全组放行了但忘了轻量控制台的防火墙，结果还是连不上。
7.2 定时任务不执行
定时任务不执行，排第一的原因是时区。
我前面已经强调过，OpenClaw的调度器读取的是系统时区。服务器默认UTC的话，你填“每天早上8点”，实际会在UTC 8点也就是北京时间16点执行。如果你发现任务在“错误的16点”跑了，其实任务没问题，是时区没设置对。统一按第2.4节的方法设置时区即可。
第二个原因是时区虽然对了，但服务器重启后chrony没起来，系统时间漂移。检查：
bash复制timedatectl status
chronyc tracking
第三个原因是任务里的命令依赖了登录环境变量。通过pm2拉起的环境和在交互式shell里的环境可能不一样，有些命令找不到。解决办法是在skill脚本里用绝对路径，或者在执行脚本前source环境变量文件。
7.3 资源占用和账单控制
OpenClaw跑起来之后，资源占用大头一般这几个：Node.js主进程（内存吃几百M）、Chrome容器（如果经常用，内存1G以上）、日志文件（慢慢涨）。我每周看一次：
bash复制pm2 status
docker stats --no-stream
df -h
日志要定期清理。pm2的日志如果不清理，几个月下来会有几个G。可以设置日志轮转：
bash复制pm2 install pm2-logrotate
pm2 set pm2-logrotate:max_size 50M
pm2 set pm2-logrotate:retain 7
账单控制方面有几点：如果只是轻量使用，按固定带宽买比按流量划算，流量费很容易超出预期；不要在多个地域同时开实例跑同样的任务，用不上的实例及时释放；学生机/活动机的到期时间提前记好，到期前做一次快照备份，后续续费或换新机都能平滑迁移。
7.4 几个从实战里沉淀下来的提醒
最后啰嗦几句，都是我用时间和教训换来的：
- 重要配置和skill目录记得定期备份。云服务器崩溃或误操作的时候，没有备份就等于全部重来。用阿里云控制台的快照功能，或者自己定期打包关键目录到独立存储位置。
- 不要用root账号跑OpenClaw。一方面是安全考虑，另一方面是root环境下某些依赖会有权限解析问题，反而不如普通用户顺畅。
- 改配置前先备份原文件。OpenClaw的配置文件出一次错，服务可能直接起不来。改之前
cp一份带日期的备份，是个很便宜的好习惯。 - 善用白名单和日志。给computer use设置域名白名单，给skill设置执行权限，别让Agent可以“自由行动”。日志是排障的第一依据，保持日志可读性比什么都重要。
这是我的完整部署经验，全部是实操过的步骤和踩过的坑。如果你也在部署OpenClaw，按这个顺序来基本能一路顺畅；如果遇到我没写到的奇怪问题，记住一个原则：先把日志翻清楚再动手，别凭感觉乱重启。