企业官网建设流程全解析

最近我把一直在用的 OpenClaw 从本机迁到了云服务器，整个过程折腾了大概一个下午，中间踩了几个坑，最后把部署流程理顺了。OpenClaw 这个开源项目，说大不大，说小不小，它本质上是帮你把定时任务、回调通知、消息推送这类琐事统一管理起来的自动化入口。以前我习惯把它跑在笔记本上，但笔记本一合盖子，任务就全断了。迁到云上之后，7x24 小时在线，很多以前靠手工处理的活彻底解放。这篇云上 OpenClaw 部署指南，就是我基于实际操作的记录，不讲虚的，直接说怎么选服务器、怎么装环境、怎么把服务跑起来，顺便把最容易出问题的几个点都列出来，照着抄就行。

1. 先把 OpenClaw 看明白：它到底解决什么问题

1.1 OpenClaw 的定位与核心能力

OpenClaw 在我看来是一个“自托管的自动化服务网关”。通俗点说，它像一个在线管家：你告诉它什么时间干什么事，它到点就执行；外部服务发来一条通知，它负责收下并按照你设定的逻辑处理；你给它一个任务，它把结果推给你指定的地方。它不需要依赖任何第三方云平台，所有数据和配置都掌握在自己手里，这一点对注重数据归属的人来说很重要。

我实际用得最多的场景有三类：

• 定时任务：比如凌晨去抓取某几个数据源，生成日报后推送到自己的消息渠道。以前靠服务器 crontab，脚本一多就乱，现在统一丢给 OpenClaw 管理，状态清晰，还能在控制台看到每次执行结果。
• Webhook 接收：很多平台支持把事件回调到指定地址，OpenClaw 可以充当后端，接收后做过滤、格式化，再转发给最终目标。相当于把“第三方回调到业务处理”这一段链路打通了。
• 消息聚合：把邮件、系统告警、监控事件、订阅更新这些信息汇聚到一处，再由 OpenClaw 按重要级别分发。这样不用在几个应用之间来回切换。

它适合谁？适合开发者、个人站长、自动化爱好者，也适合小团队做内部工具后端。前提是你愿意花半小时做一次部署，之后能省下大量重复操作的时间。

1.2 云上部署和本地运行，差在哪

很多人一开始会觉得：一个开源工具，本地装个环境跑起来不就行了，为什么非要上云？我也这么干过，但实际用下来差距很明显。

本地运行最大的问题是“在线率”。你是用家里台式机跑还是笔记本跑？笔记本随时会休眠，公司网络和家里网络也会变。OpenClaw 这类服务如果只在局域网里用，那倒无所谓，可一旦要接收外部平台的 Webhook 回调，问题就来了：回调请求需要一个公网能访问到的地址，家里宽带没有固定公网 IP，运营商还可能隔段时间重新拨号，导致地址变化。云服务器有固定公网 IP，这个问题直接消失。

再就是稳定性。云服务器挂了可以自动重启，本地机器断电了只能等回家。把 OpenClaw 放在云上，最大的收益不是省电，而是“有一台机器专门为它待命”。我迁移之后最直接的体感是：再也不用担心电脑休眠导致凌晨任务漏跑了。

成本方面，我列一张简单的对比表：

如果你的 OpenClaw 只是在本机做实验，那本地跑没问题；但凡想正经用起来，让它接收回调、定时执行任务，直接放云上才是省心方案。

1.3 部署前必须想清楚的三件事

动手部署之前，建议先把三件事想清楚，不然后面会反复返工。

第一，域名。OpenClaw 的很多功能依赖公网回调地址，用 IP 加端口的方式也能访问，但证书不好办，后续维护也麻烦。最好准备一个域名，解析到你的云服务器公网 IP。不需要多贵，一个普通域名一年几十块，换来的是 HTTPS 和干净的访问地址。如果没有域名，后面 Webhook 那部分体验会很差。

第二，数据备份策略。OpenClaw 的配置、任务记录、日志都存放在数据目录里。容器本身可以随时删掉重建，但数据不能丢。部署前就要确定数据目录是独立的持久化目录，并且想好备份周期。我建议至少每周打包一次数据目录，上传到对象存储或者另一台机器。

