OpenClaw云服务器部署指南：从Ollama到QQ机器人7x24小时运行-嵌云网-嵌入式AI开发资源站

OpenClaw云服务器部署指南：从Ollama到QQ机器人7x24小时运行

黑河市all·2026-09-20·阅读 21 GEO检测（免费）

OpenClawOllamaQQ机器人

|难度：普通|阅读约 32 分钟

我把 OpenClaw 在 Linux 云服务器上的完整部署过程拆开揉碎写了一遍，从选服务器、装 Ollama 模型服务，到配置 QQ 机器人通道、systemd 守护进程，再到我实际踩过的几个报错坑，全流程都有命令和原因解释。如果你准备把机器人放到云端 7x24 小时运行，这篇可以直接当成操作手册来用。

1. 整体思路与方案选型

1.1 为什么我推荐直接上云服务器，而不是本地 Windows

OpenClaw 这套东西本质上是一个跑在 Node.js 环境里的消息机器人框架，它负责对接各类 IM 平台（QQ、微信、Discord 等），然后把用户消息转发给本地或远程的大模型推理服务，拿到回复后再通过原通道发出去。很多人在 Windows 上折腾，遇到最多的就是“OpenClaw could not safely verify the WSL2 environment”这类环境校验问题。

OpenClaw 官方设计上更偏向类 Unix 环境，Windows 下虽然能通过 WSL2 或 Docker 跑，但环境校验、网络互通、文件权限这些环节很容易出幺蛾子。与其在本地折腾半天，不如直接在 Linux 云服务器上跑，路径干净、权限清晰、公网访问也不受 NAT 限制，关键是能 7x24 小时在线，不用担心电脑关机。

1.2 部署 OpenClaw 需要哪些核心组件

OpenClaw 本身不是一个“全家桶”，它更像一个调度框架。一次完整的部署包含三个层面：

接入层：负责接收 QQ 消息并发送回复。OpenClaw 通过 QQ 通道（官方开放平台或 OneBot 协议桥接）实现。
大脑层：真正生成对话内容的 AI 大模型。这里我用 Ollama 做本地推理服务，不需要额外购买 API。
运行时：OpenClaw 作为 Node.js 应用运行，需要 Node 环境，同时要保证模型服务的端口能被本机访问。

这三层各自独立、又相互依赖。好处是每一层都能单独替换：今天用 Ollama 跑 Qwen，明天想接 DeepSeek API，只需要改 OpenClaw 的模型配置，不用动接入层；同理，QQ 通道出问题也只会影响接入层，不会影响模型服务。

1.3 服务器配置怎么选才不花冤枉钱

先回答一个热搜词里的问题：云服务器 32 核 128G 里的 128G 指的是内存，不是磁盘。内存大小直接决定了你能跑多大的模型。对于 OpenClaw 这种场景，我的建议是：

机器人对话量大、需要同时处理多个群消息的，内存优先，CPU 其次。
跑 7B 参数级别的量化模型（比如 Qwen2.5-7B-Q4），内存至少 8G，推荐 16G。
跑 14B 以上的大模型，内存至少 32G，否则加载后基本没有剩余空间跑其他进程。
磁盘建议 40G 起步，因为模型文件本身就是几个 G 到十几个 G。

我自己用的是 4 核 16G 的机器，跑 7B 量化模型完全够用，开多个群机器人都没有明显卡顿。如果你预算有限，可以先用便宜的 2 核 4G 试水，模型换成 3B 或 4B 级别的，但说实话体验会打折扣。

1.4 本文的部署路径总览

具体路线是：购买并初始化云服务器 → 安装 Ollama 并拉取模型 → 安装 Node.js → 部署 OpenClaw → 配置 QQ 通道 → 用 systemd 守护进程 → 测试与日志排查。

这套方案的优势在于每个环节都有明确的验证节点，出问题能快速定位。而且所有软件都是开源免费，没有额外的 API 费用，长期跑的成本就是服务器的月租。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 服务器与系统环境初始化

2.1 购买服务器后的首次登录

我用的是 Ubuntu 22.04 LTS，这个版本对 OpenClaw 和 Ollama 的兼容性最好。购买后第一步是 SSH 登录，生产环境建议直接配置密钥登录，避免密码登录被暴力破解。

