1. 为什么要把 OpenClaw 搬到云端而不是留在本机很多人第一次接触 OpenClaw都是在自己电脑上跑起来的。下载 Node.js、克隆仓库、装依赖、配模型折腾一两个小时看到终端里跳出对话界面那种成就感确实不错。但用不了几天问题就来了笔记本一合盖服务就断了想在外面用手机访问发现本地端口根本出不去更别提电脑重装系统或者换机器整套环境又得从头来一遍。我自己最开始也是在 Windows 本机上跑 OpenClaw接的是本地的小参数模型。刚开始觉得挺方便数据都在自己手里也不用花服务器的钱。但实际用下来痛点非常明显。首先是可用性本地服务只在开机且不睡眠的时候才活着我出门在外想查个资料、让助手帮我整理点东西根本连不上。其次是资源占用本地模型跑起来吃内存吃 CPU开着 OpenClaw 的时候我基本没法同时干别的重活。最后是环境一致性Windows 上装 WSL、配 Node 版本、处理各种依赖冲突每次升级都像拆盲盒。把 OpenClaw 部署到云端本质上是把运行环境和使用终端解耦。你的助手跑在一台 7x24 小时在线的服务器上你用什么设备访问都行手机、平板、公司电脑只要能连上网络就能用。而且云服务器的配置可以按需选择跑不动就升配用不上就降配比换电脑划算得多。腾讯云 Lighthouse轻量应用服务器是我比较推荐给个人用户和小团队的方案。它比标准的云服务器 CVM 简单很多控制台里把选镜像、选套餐、开防火墙这几件事做完剩下的就是 SSH 进去敲命令。对于只是想跑一个 AI 助手、不想在云基础设施上花太多精力的人来说Lighthouse 的性价比和易用性都挺合适。这篇文章会从零开始把 OpenClaw 在腾讯云 Lighthouse 上的完整部署流程讲清楚。包括服务器怎么选、系统怎么配、Node 环境怎么装、OpenClaw 怎么拉起来、模型怎么接、外网怎么访问、以及我踩过的那些坑。不管你是刚接触命令行的小白还是已经用过其他云服务的开发者应该都能照着走下来。2. 腾讯云 Lighthouse 的选型与初始化配置2.1 套餐怎么选才不浪费也不卡顿Lighthouse 的套餐按 CPU、内存、带宽、流量几个维度组合。跑 OpenClaw 这种 Node.js 应用核心瓶颈其实不在 CPU而在内存和网络。OpenClaw 本身是个 Node 服务空跑的时候内存占用不算大大概几百 MB。但如果你打算在服务器上同时跑本地模型推理那内存需求就完全不一样了。一个 3B 参数量的模型量化之后大概需要 2-4GB 内存才能跑得比较舒服7B 的模型基本要 8GB 起步。所以选套餐之前先想清楚一件事模型是跑在服务器上还是通过 API 调用外部服务。我的建议是这样使用场景推荐配置说明只跑 OpenClaw 本体模型走 API2核2G最经济够用跑 OpenClaw 小参数本地模型3B 量化2核4G内存是瓶颈CPU 够用跑 OpenClaw 中等模型7B 量化4核8G推理速度可接受多人使用或跑更大模型8核16G 以上按实际并发调整带宽方面Lighthouse 默认给的是峰值带宽比如 4Mbps、6Mbps。如果你只是自己用偶尔通过网页或 API 访问4Mbps 完全够。但如果你要在服务器上跑模型然后通过外网传输推理结果或者有多人同时访问建议选 6Mbps 以上。流量包也要留意Lighthouse 的套餐通常包含每月固定流量超出部分会额外计费。个人使用一般不会超但如果你的助手调用很频繁或者传输的数据量大就要关注一下流量使用情况。地域选择上选离你主要使用地点近的节点延迟会低一些。如果你主要在国内使用选国内节点如果考虑海外访问或者某些 API 服务的地域限制可以选对应的海外节点。这个根据自己实际情况来。2.2 镜像选择Ubuntu 还是别的Lighthouse 提供了多种系统镜像包括 Ubuntu、CentOS、Debian、Windows Server 等。跑 OpenClaw我强烈建议选Ubuntu 22.04 LTS或Ubuntu 24.04 LTS。原因有几个。第一OpenClaw 的官方文档和社区教程绝大多数都是基于 Ubuntu 写的遇到问题搜解决方案的时候Ubuntu 的参考资料最多。第二Node.js 在 Ubuntu 上的安装和管理非常成熟用 NodeSource 的源或者 nvm 都很方便。第三如果你后续要装 Docker、Python 环境、或者其他 AI 相关的工具链Ubuntu 的兼容性最好。CentOS 系列虽然稳定但 CentOS 7 已经停止维护CentOS Stream 的生态和 Ubuntu 有差异新手容易在包管理命令上卡住。Debian 和 Ubuntu 同源也可以用但 Ubuntu 的社区资源更丰富。Windows Server 就不建议了跑 Node 服务和 Linux 工具链的体验差很多而且 Lighthouse 的 Windows 镜像套餐通常更贵。选镜像的时候还有一个细节Lighthouse 提供应用镜像和系统镜像两类。应用镜像里预装了一些软件比如宝塔面板、WordPress、Docker 等系统镜像就是干净的操作系统。跑 OpenClaw 建议选纯净的系统镜像不要选预装了一堆东西的应用镜像避免环境冲突和额外的资源占用。2.3 初始化服务器登录、更新、建用户服务器创建好之后第一件事是登录。Lighthouse 支持密钥登录和密码登录两种方式。强烈建议用密钥登录安全性高很多而且后续用 scp 传文件、配 Git 部署都更方便。在控制台重置密码或者下载密钥之后用 SSH 连上去ssh ubuntu你的服务器公网IP如果是密钥登录命令类似ssh -i /path/to/your-key.pem ubuntu你的服务器公网IP登录进去之后先做三件事第一更新系统包。这一步很多人会跳过但新创建的服务器软件源可能不是最新的先更新一下避免后面装东西出问题sudo apt update sudo apt upgrade -y第二创建一个专用用户来跑 OpenClaw。虽然直接用 ubuntu 用户也能跑但从安全和管理的角度给应用单独建一个用户是更好的实践sudo adduser openclaw sudo usermod -aG sudo openclaw然后切换到新用户su - openclaw第三配置防火墙。Lighthouse 的防火墙有两层一层是控制台里的防火墙规则一层是系统内的 ufw。控制台里的规则决定了哪些端口能从外网访问系统内的 ufw 是第二道防线。OpenClaw 默认跑在某个端口上比如 3000 或 8080你需要先在控制台放行这个端口然后在系统内也放行。控制台的操作是在 Lighthouse 实例详情页找到防火墙添加规则放行 TCP 协议的对应端口。系统内用 ufwsudo ufw allow 22/tcp sudo ufw allow 3000/tcp sudo ufw enable注意在开启 ufw 之前一定要先放行 SSH 端口默认 22否则你可能会把自己关在门外只能通过控制台的 VNC 登录去救。3. Node.js 环境搭建与 OpenClaw 安装的完整链路3.1 Node.js 版本选择与安装方式对比OpenClaw 对 Node.js 版本有要求通常需要Node 18 或以上推荐 Node 20 LTS。版本太低会报各种语法错误或者依赖不兼容版本太高比如最新的奇数版本可能遇到某些依赖还没适配的问题。安装 Node.js 有几种方式我逐一分析一下适用场景方式一apt 直接安装sudo apt install nodejs npm -y这是最简单的方式但 Ubuntu 官方源里的 Node 版本通常比较旧可能是 12 或 14不满足 OpenClaw 的要求。所以不推荐。方式二NodeSource 源安装curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install nodejs -y这种方式安装的是 Node 20版本符合要求而且通过 apt 管理升级方便。适合大多数用户。方式三nvm 安装curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20 nvm use 20nvm 的好处是可以同时装多个 Node 版本随时切换。如果你可能需要在不同项目间切换 Node 版本nvm 是最灵活的选择。缺点是每次新开终端要确保 nvm 的环境变量加载了。我个人的习惯是用 nvm因为后续如果 OpenClaw 升级要求更高的 Node 版本或者我想测试不同版本下的兼容性切换起来很方便。但如果你只是想稳定跑一个服务NodeSource 的方式更省心。安装完之后验证一下node -v npm -v应该输出 v20.x.x 和对应的 npm 版本。3.2 拉取 OpenClaw 源码与依赖安装Node 环境准备好之后就可以拉 OpenClaw 的代码了。假设你已经把代码放在了某个 Git 仓库或者你有压缩包操作方式略有不同。如果是 Git 仓库git clone https://github.com/your-repo/openclaw.git cd openclaw如果是压缩包先上传到服务器然后解压scp -i /path/to/key openclaw.zip openclaw服务器IP:~/ ssh openclaw服务器IP unzip openclaw.zip cd openclaw进入项目目录后安装依赖npm install这一步可能会比较慢因为要下载很多包。如果服务器在国内npm 的默认源可能速度不理想可以换成国内镜像源npm config set registry https://registry.npmmirror.com然后再执行npm install。安装过程中如果遇到 node-gyp 相关的编译错误通常是因为缺少构建工具。装一下sudo apt install build-essential python3 -y然后再重新npm install。3.3 配置文件的关键参数解读OpenClaw 通常需要一个配置文件来指定模型、端口、API 密钥等信息。这个文件可能是.env、config.json、config.yaml或者类似的格式。具体取决于 OpenClaw 的版本和你的部署方式。以常见的.env为例几个关键参数# 服务监听端口 PORT3000 # 模型提供方比如 openai、anthropic、local 等 MODEL_PROVIDERlocal # 如果走 API填对应的 API Key API_KEYyour_api_key_here # 如果走本地模型指定模型路径或模型名称 LOCAL_MODEL_PATH/home/openclaw/models/qwen2.5-3b # 数据库连接如果 OpenClaw 需要持久化 DATABASE_URLsqlite:///home/openclaw/openclaw.db这里重点说一下模型接入这块。OpenClaw 支持多种模型后端常见的有OpenAI 兼容 API如果你有 OpenAI 或者兼容 OpenAI 接口的服务比如国内的一些大模型 API配置base_url和api_key即可。本地模型通过 Ollama、llama.cpp、vLLM 等推理框架跑本地模型OpenClaw 通过本地 HTTP 接口调用。其他云服务商 API比如 Anthropic、Google 等需要对应的 SDK 和密钥。如果你打算在 Lighthouse 上跑本地模型推荐用Ollama安装和拉模型都很简单curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:3b然后 OpenClaw 配置里指向 Ollama 的默认接口http://localhost:11434就行。提示本地模型对内存要求比较高3B 模型量化后大概需要 2-3GB 内存7B 需要 6-8GB。选 Lighthouse 套餐的时候要把这部分算进去。3.4 首次启动与常见报错处理配置好之后启动 OpenClawnpm start或者如果是用 pm2 管理pm2 start npm --name openclaw -- start首次启动常见的报错有这么几类报错一端口被占用Error: listen EADDRINUSE: address already in use :::3000说明 3000 端口已经被别的程序占了。要么改 OpenClaw 的端口要么把占用端口的程序停掉。查占用sudo lsof -i :3000报错二Node 版本不满足SyntaxError: Unexpected token ??这是 Node 版本太低不支持某些新语法。确认node -v是 18 以上。报错三依赖缺失或版本冲突Cannot find module xxx先删掉node_modules和package-lock.json重新npm install。如果还不行检查package.json里的依赖版本是否有冲突。报错四模型连接失败Error: connect ECONNREFUSED 127.0.0.1:11434说明 OpenClaw 尝试连接本地模型服务但连不上。确认 Ollama 或者其他推理服务是否在运行systemctl status ollama如果没有运行启动它sudo systemctl start ollama4. 外网访问、进程守护与安全加固4.1 让 OpenClaw 在外网可访问的正确姿势OpenClaw 默认监听localhost或者127.0.0.1这意味着只有服务器本机能访问。要让外网能访问需要让它监听0.0.0.0。在配置文件里把 host 改成0.0.0.0或者启动时指定HOST0.0.0.0 npm start然后确认 Lighthouse 控制台的防火墙规则里对应的端口已经放行。系统内的 ufw 也要放行。做完这两步理论上就可以通过http://你的公网IP:端口访问了。但这里有一个非常重要的安全问题直接把 OpenClaw 暴露在公网上如果没有认证机制任何人都能访问你的 AI 助手甚至可能通过它执行一些敏感操作。所以强烈建议加一层反向代理和认证。4.2 用 Nginx 做反向代理和基础认证Nginx 可以做两件事一是把 80/443 端口的请求转发到 OpenClaw 的内部端口二是加上 HTTP Basic Auth防止未授权访问。安装 Nginxsudo apt install nginx -y创建一个配置文件sudo nano /etc/nginx/sites-available/openclaw内容大致如下server { listen 80; server_name your_domain_or_ip; location / { auth_basic Restricted Access; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } }生成密码文件sudo apt install apache2-utils -y sudo htpasswd -c /etc/nginx/.htpasswd your_username启用配置并重启 Nginxsudo ln -s /etc/nginx/sites-available/openclaw /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl restart nginx这样访问的时候就需要输入用户名密码了。如果你有自己的域名还可以申请 SSL 证书把 HTTP 升级到 HTTPS进一步加密传输。4.3 用 pm2 守护进程避免 SSH 断开后服务挂掉直接npm start启动的服务在你退出 SSH 会话后就会被终止。要让 OpenClaw 持续运行需要用进程管理工具。pm2是 Node.js 生态里最常用的选择。安装 pm2sudo npm install -g pm2用 pm2 启动 OpenClawpm2 start npm --name openclaw -- start查看状态pm2 status查看日志pm2 logs openclaw设置开机自启pm2 startup pm2 savepm2 startup会输出一条命令复制粘贴执行一下pm2 就会在系统启动时自动拉起 OpenClaw。pm2 还有一个好处是自动重启。如果 OpenClaw 因为某些原因崩溃了pm2 会自动把它拉起来保证服务可用性。4.4 安全加固清单别让服务器变成别人的肉鸡云服务器暴露在公网上安全加固是必须的。以下是我每次部署都会检查的几项第一禁用密码登录只用密钥。编辑/etc/ssh/sshd_config把PasswordAuthentication改成no然后重启 SSH 服务。这样暴力破解密码的攻击就无效了。第二修改 SSH 默认端口。把 22 改成其他端口能减少大量自动化扫描。改完之后记得在 Lighthouse 防火墙和 ufw 里放行新端口。第三安装 fail2ban。它能监控登录日志发现多次失败尝试就自动封 IPsudo apt install fail2ban -y sudo systemctl enable fail2ban sudo systemctl start fail2ban第四定期更新系统。设置自动安全更新sudo apt install unattended-upgrades -y sudo dpkg-reconfigure --prioritylow unattended-upgrades第五最小化开放端口。只放行必要的端口比如 SSH、HTTP、HTTPS。OpenClaw 的内部端口比如 3000不需要对外网开放通过 Nginx 转发就行。5. 模型接入的几种方案与实测对比5.1 本地模型 vs 云端 API怎么选OpenClaw 的核心能力来自背后的模型。模型接入方式直接决定了使用体验、成本和隐私性。我把几种常见方案列出来对比一下方案成本延迟隐私维护难度适合场景本地小模型3B服务器费用低高中个人日常助手本地中模型7B服务器费用中高中对质量有要求云端 API国内按量付费低中低快速上手云端 API海外按量付费中中低特定模型需求本地模型的优势是数据不出服务器隐私性好而且没有按次调用的费用。缺点是模型能力受限于服务器配置小模型在复杂任务上的表现和云端大模型有差距。云端 API 的优势是开箱即用模型能力强不需要操心推理环境的维护。缺点是要花钱而且数据要传到第三方。我的建议是先用云端 API 把 OpenClaw 跑通确认整个链路没问题再考虑要不要换本地模型。这样可以把部署问题和模型问题分开排查降低调试难度。5.2 接入 Ollama 跑本地模型的完整步骤如果你决定在 Lighthouse 上跑本地模型Ollama 是最省事的方案。安装curl -fsSL https://ollama.com/install.sh | sh安装完成后Ollama 会作为 systemd 服务自动运行。拉取模型ollama pull qwen2.5:3b这个命令会下载模型文件大小大概 2GB 左右。下载完成后测试一下ollama run qwen2.5:3b如果能看到对话界面说明模型跑起来了。然后在 OpenClaw 的配置里把模型接口指向 OllamaMODEL_PROVIDERollama OLLAMA_BASE_URLhttp://127.0.0.1:11434 OLLAMA_MODELqwen2.5:3b重启 OpenClaw它就会通过 Ollama 调用本地模型了。注意Ollama 默认只监听127.0.0.1这是安全的。不要把它暴露到公网否则别人可以随意调用你的模型。5.3 模型切换与多模型共存的配置技巧OpenClaw 通常支持配置多个模型然后根据任务类型或者用户选择来切换。比如日常对话用小的快模型复杂推理用大的慢模型。配置方式一般是在配置文件里定义多个 provider然后给每个 provider 一个名字{ providers: { fast: { type: ollama, base_url: http://127.0.0.1:11434, model: qwen2.5:3b }, smart: { type: openai, base_url: https://api.example.com/v1, api_key: your_key, model: gpt-4 } }, default_provider: fast }这样你就可以在对话里指定用哪个模型或者在代码里根据任务复杂度动态选择。多模型共存的时候要注意内存管理。如果同时加载多个本地模型内存会很快吃满。Ollama 支持模型按需加载和自动卸载但切换的时候会有几秒的加载延迟。如果对响应速度要求高可以考虑把常用模型常驻内存不常用的按需加载。6. 部署后我踩过的坑和日常维护经验6.1 那些让我折腾半天的报错坑一WSL 相关的报错。有些人在 Windows 上先用 WSL 试跑 OpenClaw然后想搬到云端结果配置文件里还留着 WSL 的路径比如/mnt/c/Users/...。搬到 Linux 服务器后这些路径不存在启动就报错。解决办法是把所有路径改成 Linux 的绝对路径比如/home/openclaw/...。坑二Node 版本和依赖不匹配。我在本地用 Node 18 跑得好好的搬到服务器上用 Node 16结果一堆语法错误。后来统一用 nvm 管理服务器和本地都锁在 Node 20问题就没了。建议在项目里加一个.nvmrc文件写明版本号这样nvm use会自动切换。坑三防火墙没放行导致以为服务没起来。有一次我在服务器上curl localhost:3000是通的但外网访问不了折腾了半天以为是 OpenClaw 配置问题最后发现是 Lighthouse 控制台的防火墙没放行端口。排查顺序应该是先确认服务本身在跑再确认系统内 ufw最后确认控制台防火墙。坑四pm2 日志把磁盘写满。pm2 默认会一直写日志时间长了日志文件可能几个 GB。要配置日志轮转pm2 install pm2-logrotate pm2 set pm2-logrotate:max_size 10M pm2 set pm2-logrotate:retain 7这样每个日志文件最大 10MB保留 7 个就不会把磁盘写满了。坑五模型下载慢或者中断。在国内服务器上拉 Ollama 模型有时候速度很慢或者断掉。可以配置代理或者用镜像源但更稳妥的方式是先在本地下载好模型文件再通过 scp 传到服务器。Ollama 的模型文件默认在~/.ollama/models传过去之后 Ollama 能直接识别。6.2 日常维护更新、备份、监控OpenClaw 部署好之后日常维护主要是三件事更新、备份、监控。更新方面如果是 Git 部署的git pull拉最新代码然后npm install更新依赖最后pm2 restart openclaw重启服务。更新前最好先看一下 changelog确认有没有破坏性变更。如果是 Docker 部署的docker pull新镜像然后重建容器。备份方面重点备份三样东西配置文件包含 API 密钥等、数据库文件如果有对话历史、以及自定义的模型或插件。可以用 cron 定时打包传到对象存储或者用 rsync 同步到另一台机器。# 每天凌晨 3 点备份配置和数据库 0 3 * * * tar -czf /home/openclaw/backup/openclaw-$(date \%Y\%m\%d).tar.gz /home/openclaw/openclaw/config /home/openclaw/openclaw/data监控方面最简单的方案是用 Lighthouse 自带的监控面板看 CPU、内存、网络的使用情况。如果想更细致可以装htop、netdata或者用 pm2 自带的pm2 monit。pm2 monit这个命令能实时看到 OpenClaw 的 CPU、内存占用和日志输出排查问题的时候很有用。6.3 性能调优的几个实用参数如果感觉 OpenClaw 响应慢可以从几个方向调优Node 内存限制。默认情况下 Node 能用的内存有限如果 OpenClaw 处理大上下文的时候崩溃可以调大NODE_OPTIONS--max-old-space-size4096 pm2 start npm --name openclaw -- startOllama 并发数。Ollama 默认同时只处理一个请求如果多人使用会排队。可以调大并发OLLAMA_NUM_PARALLEL2 ollama serve但要注意并发数越大内存占用越高要根据服务器配置来定。Nginx 缓冲。如果通过 Nginx 转发适当调大缓冲区和超时时间避免大响应被截断proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; proxy_read_timeout 300s;这些参数不是越大越好要根据实际负载调整。我一般会先用默认配置跑一段时间看监控数据找到瓶颈之后再针对性调优。6.4 从单机到多用户的扩展思路一开始可能只是自己用但随着使用频率增加可能会想分享给家人或团队。这时候要考虑几个问题认证和权限。单用户的时候 Basic Auth 就够了多用户就需要更细粒度的权限控制。可以考虑接入 OAuth 或者自己实现一套简单的用户系统。会话隔离。不同用户的对话历史要分开存储避免串扰。OpenClaw 如果支持多会话配置好 session 管理就行如果不支持可能需要在应用层做隔离。资源配额。防止某个用户大量调用导致其他人用不了。可以在 Nginx 层做限流或者在应用层记录每个用户的调用次数。扩展方式。如果单台 Lighthouse 跑不动了可以考虑升级套餐或者把模型推理拆到另一台服务器上OpenClaw 本体和模型服务分开部署。再往上就是容器化和负载均衡但那已经是另一个量级的工程了个人用户一般用不到。我个人从单机自用到现在家里几个人共用最大的体会是先把单用户跑稳再考虑扩展。很多扩展需求其实在单用户阶段就能预判到比如配置文件里预留多用户字段、数据库设计上支持多租户后面升级会顺利很多。如果一开始就按单用户硬编码后面改起来会很痛苦。最后分享一个我常用的排查思路遇到问题先看日志再看监控最后才改配置。pm2 的日志、Nginx 的日志、Ollama 的日志三个地方看一遍大部分问题都能定位到。改配置之前先备份改完重启验证不行就回滚。这套流程看起来笨但能避免很多改着改着服务起不来了的情况。