第三，端口和安全规划。云服务器上不要一股脑把所有端口都暴露到公网。OpenClaw 的内部服务端口，最好的方式是只在本机回环地址上监听，然后让 Nginx 这类入口服务转发外部请求。公网只开放 80 和 443 就够了，其他端口一律关闭。这样即使 OpenClaw 有漏洞，攻击面也小很多。

2. 云服务器选型与初始化，这一步别省

2.1 配置怎么选：OpenClaw 需要多大资源

OpenClaw 本身不算重，但你要给它留够运行系统的余量。很多人在选服务器时容易走两个极端：要么买最低配 1核1G，结果跑起来内存吃紧；要么直接上 4核8G，资源又用不满。根据我的实测，1核1G 能跑，但一旦任务并发上来或者日志一多，很容易把内存耗尽，触发 OOM。正常使用，我更推荐从 2核2G 起步。

我一般按这个标准推荐：

带宽不用太高。OpenClaw 处理的多是请求和文本数据，不像视频或文件下载那样吃带宽，入站 1到3Mbps 足够，出站 3到5Mbps 也够用。磁盘方面，系统盘 40G 起步，建议另外挂载一个数据盘或者单独的数据目录，方便备份和扩容。

还有一点容易忽略：操作系统镜像。我推荐 Ubuntu 22.04 LTS，原因是文档多、软件源里的包比较新、Docker 支持好。不要选太冷门的发行版，遇到问题连搜索都不好搜。

2.2 从零初始化一台 Ubuntu 服务器

拿到服务器之后，第一件事不是急着装 Docker，而是先把系统基础配置好。我习惯按下面几步走。

第一步，用 SSH 登录服务器。如果你在云控制台创建时设置了 root 密码，可以直接ssh root@服务器IP登录。我更推荐创建时直接绑定密钥，这样安全级别更高，后面可以把密码登录关掉。

第二步，创建普通用户。OpenClaw 这类应用不要用 root 身份直接跑，权限太乱，出了问题也不好排查。执行：

adduser openclaw usermod -aG sudo openclaw

创建之后，以后都用这个用户登录，只有在需要管理员权限时才用sudo。

第三步，配置 SSH 密钥登录。把本地公钥加到服务器的~/.ssh/authorized_keys里，然后测试新用户能否正常登录。确认没问题后，再修改 SSH 配置文件，把密码登录关掉：

sudo nano /etc/ssh/sshd_config

找到PasswordAuthentication，改成no，然后重启 SSH 服务：

sudo systemctl restart ssh

这一步一定要在确认密钥能正常登录之后再做，否则容易把自己锁在外面。

第四步，更新系统并设置时区。新服务器拿到手，先更新一下软件包：

sudo apt update && sudo apt upgrade -y sudo timedatectl set-timezone Asia/Shanghai

时区一定要设对，因为定时任务依赖系统时间。如果你人在国内，却忘了设置时区，后面会发现所有定时任务都差了 8 小时。

第五步，开启防火墙。Ubuntu 自带的 ufw 够用，先放开 SSH、HTTP、HTTPS，其他端口先拦着：

sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable

注意，OpenClaw 的 8080 端口这里不用放行，后面我会让它只监听本机地址。

2.3 安装 Docker 与 Compose 插件

我为什么坚持用 Docker 部署 OpenClaw，而不是直接下载二进制包？因为依赖隔离太省心了。OpenClaw 可能有自己的运行时依赖，直接装到系统里，一旦版本冲突，排查起来很痛苦。用 Docker 之后，镜像里打包好了完整环境，宿主机只需要一个 Docker 引擎，升级就是换镜像，回滚也方便。

安装 Docker 可以直接用官方脚本：

curl -fsSL https://get.docker.com | sh

脚本跑完会自动添加好软件源并安装 Docker 引擎。然后设置开机自启并验证：

systemctl enable --now docker docker --version docker compose version

Compose 插件现在一般随 Docker 一起装好了，如果提示找不到，可以单独装：

sudo apt install docker-compose-plugin

装完做个检查：docker compose version能输出版本号就说明环境没问题。有些云厂商的镜像市场里已经预装了 Docker，那你直接跳到验证步骤就行。注意如果拉取镜像比较慢，可以在/etc/docker/daemon.json里配置你信任的镜像加速地址，然后重启 Docker。这一步不是必须的，但能省不少时间。