bash复制# 在本地生成密钥对
ssh-keygen -t ed25519 -C "openclaw-server"

# 将公钥复制到服务器
ssh-copy-id root@你的服务器IP

# 登录服务器
ssh root@你的服务器IP

第一次登录后，马上做两件事：创建普通用户、关闭 root 密码登录（如果用密钥的话可以保留 root 登录，但新建一个普通用户更规范）。

bash复制# 创建用户
adduser openclaw
usermod -aG sudo openclaw

# 切换到新用户继续操作
su - openclaw

2.2 更新系统与安装基础依赖

新机器到手，更新是肌肉记忆。OpenClaw 需要 git、curl、build-essential 这些基础工具，最好一次装齐。

bash复制sudo apt update && sudo apt upgrade -y
sudo apt install -y git curl build-essential

有一个细节容易被忽略：OpenClaw 安装时如果有编译原生模块的需求，build-essential 里的 gcc、make 是必需的。缺了它，npm install 阶段可能会报 node-gyp 相关的错误。

2.3 防火墙与安全组配置

云服务器的安全组和系统防火墙是两个层面，缺一不可。安全组负责公网入口，系统防火墙负责本机规则。OpenClaw 本身不需要对外暴露端口，因为所有连接都是主动外连到 QQ 服务器，所以只需要放通 SSH 端口。

bash复制sudo ufw allow ssh
sudo ufw enable
sudo ufw status

这里有个经验：很多初学者的机器被入侵，就是因为把模型服务端口（比如 Ollama 的 11434）暴露到了公网。Ollama 的 API 没有鉴权机制，一旦暴露，任何路过的人都能调用你的模型，流量费直接爆表。所以 Ollama 监听地址必须限制在 127.0.0.1。

2.4 安装 Node.js 运行时

OpenClaw 基于 Node.js，版本选择很重要。太老的版本（比如 14）会导致依赖装不上，太新的 LTS 反而比较稳。我推荐用 NodeSource 源安装 20 LTS。

bash复制curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

装完确认版本，node -v 和 npm -v 都出来就说明环境 OK。这里建议不要用系统自带的旧版 node，因为 OpenClaw 的依赖树其实不小，旧版 node 容易在 npm install 阶段卡死在编译环节。

3. 大模型推理服务部署

3.1 为什么选择 Ollama 来做本地推理

OpenClaw 的优势之一是支持多种模型后端，其中 Ollama 是上手成本最低的一种。Ollama 把模型下载、量化压缩、推理 API 都封装好了，一条命令就能把一个 7B 模型跑起来，而且对 CPU 推理做了优化。OpenClaw 通过 OpenAI 兼容接口调用 Ollama，所以在配置层几乎不需要额外适配。

Ollama 的安装方式很简单，官方提供了一键脚本：

bash复制curl -fsSL https://ollama.com/install.sh | sh

装完之后，Ollama 会以 systemd 服务的形式运行，默认端口 11434。注意这个时候监听地址默认是 127.0.0.1，这是对的，先别动。

3.2 模型选择与拉取

模型选型是影响机器人智能程度和响应速度的关键。我实测下来，在 16G 内存的 CPU 机器上推荐：

模型	参数量	量化版本	内存占用	适合场景
Qwen2.5-7B-Instruct	7B	Q4_K_M	约 5-6G	中文对话、通用问答
DeepSeek-R1-Distill-Qwen-7B	7B	Q4_K_M	约 5-6G	推理、逻辑题
Qwen2.5-3B-Instruct	3B	Q4_K_M	约 2-3G	低配机器、快速响应

以 Qwen2.5-7B 为例，拉取命令：

bash复制ollama pull qwen2.5:7b

模型文件会保存到 /usr/share/ollama/.ollama/models（root 安装）或 ~/.ollama/models（普通用户），体积大概 4-5G，下载速度取决于服务器带宽。国内服务器下载 Ollama 模型可能有网络问题，可以配置镜像源；如果云服务商本身有内网镜像，优先用内网。

拉取完成后，先手动测一下模型能否正常响应：

bash复制ollama run qwen2.5:7b "你好，请介绍一下你自己"

如果这一步正常输出，模型层就通了。

3.3 配置 Ollama 内存与并发参数

