我第一次跑通OpenClaw接进钉钉群的那个晚上,脑子里冒出来的一个念头是:这东西终于从一个命令行玩具,变成了一个能挂在工作群里长期干活的“AI员工”。如果你还没接触过OpenClaw,可以用一句话先理解它:一个开源的AI代理框架,消息从QQ、微信、飞书、钉钉任何一个入口进来,它都能接收、理解、调用Skill工具去执行任务,再把结果推回群里。2026年这个时间点,个人AI助理项目早就不稀奇了,但OpenClaw是当前我实际用过之后,觉得“多渠道接入 + 模型后端可换 + Skill技能栈”三者结合得最顺手的一个。
这篇文章我会完整记录一遍在阿里云ECS上从零部署OpenClaw的过程,包括服务器选型、安装初始化、配置百炼API、编写和安装Skill、接入四个IM平台,以及最后的systemd常驻和HTTPS安全加固。文章尽量少说废话,命令直接给,坑直接标出来。适合两类人看:一类是想把OpenClaw跑起来当个人助理的折腾型玩家,另一类是团队里想搭一个能对接钉钉/飞书的内部机器人、但又不想用SaaS方案的开发者。两条路线都能从这篇文章里找到可以直接抄的配置。
1. 部署前先想清楚:这台阿里云机器到底要承担什么角色
1.1 OpenClaw不是又一个聊天机器人
很多人第一次看到OpenClaw的界面,会把它和“接了大模型API的聊天机器人”划等号。这是最大的误解。聊天机器人做的事情是“你问一句,它答一句”,而OpenClaw的核心定位是一个可以自主执行任务的代理框架。
拆开来看,它由三层组成:
- 消息接入层:负责对接QQ、微信、飞书、钉钉这些平台,统一处理消息协议和回调。
- 大脑层:也就是模型后端,通过配置切换不同的模型服务商,比如阿里云百炼、NVIDIA NIM,也可以是本地模型。
- 工具执行层:这是OpenClaw最有价值的部分,通过Skill机制把“会说话”变成“会干活”。比如让它生成一份数据报表、调用一个脚本、执行一条运维命令,再把结果整理好回复给用户。
这个结构和传统聊天机器人的本质区别在于:聊天机器人是“对话即终点”,OpenClaw是“对话是起点,执行任务才是终点”。这一点直接决定了后面部署时的各种选择,尤其是服务器规格和权限设计。
1.2 为什么选阿里云而不是本地跑
如果你只想在电脑上体验一下,本地装一个也不是不行。但如果你打算让它长期服务一个群或者一个小团队,我强烈建议你放到云服务器上。原因有三个:
第一,必须7x24小时在线。IM平台的消息不会挑你电脑开机的时间来。电脑一合盖、一休眠,群里@机器人就没人应答,体验非常糟糕。
第二,需要固定的公网地址。钉钉、飞书这类平台的webhook回调,以及QQ侧的OneBot连接,都要求有一个稳定的公网地址可以访问。家庭宽带的公网IP不仅多数情况下拿不到,即便拿到了也会变动,还得处理路由器端口映射和ISP封锁的问题,纯属给自己找麻烦。
第三,国内云到国内模型服务的网络链路更稳定。既然要用阿里云百炼API,把OpenClaw直接放在阿里云的ECS上,内网走专线访问百炼,延迟和稳定性都远好于家里宽带到云端的公网链路。
阿里云的优势对于这个场景来说很直接:地域节点多、开通快、百炼API是同一生态,安全组规则配置也直观,遇到问题查文档比冷门小厂商容易得多。
1.3 服务器规格和安全组配置
先说结论:2核4G内存起步,系统盘40G以上,按量付费先试几天再转包年包月。这个规格对于OpenClaw加上Node.js运行时、系统日志、Skill脚本来说,余量充足。如果后续要加载本地模型,或者跑比较重的Skill任务,再升级到4核8G不迟。
地域选择上,如果你的用户和钉钉/飞书群主要在华东,就选杭州或上海;华北选北京;华南选深圳。原则是离你的实际使用场景近,别盲目选热门地域。
操作系统我推荐Ubuntu 22.04 LTS。不是Alibaba Cloud Linux不好,而是Ubuntu的社区资料多、遇到问题能搜到的解决方案最多,对新手最友好。如果你已经有CentOS或者Alibaba Cloud Linux的使用习惯,也能跑,但后面的命令需要对应调整。
安全组是阿里云上新手最容易栽跟头的环节。实例创建后,默认安全组可能只放行了22端口,这意味着你装好OpenClaw之后,从外面任何渠道都访问不到它。以下端口建议在部署阶段提前放行:
| 端口 | 用途 | 建议 |
|---|---|---|
| 22 | SSH远程登录 | 放行,建议限制来源IP |
| 80 | HTTP服务(Nginx反代用) | 放行 |
| 443 | HTTPS服务 | 放行 |
| 3000或8787 | OpenClaw服务端口 | 先放行用于调试,配好HTTPS后可以只允许本机访问 |
这里要多说一句:安全组是云平台层面的防火墙,和操作系统里面的iptables/firewalld是两回事。你在服务器内部怎么放行都没用,安全组不放行就是进不来。所以第一步先把安全组配置对,后面能省很多排查时间。
2. 阿里云主机初始化和运行环境准备
2.1 登录与基础安全设置
拿到公网IP后,用SSH登录:
ssh root@你的服务器公网IP登录成功之后第一件事不是急着装软件,而是创建一个日常使用的普通用户。OpenClaw官方其实不推荐直接用root跑服务,因为Agent框架本身有执行命令的能力,用root权限跑相当于给了它一把万能钥匙。创建一个名为ubuntu的管理员用户:
adduser ubuntu usermod -aG sudo ubuntu rsync -a --exclude='/proc' --exclude='/sys' --exclude='/dev' --exclude='/run' /root/ /home/ubuntu/我习惯把root家目录里已有的配置(比如后面要用的环境变量文件)同步到新用户家目录下,省得切用户之后找不到。然后测试一下新用户能否正常sudo:
su - ubuntu sudo whoami返回root就说明权限正常。之后所有操作都用这个用户执行,包括后面配置systemd服务。
2.2 更新系统与安装基础工具
先更新软件源和已安装软件包,这步看起来基础但很重要。新实例的软件源往往不是最新的,直接装依赖容易装到老版本。
sudo apt update && sudo apt upgrade -y然后安装构建工具链和常用工具:
sudo apt install -y build-essential git curl wget unzip如果这一步在阿里云上觉得下载慢,可以先把apt源换成阿里云的镜像源,尤其是非华东地域的实例,速度差距很明显。换源方式很简单:编辑/etc/apt/sources.list,把其中的archive.ubuntu.com和security.ubuntu.com替换为mirrors.aliyun.com即可,然后重新sudo apt update。
2.3 Node.js环境:为什么必须用nvm而不是apt
OpenClaw的运行时是Node.js,版本要求比较明确,至少需要Node.js 18以上,我在2026年初部署时用的是Node.js 20 LTS。这一步有个常见的坑:Ubuntu 22.04自带的apt源里Node.js版本是12.x或14.x,直接apt install nodejs装出来的一定不满足要求。
我的做法是先用nvm安装,而不是去手动下载tar包。nvm最大的好处是支持多版本共存和随时切换,后面你如果因为某些Skill依赖Node版本冲突,可以随时切版本,不用重装系统。
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash安装完成后重新加载shell配置:
source ~/.bashrc然后安装Node.js 20:
nvm install 20 nvm alias default 20 node -v确认输出的版本号是v20.x.x就对了。顺手装上pnpm,OpenClaw源码方式安装时需要用到:
npm install -g pnpm这里我插一句经验:OpenClaw对Node版本很敏感,如果你后面启动服务时遇到一些莫名其妙的段错误或者模块加载失败,先怀疑Node版本,大概率是你系统里残留了旧版Node,which node看一下路径,确认用的是nvm管理的那一个。
3. OpenClaw本体安装与初始化
3.1 npm全局安装和源码运行的取舍
OpenClaw的安装方式官方给了两种:npm全局安装和源码运行。我的建议是日常使用用npm全局安装,原因很简单:省心。npm方式装的是一个可直接执行的openclaw命令,升级时一条命令搞定:
npm install -g openclaw如果你需要二次开发、改OpenClaw本身的代码,那才需要从源码运行。源码方式需要先clone仓库、pnpm install、pnpm build,整个过程耗时且容易因为依赖版本踩坑,但好处是能随时拉最新commit,适合追新功能的人。
两种方式对最终配置完全没影响,配置文件都读取同一个~/.openclaw目录。我建议先走npm安装,跑通全流程之后再考虑要不要折腾源码。
安装完成后检查版本:
openclaw --version客户端没必要再装了。安装完成后检查版本。
3.2 初始化与config.yaml核心字段
安装完成后,运行初始化命令:
openclaw init这个命令会在当前用户家目录下生成~/.openclaw/目录,里面有一个config.yaml配置文件。整个OpenClaw的几乎全部行为都由这个文件控制。生成出来的默认配置里有很多注释和示例,你需要动手改的核心字段主要是这几块:
agent: name: openclaw model: provider: dashscope model: qwen-plus api_key_env: DASHSCOPE_API_KEY base_url: https://dashscope.aliyuncs.com/compatible-mode/v1 temperature: 0.7 channels: dingtalk: enabled: false feishu: enabled: false qq: enabled: false wechat: enabled: false skills: dir: ~/.openclaw/skills approval: enabled: true default: prompt先别急着让所有渠道都生效。我建议初始化之后保持默认渠道全关,先用CLI模式跑通模型对话,再接IM渠道,这样能明确区分“模型问题”和“渠道问题”,排查起来非常高效。
如果你在这一步看到openclaw命令找不到,说明npm全局bin目录没有加入PATH。检查一下npm prefix -g的输出,把对应的bin目录加到~/.bashrc里。
3.3 首次启动和CLI冒烟测试
在配置好百炼API之前,OpenClaw是没法正常对话的,所以你如果现在就运行openclaw chat,会看到模型连接失败的报错。这是正常的,我们先把服务启动起来,确认进程和端口正常。
启动服务:
openclaw serve看到监听端口日志输出后,另开一个SSH窗口确认进程和端口:
ss -tlnp | grep 3000 curl http://127.0.0.1:3000/health如果有一个{"status":"ok"}之类的JSON返回,说明服务核心已经正常工作。这一步的意义在于:排除了“服务本身没起来”这个变量,后面模型和渠道出了问题,不会被误导到进程层面。
3.4 升级到2.x时“exec approvals exists”报错的正确处理
这里说一个我在旧版本升级到OpenClaw 2.x时遇到的报错,和热搜词里那条“legacy exec approvals exist at /root/.openclaw/exec-approvals.json. run `ope”对应的是同一个场景。
报错的大意是:检测到旧版本遗留的/root/.openclaw/exec-approvals.json文件,里面记录的是旧格式的命令审批记录,2.x版本不能直接读取,需要先迁移。我当时不知道这个情况,直接把这个文件删了,结果之前所有“信任的命令”全部作废,所有Skill在执行命令时又弹审批,反而更麻烦。
正确的处理方式是执行迁移命令:
openclaw approvals migrate这个命令会把旧格式的审批记录转换成新格式。如果你确实不需要保留审批记录,再执行:
openclaw approvals reset把审批台账清空重新积累。这里提醒一句:升级版本前先备份~/.openclaw整个目录,OpenClaw几乎每天都有commit更新,跨版本升级出现配置结构不兼容是常态,有备份随时能回滚。
4. 配置百炼API——给OpenClaw装上通义千问
4.1 为什么我把默认模型后端换成百炼
OpenClaw默认模型后端是国外的,如果你在国内服务器上直接跑,会遇到网络延迟高、请求超时甚至完全不可用的问题。我最终选择了阿里云百炼(DashScope),有三个实际考量:
第一,网络稳定性。百炼是阿里云自家服务,ECS访问走的是内网链路,响应速度非常快。我在测试时体感上比默认后端快了一倍都不止。
第二,兼容OpenAI协议。百炼对外提供服务时,兼容OpenAI的接口格式,所以OpenClaw可以无缝对接,不需要特殊适配代码。这一点大大降低了配置复杂度。
第三,中文场景效果好。通义千问系列模型在中文理解、指令遵循方面表现稳定,对于钉钉工作群、飞书这种典型中文办公场景,回答质量和语气都比国外模型更对味。
如果你手上有NVIDIA NIM的key,也可以把provider切到NIM,OpenClaw对NIM的支持是原生级别的。但既然文章标题说的是阿里云部署,百炼就是最顺手的一条路。
4.2 开通百炼与获取API-KEY
登录阿里云控制台,在产品列表里找到“模型服务灵积/百炼”,进入控制台后按提示开通服务。开通本身不收费,调用模型时才按token计费。
然后是创建API-KEY:在百炼控制台的“API-KEY管理”页面,点击创建新的API-KEY。创建后系统会生成一串以sk-开头的字符串,这个就是OpenClaw要用的凭证。
这里有一个安全细节:API-KEY只显示一次,页面刷新后就看不到了。我建议创建后马上把它复制到服务器的环境变量文件里,别存在本地备忘录里到处发。
4.3 写入环境变量和config.yaml
OpenClaw读取API-KEY的方式是从环境变量读取,而不是直接明文写在config.yaml里。这样做的目的是防止配置文件被分享出去时泄露密钥。
创建环境变量文件:
mkdir -p ~/.openclaw cat > ~/.openclaw/env << 'EOF' DASHSCOPE_API_KEY=sk-你的百炼API-KEY EOF chmod 600 ~/.openclaw/env然后确保每次shell登录时加载这个文件。在你的~/.bashrc里加一行:
export $(grep -v '^#' ~/.openclaw/env | xargs)重载配置并验证:
source ~/.bashrc echo $DASHSCOPE_API_KEY能输出你的key就对了。然后用curl直接测一下百炼接口是否通,这一步能提前发现网络和密钥问题:
curl -X POST https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions \ -H "Authorization: Bearer $DASHSCOPE_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"qwen-plus","messages":[{"role":"user","content":"你好"}]}'返回正常的JSON响应就说明百炼链路没问题,这时再去检查config.yaml里的model配置。
4.4 验证模型连接与调参建议
确认config.yaml里模型配置正确后,在OpenClaw的安装目录下运行交互对话:
openclaw chat输入“你好”或者让它帮你算一道题,如果返回正常,整个“OpenClaw服务 + 百炼模型”的链路就完全打通了。
几个值得调的参数:
temperature:控制回答的随机性,默认0.7。给工作群用的机器人我习惯调到0.5,回答更稳定不飘。max_tokens:限制单次回答的最大长度,防止模型输出超长内容刷屏,可以根据实际使用场景限制。model:如果觉得qwen-plus不够聪明,换成qwen-max;如果只是日常聊天和简单任务,qwen-turbo性价比更高。具体以百炼控制台给出的模型列表为准。
我在首次测试时常用的指令是让OpenClaw“用三条bullet points总结这段话”,既能验证工具调用,也能直观感受模型指令跟随能力。
5. Skill实战:从陪聊到干活的技能栈
5.1 Skill机制的本质
如果说模型是OpenClaw的“大脑”,Skill就是它的“手”。这个机制本质上不是传统意义上的“插件”,而是一套**“触发条件 + 执行脚本 + 返回值”的标准化封装**。
打个比方:模型本身知道很多知识,但它没有执行能力,它不能真的去帮你查询服务器状态、不能真的生成报表。Skill就是给模型配了一套“工具”,模型在对话中发现用户的需求匹配某个Skill的描述时,会主动调用这个Skill,并把执行结果组织成自然语言回复给用户。
一个Skill由两部分组成:
SKILL.md:描述这个技能是干什么的、什么情况下触发、怎么使用。- 一个或多个可执行文件:脚本、程序,只要能在系统里跑起来就行。
OpenClaw的模型在每轮对话前会扫描已安装的Skill列表,把Skill的描述作为上下文发送给模型,模型判断当前用户指令是否匹配某个Skill。所以SKILL.md里“描述”写得清不清楚,直接决定Skill能不能被正确触发。
5.2 手写一个“每日工作摘要”Skill
光说原理容易晕,我拿一个自己实际在用的Skill举例。这个Skill的作用是读取一个工作日志文件,生成当天的摘要并发到群聊里。
先创建目录结构:
mkdir -p ~/.openclaw/skills/daily-report然后写SKILL.md:
--- name: daily-report description: 当用户要求“生成每日工作摘要”、“今日总结”、“日报”时使用该技能。读取工作日志文件并返回结构化摘要。不要主动在非工作摘要场景调用。 --- # Daily Report 读取 ~/work-log.md 文件,提取今天日期的条目,以列表形式返回摘要。 ## 用法 执行: ```bash bash ~/.openclaw/skills/daily-report/run.sh接下来写执行脚本`run.sh`: ```bash #!/bin/bash TODAY=$(date +%F) LOG_FILE="$HOME/work-log.md" if [ ! -f "$LOG_FILE" ]; then echo "工作日志文件不存在: $LOG_FILE" exit 1 fi echo "今天的日期: $TODAY" echo "工作日志摘要:" grep "^## $TODAY" -A 30 "$LOG_FILE" || echo "今天还没有记录"给脚本加执行权限:
chmod +x ~/.openclaw/skills/daily-report/run.sh对齐的Markdown代码块里的嵌套反引号没问题。 这里注意SKILL.md的description字段,我特别强调了“不要主动在非工作摘要场景调用”,这是为了防止模型在用户问“今天天气怎么样”时错误触发日报技能。描述越精准,误触率越低,这是Skill编写里一定要有的自觉。
5.3 Skill的安装、启用与调试
除了手动创建,OpenClaw也支持从远程仓库安装Skill:
openclaw skill search weather openclaw skill install weather openclaw skill list openclaw skill enable daily-reportskill list能看到所有已安装的Skill及启用状态。安装后建议先用openclaw chat在命令行里手动测试触发,确认正常后再接IM渠道。调试时要善用OpenClaw的运行日志,通常在~/.openclaw/logs/下,看Skill是否被调用、脚本输出是什么、报错信息是什么,都在日志里有迹可循。
我遇到的一个高频问题是:Skill脚本在Shell里直接执行正常,但通过OpenClaw调用就报权限错误。原因往往是systemd服务运行时的用户和家目录与手动执行时不一致,导致读不到家目录下的文件或者没有家目录的写权限。排查思路很简单,先确认ps aux | grep openclaw看它以什么用户身份运行,再对照那个用户家目录下有没有对应的文件。
5.4 exec-approvals.json:审批白名单的正确用法
Skill调用时,OpenClaw有一个安全机制:执行命令前需要审批。默认策略是每次执行都询问,但在群机器人场景下,你不可能每次都在服务端确认,所以需要配置审批白名单。
~/.openclaw/exec-approvals.json就是记录这些审批决策的文件。当你确认某条命令可以信任时,把它加入白名单,后续相同命令就不再询问。
我建议的配置思路是:只放行完全确定安全的命令,比如读取日志、拉取API数据这类只读操作,涉及删除、写入、网络请求外发的命令保持每次询问。配置文件结构大致如下:
{ "allow": [ "bash ~/.openclaw/skills/daily-report/run.sh", "date", "df -h" ], "deny": [ "rm -rf *", "sudo shutdown" ] }这样的好处是既保证了自动化程度,又不至于把整个服务器的生杀大权交给AI。配置修改后记得重启OpenClaw服务使配置生效。
6. 多平台接入:QQ、微信、飞书、钉钉
6.1 四类通道的正确打开方式对比
OpenClaw接入IM平台的方式,本质分成两大类:
一类是webhook机器人,代表是飞书和钉钉。你在群里创建一个自定义机器人,得到一个webhook地址,OpenClaw配置这个地址后,主动向群里推送消息。这种方式的局限是:机器人收到用户消息后,是平台通过回调地址推给OpenClaw,所以要求OpenClaw有一个公网可访问的回调地址。简单说,它更适合“批量推送”和“主动喊话”。
另一类是长连接协议,代表是QQ的OneBot协议。这类方式需要额外部署一个协议客户端,由客户端主动连接到OpenClaw上。它的好处是不需要公网回调地址,配置相对灵活。
企业微信则走webhook路线,通过群机器人推送消息。个人微信不建议碰,原因后面单独说。
四者在配置难度和使用场景上区别很大:
| 平台 | 接入方式 | 配置难度 | 主要应用 |
|---|---|---|---|
| 飞书 | 自定义机器人webhook | 低 | 群通知、日报推送、交互机器人 |
| 钉钉 | 自定义机器人webhook | 低 | 群通知、报警、任务汇报 |
| OneBot协议 + 第三方客户端 | 中 | 个人/群闲聊、自动回复 | |
| 企业微信 | 群机器人webhook | 低 | 企业内部通知同步 |
| 微信个人号 | 不推荐接入 | 高且有风险 | —— |
6.2 飞书自定义机器人接入:五分钟搞定
飞书接入流程很简单,是最适合首次试验的渠道。打开目标飞书群,进入“设置 > 群机器人 > 添加机器人 > 自定义机器人”,取个名字,复制webhook地址。
然后修改config.yaml:
channels: feishu: enabled: true webhook: https://open.feishu.cn/open-apis/bot/v2/hook/你的飞书Webhook地址 secret: "" # 如果你的机器人开启了签名校验,把secret填这里重启OpenClaw服务后,在飞书群里@机器人发一句话,OpenClaw就能收到并回复。飞书自定义机器人有一个坑:默认不校验签名时,任何拿到webhook地址的人都能向你的群发消息,所以强烈建议在飞书机器人安全设置里开启“签名校验”,然后把secret填到配置里。
6.3 钉钉自定义机器人接入:注意加签和关键词
钉钉的接入路径也很类似:在钉钉群里进入“智能群助手 > 添加机器人 > 自定义机器人”,创建后拿到webhook地址。
钉钉有一个和飞书不同的机制:安全设置三选一,必须选一个才能创建,分别是自定义关键词、加签、IP白名单。
我实际测试下来的最佳组合是关键词 + 加签。自定义关键词意味着每条推送到群里的消息必须包含这个关键词,否则会被钉钉拦截。比如你把关键词设为“报告”,那OpenClaw每次推消息都得带“报告”两个字,这在消息内容自由组合时很别扭。所以我建议设一个中性关键词,比如“AI”或“助理”,让OpenClaw在大多数回复里主动包含它。
配置里对应填两处:
channels: dingtalk: enabled: true webhook: https://oapi.dingtalk.com/robot/send?access_token=你的钉钉AccessToken secret: 你的钉钉加签密钥这里要特别提醒:钉钉的webhook地址本身带了一个access_token参数,OpenClaw配置里只需要填这个地址和secret,不要再把secret拼到URL后面,否则验签会失败。
6.4 QQ接入:OneBot协议客户端
QQ的接入和飞书、钉钉思路完全不同。OpenClaw本身不直接连QQ服务器,而是通过OneBot协议与一个“协议客户端”通信。这个客户端负责与QQ的消息系统交互,再把消息翻译成OneBot协议转发给OpenClaw。
我建议的部署方式是用反向WebSocket:OpenClaw作为WebSocket服务端,协议客户端主动连接上来。
config.yaml里相应配置:
channels: qq: enabled: true protocol: onebot type: reverse-ws host: 0.0.0.0 port: 6700然后在协议客户端上配置反向WebSocket连接地址:
ws://你的服务器IP:6700启动协议客户端后,打开OpenClaw日志,如果出现WebSocket client connected,说明QQ侧已经接通。之后在QQ群里@机器人即可触发对话。
需要留意的是,第三方QQ协议客户端在2026年普遍面临账号风控的问题,新号很容易被限制登录,建议用不常用的QQ号或小号测试,不要拿主号冒险。
6.5 企业微信机器人接入与个人微信的风险提示
企业微信接入最简单,就是在企业微信群里添加“群机器人”,得到一个webhook地址,配置方式与飞书、钉钉的webhook完全一致:
channels: wechat: enabled: true type: enterprise webhook: https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的企微Key个人微信的情况比较特殊。市面上的个人微信机器人方案大多依赖非官方协议或逆向hook,账号随时有被限制的风险,而且多数方案还要依赖Windows环境运行,和OpenClaw服务端的Linux部署结构不搭配。我的建议很明确:个人微信场景就不要折腾非官方接入方案了,用企业微信群机器人就能覆盖绝大多数通知和交互需求。如果你实在需要处理个人微信消息,更稳妥的路线是用微信官方提供的客服消息或公众号接口做间接打通,至少账号安全有保障。
7. 常驻运行、端口暴露与日常维护
7.1 systemd守护进程配置
现在OpenClaw已经能正常对话和接入了,但如果直接关掉SSH窗口,服务就停了,这显然不能接受。正确做法是用systemd把它注册成系统服务,设置开机自启和崩溃自动重启。
创建服务文件:
sudo tee /etc/systemd/system/openclaw.service << 'EOF' [Unit] Description=OpenClaw AI Assistant After=network.target [Service] User=ubuntu WorkingDirectory=/home/ubuntu ExecStart=/home/ubuntu/.nvm/versions/node/v20.x.x/bin/openclaw serve Restart=always RestartSec=5 EnvironmentFile=/home/ubuntu/.openclaw/env [Install] WantedBy=multi-user.target EOF注意ExecStart里的路径必须是which openclaw返回的完整路径,不能用简写命令,否则systemd找不到。EnvironmentFile指向之前创建的环境变量文件,这样DASHSCOPE_API_KEY和后面新增的密钥才能在服务启动时被正确加载。
然后重载并启动:
sudo systemctl daemon-reload sudo systemctl enable --now openclaw sudo systemctl status openclaw以后查看服务日志用:
journalctl -u openclaw -f这个命令会实时打印OpenClaw运行日志,排查问题时第一个想到它。
7.2 Nginx反代与阿里云免费SSL证书
到这一步,OpenClaw的webhook回调地址还是http://IP:端口的形式。国内IM平台对回调地址普遍要求HTTPS,直接裸HTTP的地址在部分平台会回调失败。所以需要一个Nginx反向代理,专门处理这些回调流量,再用阿里云SSL证书提供HTTPS加密。
安装Nginx:
sudo apt install -y nginx创建一个Nginx站点配置:
server { listen 80; server_name your-domain.com; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }关于SSL证书,直接在阿里云控制台搜索“SSL证书”,申请免费证书,绑定你的域名并完成DNS验证,下载Nginx格式的证书文件,上传到服务器,然后在Nginx配置里加上证书路径并监听443端口。这个流程在阿里云文档里写得很清楚,按步骤走即可。
需要提醒的是,免费证书的有效期现在一般只有3个月,到期后要记得续期。我建议在服务器上配一个crontab提醒,或者直接搜一下acme.sh的自动续期方案,设置一次后续自动解决。
7.3 常见故障速查表
最后整理一份我实际踩过的坑,按问题现象、可能原因、解决办法列出来,方便日后直接对号入座:
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 飞书/钉钉群收不到机器人消息 | webhook地址填错、加签密钥没填对 | 核对webhook地址和secret,用curl手动POST到webhook测试 |
| 钉钉提示“关键词不匹配” | 消息内容没包含设定的关键词 | 修改机器人安全设置,换一个能接受的通用关键词 |
| 百炼API返回401 | API-KEY没加载或错误 | 确认source ~/.bashrc后echo $DASHSCOPE_API_KEY是否正确 |
| OpenClaw启动即退出 | 端口被占用或Node版本不匹配 | ss -tlnp查端口占用,node -v确认版本 |
| 服务运行一段时间后无响应 | 内存不足被系统杀掉 | 查看dmesg是否有OOM信息,加swap或升级内存 |
| Skill脚本执行报权限错误 | systemd服务用户与文件属主不一致 | 确认服务User字段,调整脚本文件权限 |
关于swap,2G内存的服务器跑OpenClaw加系统本身,偶尔会碰到内存吃紧的情况。提前分配一个2G的swap文件,能避免很多进程被OOM杀掉的尴尬:
sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile我记得自己第一次部署的时候,卡在钉钉回调配置上整整一个晚上,最后发现只是关键词设置没对。后来也遇到过几次版本升级带来的配置破坏,慢慢养成了一个习惯:每次改动config.yaml之前,先把~/.openclaw整个目录打包备份一次,改动之后立刻用openclaw chat验证,确认没问题再把改动同步到其他环境。这套流程看起来笨,但确实帮我躲过了好几次配置文件写错导致的半小时起步排查。如果你按这篇教程搭完,在群里看到机器人第一次正常回复的那一刻,你会觉得前面所有折腾都值了。