3. OpenClaw 容器化部署：30 分钟跑通

3.1 规划目录和端口

部署前先在服务器上建好目录。我习惯把应用统一放在/opt下面，好处是目录清晰、权限好控制。

sudo mkdir -p /opt/openclaw/data sudo chown -R 1000:1000 /opt/openclaw/data

为什么 chown 到 1000 这个 UID？因为容器里的 OpenClaw 服务通常以普通用户身份运行，而容器内的 UID 映射到宿主机是 1000。如果不改属主，容器写数据时很可能遇到权限不足，日志里会报 permission denied。

端口规划上，我的方案是：OpenClaw 容器内监听 8080，但宿主机只把 8080 映射到127.0.0.1。这意味着外部无法直接访问 8080，只有本机进程能连上。后面再用 Nginx 把 80/443 进来的请求转发到127.0.0.1:8080。这样设计后，公网攻击面被压缩到只剩 80 和 443 两个端口，安全很多。

3.2 编写 docker-compose.yml

切到/opt/openclaw目录，新建一个docker-compose.yml。我直接把我验证过的配置贴出来：

services: openclaw: image: ghcr.io/openclaw/openclaw:latest container_name: openclaw restart: unless-stopped ports: - "127.0.0.1:8080:8080" environment: - TZ=Asia/Shanghai - OPENCLAW_SECRET=请改成随机字符串 - OPENCLAW_DATA_DIR=/data volumes: - /opt/openclaw/data:/data logging: driver: json-file options: max-size: "10m" max-file: "3"

逐行解释几个关键配置。

restart: unless-stopped表示容器异常退出或服务器重启后会自动拉起。云服务器难免有重启维护的时候，加了这个参数，OpenClaw 不用手动启。

ports里写了127.0.0.1:8080:8080，前半部分指宿主机监听地址。给宿主机加了回环地址限制，就不会暴露到公网。如果你不小心写成8080:8080，那就等于把服务裸奔在网上，扫描机器人马上就会找上门。

OPENCLAW_SECRET是这个服务用来签名会话和校验请求的密钥，一定不能留默认值。生成随机串用一行命令：

openssl rand -hex 16

把输出结果填到环境变量里。密钥泄露意味着别人可能伪造请求，这一步不能偷懒。

OPENCLAW_DATA_DIR=/data是容器内数据目录的路径，它和宿主机/opt/openclaw/data通过 volumes 绑定。以后删掉容器重建，数据还在。

logging部分很容易忽略。Docker 默认会无限收集容器日志，时间长了磁盘会被撑满。我设置了单个日志文件 10MB、最多保留 3 个文件，这样 OpenClaw 跑一年也不会因为日志爆盘。

3.3 首次启动与初始化校验

配置文件写好后，启动服务只需要一句命令：

cd /opt/openclaw sudo docker compose up -d

首次启动会拉取镜像，时间取决于网络状况，耐心等一会。拉完镜像容器会自动创建并启动。接着看日志，确认没有报错：

sudo docker compose logs -f

日志稳定输出、没有红字报错，说明启动没问题。然后在服务器本机验证一下服务是否真的活着：

curl http://127.0.0.1:8080/healthz

正常会返回类似ok或一个 JSON 状态。这里强调的是“服务器本机”，因为你没有开放公网 8080，本地浏览器现在直接访问是打不开的，不用着急，下一步配置公网入口后就能访问了。

3.4 环境变量改完之后的正确重启方式

很多新手改完环境变量后习惯用docker restart，这其实是坑。restart 只会重启同一个容器，不会重新读取 compose 里的环境变量。正确做法是重新执行：

sudo docker compose up -d

Compose 检测到配置变化后，会重建容器。更保险一点可以加上--force-recreate强制重建。数据目录是挂载出来的，所以容器重建不会丢数据。如果你改了端口、镜像版本、环境变量，就用这种方式；如果只是临时想重启服务，才用docker compose restart。

4. 用 Nginx 做公网入口：域名、HTTPS、Webhook 接收

4.1 为什么公网入口必须单独加一层

有人会问：我已经在容器里映射了端口，直接把 8080 对公网开放不就行了？技术上可以，但不推荐。原因有三个。

