企业官网建设流程全解析

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 调用外部服务。

我的建议是这样：

带宽方面，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 协议的对应端口。系统内用 ufw：

sudo 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 20

nvm 的好处是可以同时装多个 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为例，几个关键参数：

# 服务监听端口 PORT=3000 # 模型提供方，比如 openai、anthropic、local 等 MODEL_PROVIDER=local # 如果走 API，填对应的 API Key API_KEY=your_api_key_here # 如果走本地模型，指定模型路径或模型名称 LOCAL_MODEL_PATH=/home/openclaw/models/qwen2.5-3b # 数据库连接（如果 OpenClaw 需要持久化） DATABASE_URL=sqlite:///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 首次启动与常见报错处理

配置好之后，启动 OpenClaw：

npm 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 ollama

4. 外网访问、进程守护与安全加固

4.1 让 OpenClaw 在外网可访问的正确姿势

OpenClaw 默认监听localhost或者127.0.0.1，这意味着只有服务器本机能访问。要让外网能访问，需要让它监听0.0.0.0。

在配置文件里把 host 改成0.0.0.0，或者启动时指定：

HOST=0.0.0.0 npm start

然后确认 Lighthouse 控制台的防火墙规则里，对应的端口已经放行。系统内的 ufw 也要放行。

做完这两步，理论上就可以通过http://你的公网IP:端口访问了。

但这里有一个非常重要的安全问题：直接把 OpenClaw 暴露在公网上，如果没有认证机制，任何人都能访问你的 AI 助手，甚至可能通过它执行一些敏感操作。所以强烈建议加一层反向代理和认证。

4.2 用 Nginx 做反向代理和基础认证

Nginx 可以做两件事：一是把 80/443 端口的请求转发到 OpenClaw 的内部端口，二是加上 HTTP Basic Auth，防止未授权访问。

安装 Nginx：

sudo 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

启用配置并重启 Nginx：

sudo 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 生态里最常用的选择。

安装 pm2：

sudo npm install -g pm2

用 pm2 启动 OpenClaw：

pm2 start npm --name openclaw -- start

查看状态：

pm2 status

查看日志：

pm2 logs openclaw

设置开机自启：

pm2 startup pm2 save

pm2 startup会输出一条命令，复制粘贴执行一下，pm2 就会在系统启动时自动拉起 OpenClaw。

pm2 还有一个好处是自动重启。如果 OpenClaw 因为某些原因崩溃了，pm2 会自动把它拉起来，保证服务可用性。

4.4 安全加固清单：别让服务器变成别人的肉鸡

云服务器暴露在公网上，安全加固是必须的。以下是我每次部署都会检查的几项：

第一，禁用密码登录，只用密钥。编辑/etc/ssh/sshd_config，把PasswordAuthentication改成no，然后重启 SSH 服务。这样暴力破解密码的攻击就无效了。

第二，修改 SSH 默认端口。把 22 改成其他端口，能减少大量自动化扫描。改完之后记得在 Lighthouse 防火墙和 ufw 里放行新端口。

第三，安装 fail2ban。它能监控登录日志，发现多次失败尝试就自动封 IP：

sudo apt install fail2ban -y sudo systemctl enable fail2ban sudo systemctl start fail2ban

第四，定期更新系统。设置自动安全更新：

sudo apt install unattended-upgrades -y sudo dpkg-reconfigure --priority=low unattended-upgrades

第五，最小化开放端口。只放行必要的端口，比如 SSH、HTTP、HTTPS。OpenClaw 的内部端口（比如 3000）不需要对外网开放，通过 Nginx 转发就行。

5. 模型接入的几种方案与实测对比

5.1 本地模型 vs 云端 API：怎么选

OpenClaw 的核心能力来自背后的模型。模型接入方式直接决定了使用体验、成本和隐私性。我把几种常见方案列出来对比一下：

本地模型的优势是数据不出服务器，隐私性好，而且没有按次调用的费用。缺点是模型能力受限于服务器配置，小模型在复杂任务上的表现和云端大模型有差距。

云端 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 的配置里，把模型接口指向 Ollama：

MODEL_PROVIDER=ollama OLLAMA_BASE_URL=http://127.0.0.1:11434 OLLAMA_MODEL=qwen2.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-size=4096 pm2 start npm --name openclaw -- start

Ollama 并发数。Ollama 默认同时只处理一个请求，如果多人使用会排队。可以调大并发：

OLLAMA_NUM_PARALLEL=2 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 的日志，三个地方看一遍，大部分问题都能定位到。改配置之前先备份，改完重启，验证，不行就回滚。这套流程看起来笨，但能避免很多"改着改着服务起不来了"的情况。