默认 Ollama 会占据所有可用内存，这在同机跑 OpenClaw 时可能造成资源紧张。可以在 systemd 服务中限制内存使用，或者用环境变量 OLLAMA_NUM_PARALLEL 控制并发数。

bash复制sudo systemctl edit ollama

在打开的编辑窗口中加入：

ini复制[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_MAX_LOADED_MODELS=1"

然后重启：

bash复制sudo systemctl restart ollama

之所以把并发数限制在 4，是因为如果每个群同时涌进来十几条消息，模型推理会排队，反而拖慢整体响应。限制并发后，多余请求在 OpenClaw 层排队，不会压垮模型服务。

3.4 验证 Ollama API 可用性

OpenClaw 调用的是 Ollama 的 /v1/chat/completions 接口（兼容 OpenAI 格式），验证方式：

bash复制curl http://127.0.0.1:11434/v1/models

正常会返回一个包含模型名的 JSON 列表。再测一次对话补全：

bash复制curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen2.5:7b",
    "messages": [{"role": "user", "content": "你好"}]
  }'

返回内容里包含回复文本，就说明 API 完全正常。这一步非常重要，因为后面 OpenClaw 连不上模型服务时，排查方向就分成了“模型服务问题”还是“OpenClaw 配置问题”。

4. OpenClaw 安装与 QQ 机器人接入

4.1 获取 OpenClaw 并初始化项目

OpenClaw 官方推荐通过 npm 安装，实际上提供的是二进制包和 npm 包两种方式。我用的是 npm 安装方式，方便后续版本升级。

bash复制sudo npm install -g openclaw

安装完成后，初始化一个专用项目目录：

bash复制mkdir ~/openclaw-bot && cd ~/openclaw-bot
openclaw init

初始化过程会生成默认配置文件 config.json（或 openclaw.config.*，取决于版本）。这一步如果报权限错误，检查一下 npm 全局目录的权限，或者用 sudo 执行。

4.2 修改模型配置，对接 Ollama

打开配置文件，核心是找到 models 相关的配置段，设置 provider 为 ollama，并指定刚才拉取的模型名称：

json复制{
  "model": {
    "provider": "ollama",
    "name": "qwen2.5:7b",
    "baseURL": "http://127.0.0.1:11434/v1"
  }
}

这里 baseURL 必须带 /v1 后缀，因为 OpenClaw 走的是 OpenAI 兼容接口。如果你用的是其他模型，比如 deepseek-r1:7b，只需要改 name 字段就行。

配置完成后，先用命令行模式验证 OpenClaw 能否正常对话：

bash复制openclaw chat

输入一句“你好”，如果模型正常回复，说明模型链路已经通了，剩下的就是绑定 QQ 通道。

4.3 QQ 接入的两种方式

QQ 机器人接入一直是个相对敏感的环节，主要是腾讯对机器人账号的管控比较严格。目前主流有两种方式：

第一种是官方接入，使用 QQ 开放平台的机器人凭证。需要在开放平台创建应用，拿到 BotAppID 和 Token，然后在 OpenClaw 配置中填入。这种方式最稳定、最合规，但审核周期相对较长。

第二种是基于 OneBot 协议的桥接方式。通过 NapCat、Lagrange 等中间层把 QQ 的消息流转换成 OneBot 标准格式，OpenClaw 通过 HTTP 或 WebSocket 与中间层通信。这种方式配置灵活，能实现在个人账号上挂机器人，但存在账号风控风险，需要谨慎使用。

4.4 官方接入配置示例

在 QQ 开放平台创建应用后，在 OpenClaw 配置文件中填入：

json复制{
  "channels": {
    "qq": {
      "enabled": true,
      "appId": "你的BotAppID",
      "token": "你的BotToken",
      "sandbox": false
    }
  }
}

其中 sandbox 字段是沙箱模式，测试阶段建议开启，等逻辑验证无误再关掉，能避免误发消息到正式群里。

4.5 桥接接入配置示例（以 NapCat 为例）

如果用 OneBot 桥接，需要先在服务器或另一台机器上跑 NapCat，拿到 WebSocket 连接地址。OpenClaw 的配置类似：

json复制{
  "channels": {
    "qq": {
      "enabled": true,
      "mode": "onebot",
      "wsURL": "ws://127.0.0.1:8080"
    }
  }
}