第一，端口太容易被扫描。公网每天有大量扫描机器人，专门找非标准端口上的后台服务，一旦发现就会尝试爆破。直接把 8080 暴露出去，等于把 OpenClaw 的管理入口亮给全网看。

第二，没有 TLS。HTTP 明文传输，回调内容、任务结果、密钥信息都有可能被中间人截获。Webhook 回调地址如果走 HTTP，很多平台也会因为安全策略拒绝连接。

第三，入口统一。有了 Nginx 这一层，以后想加静态资源、访问限制、请求日志、限流，都是在入口做，不需要改 OpenClaw 本身。

我习惯把这个入口叫 Nginx 入口。你可以把它想象成小区门口的值班室：外部人员先在这个窗口登记，核实没问题后，才被引导到具体住户那里。OpenClaw 这个“住户”不需要和每一个来访者打交道。

4.2 安装 Nginx 并配置站点

先在服务器上安装 Nginx：

sudo apt install nginx -y sudo systemctl enable --now nginx

然后给 OpenClaw 建一个独立站点配置。我习惯在/etc/nginx/sites-available下创建文件，名字叫openclaw：

sudo nano /etc/nginx/sites-available/openclaw

写入下面这份配置：

server { listen 80; server_name openclaw.example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

其中server_name openclaw.example.com要换成你自己的域名。写完后把这个站点启用：

sudo ln -s /etc/nginx/sites-available/openclaw /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx

nginx -t是测试配置语法，如果有问题会直接提示，千万不要跳过。这里几个proxy_set_header的作用是让后端 OpenClaw 能看到真实访客 IP 和原始协议。不加的话，后端日志里所有请求来源都会变成127.0.0.1，而且当后面开了 HTTPS，OpenClaw 判断请求协议时会出错。

配置生效后，在浏览器访问http://openclaw.example.com，如果能看到 OpenClaw 的界面，说明方向对了。如果打不开，先检查域名解析是否已经指向服务器公网 IP，再检查服务器防火墙和云控制台安全组。

4.3 用 Certbot 快速上 HTTPS

HTTP 能访问只是第一步，接下来必须上 HTTPS。我用的方法是 Certbot 加 Nginx 插件，一条命令就能完成申请和自动配置。

安装 Certbot：

sudo apt install certbot python3-certbot-nginx -y

然后执行：

sudo certbot --nginx -d openclaw.example.com

按提示填一个接收续期提醒的邮箱，同意服务条款，Certbot 会自动完成证书申请并修改 Nginx 配置。执行完成后，再用浏览器访问就是 HTTPS 了。

验证自动续期是否配置好：

sudo certbot renew --dry-run

证书有效期一般是 90 天，Certbot 默认会通过系统定时任务自动续期。--dry-run能模拟续期过程，出现正常提示就说明以后不用担心证书过期。

别忘了在防火墙放行 HTTPS：

sudo ufw allow 443/tcp

最后，把 OpenClaw 里所有对外回调地址改成https://openclaw.example.com/...这种格式。很多平台校验 Webhook 时都要求 HTTPS，这一步不做，前面全部白费。

5. 上线后最容易踩的 5 个坑

5.1 容器起来了，但外网访问不了

我遇到过最典型的场景是：服务本地 curl 正常，域名也解析了，但外网就是打不开。这时候不要急，按顺序排查。

先看防火墙：

sudo ufw status

再确认云控制台安全组里是否放行了 80 和 443。这里是最容易漏的地方。服务器系统防火墙和云平台安全组是两层，只放行其中一层，外网流量还是进不来。

然后看监听端口：

sudo ss -tlnp | grep -E ':80|:443|:8080'

如果 8080 显示的监听地址是127.0.0.1:8080，说明没有暴露到公网，符合预期。80 和 443 正常监听，一般是 Nginx 在工作。最后再用curl -v http://127.0.0.1:8080/healthz确认后端正常。哪一步不通，问题就在哪一步。

5.2 打开页面报 502 或 503

502 和 503 的区别，很多新手会混淆。我遇到 502，多半是 Nginx 连不上后端容器。先检查容器状态：

sudo docker compose ps

如果容器显示未启动或反复重启，看日志：

sudo docker compose logs --tail=50 openclaw

日志里有权限报错，就去查数据目录权限；有端口占用，就检查映射关系。容器正常的话，在服务器上直接访问后端地址：

curl http://127.0.0.1:8080/healthz

能通，问题基本就在 Nginx 配置里的端口写错了。回到/etc/nginx/sites-available/openclaw检查proxy_pass是不是和 Docker 映射的宿主机端口一致。

503 一般比 502 少。如果你用了完整的upstream配置块，很可能是 Nginx 启动时后端服务还没准备好，或者在 Nginx 配置里proxy_pass http://openclaw_upstream;但 upstream 名字写错了。我的建议是像我上面那样直接用http://127.0.0.1:8080，少一层，也少一个出错点。

5.3 数据卷权限问题

容器运行正常，但 OpenClaw 日志里频繁出现写文件失败，这是典型的数据卷权限问题。

我之前就踩过：拉镜像时容器内用户 UID 和宿主机目录属主不一致，导致容器无法在挂载目录里创建文件。解决方法很直接：

sudo chown -R 1000:1000 /opt/openclaw/data

如果你不确定容器内用户 UID，可以在 compose 里显式指定用户：

user: "1000:1000"

这样宿主机目录属主和容器用户一致，问题就解决了。千万不要图省事，直接把整个目录chmod 777，虽然能跑，但等于把读写权限放给所有用户，一旦有别的进程被入侵，数据很容易被改。

5.4 日志把磁盘塞满

OpenClaw 跑了一段时间后，磁盘莫名其妙满了。我最早也中招过，后来才发现是 Docker 默认日志驱动没有上限，容器日志文件能涨到好几个 GB。

所以我在 compose 里提前加了日志限制：

logging: driver: json-file options: max-size: "10m" max-file: "3"

已经部署的应用，如果日志文件已经很大，可以手动清理：

sudo sh -c "truncate -s 0 /var/lib/docker/containers/*/*-json.log"

注意是truncate清零，不是rm。直接删文件可能会影响 Docker 对日志文件的占用，需要重启 Docker 才生效。另外建议定期用df -h看一眼磁盘占用，别等满了才处理。云服务器磁盘满了以后，服务可能直接拒绝写入，表现比宕机还难排查。

5.5 升级镜像后服务起不来

OpenClaw 更新版本时，我习惯这样操作：

cd /opt/openclaw sudo docker compose pull sudo docker compose up -d

但升级后就容易遇到新版本和旧配置不兼容，表现为容器启动失败或者反复重启。这时候先看日志：

sudo docker compose logs --tail=100 openclaw

如果日志提示配置项已经改名或者环境变量不再支持，最快的回滚方式是指定旧版本镜像。我在 compose 里通常只用latest，但回滚时可以直接覆盖镜像版本：

sudo docker compose up -d openclaw:上个版本号

当然，升级前备份数据目录是最稳妥的方案。再小的版本升级我都建议先打包一次数据，不然等启动失败再找备份就来不及了。

5.6 我的日常维护清单

这部分不是官方文档里的东西，就是我实际跑下来总结的习惯。

每天会扫一眼docker compose ps，确认容器是 Up 状态。如果发现容器不断重启，再去看日志，很多问题在早期只是一条 warning，拖久了才变成故障。

每周做一次完整备份。我一般用 tar 打包数据目录：

tar -czf openclaw-backup-$(date +%F).tar.gz -C /opt/openclaw data

然后把备份包传到另一台机器或者对象存储。云服务器本身可能出故障，所以备份一定不能只存在同一台机器上。

升级前一定再备份一次。版本升级是风险最高的操作，多花一分钟备份，能省掉一整晚的恢复时间。

还有个小技巧：给 OpenClaw 的每个长耗时任务设置合理超时，避免几个任务同时跑的时候把内存占满。云服务器内存一旦爆掉，容器 OOM 重启，任务执行记录可能就丢了。宁可让单个任务失败重试，也不要让整体服务被拖垮。

我个人最后想说的是，OpenClaw 这种东西，本地跑通只是开始，真正让它产生价值的是“长期在线”。云上部署看着多花了一点服务器成本，但换来的省心事远不止这些。照着这套流程跑一遍，你也能把它稳稳放在云上。