需要注意的是，桥接方式下 OpenClaw 是被动连接方。NapCat 先启动并监听 8080 端口，OpenClaw 启动时主动连上去。如果顺序反了，连接会失败，启动日志里能看到 connection refused，这时候把 NapCat 先拉起就行。

生产环境建议用 systemd 同时管理 NapCat 和 OpenClaw，让两者都开机自启，再用 Restart=always 保证进程崩溃后能自动拉起。

4.6 启动与破冰测试

配置完成后启动 OpenClaw 前台模式，方便看日志：

bash复制openclaw start

或者直接 npm start，取决于你初始化时生成的 package.json。等到日志里出现 QQ channel connected 之类的字样，说明通道建立成功。这时候用另一个 QQ 号给机器人发一条消息，观察日志里的消息流转：

消息被 QQ 通道接收
转发给 Ollama 模型处理
模型返回结果
结果通过 QQ 通道回发

如果任意一步缺失，就对照日志排查对应组件。

5. 进程守护：让机器人 7x24 小时在线

5.1 为什么不能只用 nohup

很多人图省事用 nohup 或 screen 跑服务，这在临时测试时没问题，但服务器一旦重启，或者进程因内存不足被系统杀掉，机器人就挂了，而且不会自动恢复。生产环境必须上 systemd。

5.2 编写 systemd 服务文件

创建服务文件：

bash复制sudo nano /etc/systemd/system/openclaw.service

内容如下：

ini复制[Unit]
Description=OpenClaw QQ Bot
After=network.target ollama.service
Wants=ollama.service

[Service]
User=openclaw
WorkingDirectory=/home/openclaw/openclaw-bot
ExecStart=/usr/bin/openclaw start
Restart=always
RestartSec=10
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

这里有三个关键点：

After 和 Wants 声明了对 ollama 服务的依赖，确保开机时 Ollama 先启动，OpenClaw 后启动，避免启动即连接失败。
Restart=always 让进程无论因何退出都自动重启，RestartSec=10 设置重启间隔，防止崩溃后疯狂重启刷日志。
User=openclaw 用普通用户运行，不推荐 root，原因很简单：Node.js 应用一旦有安全漏洞，root 权限会让攻击者直接拿到整台机器的控制权。

启动并设置开机自启：

bash复制sudo systemctl daemon-reload
sudo systemctl enable openclaw
sudo systemctl start openclaw

5.3 查看日志与状态

systemd 的好处是日志统一管理，不再需要重定向输出文件：

bash复制# 查看服务状态
sudo systemctl status openclaw

# 实时跟踪日志
sudo journalctl -u openclaw -f

# 查看最近100行
sudo journalctl -u openclaw -n 100 --no-pager

排查问题的第一件事永远是看日志，而不是重启服务。日志里会明确告诉你是哪一层出了问题：是 QQ 连接断开、模型请求超时，还是配置解析失败。

5.4 内存监控和自动重启的补充手段

云服务器内存跑满会导致 OOM（Out Of Memory），系统会主动杀掉占用最大的进程。如果被杀的是 OpenClaw，systemd 的 Restart=always 能救回来；但如果 Ollama 被杀，重启 OpenClaw 也没用。

一个比较实用的做法是给系统加 swap 空间，缓解高峰期内存压力：

bash复制sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

持久化写入 fstab：

bash复制echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

加了 swap 之后，模型推理时短时间内存溢出会先落到磁盘，不至于直接把进程打挂，相当于给系统买了一份“意外险”。

6. 常见问题与排查技巧实录

6.1 WSL2 环境校验失败

部署 OpenClaw 时如果是在 Windows 环境下用 WSL2 会遇到“could not safely verify the WSL2 environment”，这是环境校验逻辑过于严格导致的。解决办法有两个方向：

一个是在 WSL2 中补全校验所需的环境变量和依赖，但这个过程比较折腾，因为校验逻辑会检查内核版本、systemd 运行状态、文件系统类型等等，有一个不满足就报错。另一个是干脆放弃本地跑，把 OpenClaw 直接放到 Linux 云服务器上。从我的经验看，本地跑这么多服务既占资源又不易管理，云服务器反而省心——环境干净，不受 Windows 更新和 WSL 重启影响。

如果你确实要在本地开发调试，建议用 Docker 跑 OpenClaw 容器，绕开宿主机环境校验。

6.2 OpenClaw 能启动，但发消息不回复

这种情况八成是模型服务层出了问题。优先检查：

bash复制curl http://127.0.0.1:11434/v1/models

如果这个地址返回空或连接失败，说明 Ollama 服务没起来或者监听地址不是 127.0.0.1。执行 sudo systemctl status ollama 看服务状态。

如果模型服务正常，再检查 OpenClaw 配置文件里的模型名称是否和 Ollama 里拉取的模型完全一致。模型名差一个冒号都匹配不上，比如 qwen2.5:7b 和 qwen2.5:latest 是两个不同的拉取标签。

6.3 模型回复速度太慢，机器人像卡死

CPU 推理 7B 模型，速度大概在每秒 3-5 个 token，一句话要等十几秒才能回完。如果并发消息多，排队时间更长。两个优化方向：

一是换更小的模型或更激进量化的版本，比如 qwen2.5:3b。二是调整 Ollama 的并发配置，OLLAMA_NUM_PARALLEL=2，避免多个请求同时挤占计算资源。

另外把 system prompt 缩短也能提升响应速度。OpenClaw 支持在配置中设置系统提示词，尽量控制在几十字以内，模型每次请求都会带上这些内容参与计算。

6.4 QQ 账号风控和封号风险提示

这是一个绕不开的话题。用个人 QQ 桥接做机器人，本身就存在账号被风控的风险。我的实测经验是：

新注册的 QQ 号直接挂机器人，大概率活不过一天。
老号、活跃号相对安全，但高频操作（频繁加群、频繁发消息）也会触发风控。
多个 QQ 号共用同一个机器人地址，风险更高。

所以我有几条具体建议：

优先使用官方开放平台的机器人能力，合规且稳定。
如果必须桥接，用不常用的号，做好被限制的心理准备。
控制发消息频率，同类消息合并发送，避免短时间大量回复。
不要把敏感信息经过这个链路，毕竟消息会经由第三方桥梁转发。

6.5 端口冲突和连接拒绝问题

如果 OpenClaw 和 NapCat 部署在同一台服务器，注意端口规划。常见冲突是 8080 被占用，需要改 NapCat 或 OpenClaw 的监听端口。

排查连接拒绝时，优先检查：

bash复制ss -lntp | grep 8080

如果端口没在监听，说明 NapCat 没起来。如果端口被别的进程占用，就需要改配置。

6.6 常见报错速查表

报错信息	原因	解决办法
Could not safely verify WSL2	Windows 环境校验失败	改用云服务器或 Docker
connect ECONNREFUSED 127.0.0.1:11434	Ollama 未启动或端口错误	sudo systemctl status ollama
model not found	模型名写错	ollama list 查看准确名称
WebSocket closed with code 1006	QQ 桥接连接不稳定	重启 NapCat，检查网络
Cannot find module node-gyp	缺少编译依赖	apt install build-essential
EACCES permission denied	目录权限不足	用普通用户运行，避免 root

7. 部署完之后的几点心得

跑通这套流程之后，我最大的感受是：OpenClaw 本身并不复杂，真正决定体验的是你愿不愿意把底层组件一个个吃透。Ollama 负责模型服务，OpenClaw 负责消息流转，NapCat 或官方通道负责 QQ 连接，三层各司其职，任何一层出问题都能通过日志快速定位。

我在第一次部署时跳过了一个“安全步骤”：把 Ollama 的监听地址改成了 0.0.0.0，图省事想用其他设备测试 API。结果第二天发现 11434 端口被大量扫描请求打满，好在没有造成严重损失。从那以后，所有本地服务一律默认只监听回环地址，需要访问时再做受控的内网代理。

最后再分享一个小技巧：在 QQ 机器人正式上线前，可以先创建一个只有你自己的测试群，把机器人拉到这个群里，把 OpenClaw 的日志输出到 journalctl 实时观察。所有 prompt 调试和参数调整都在测试群里完成，确认稳定后再拉进真实用户群，能避免不少尴尬场面。毕竟一个经常抽风不回复的机器人，比没有机器人更让人头疼。