夜雨聆风最后一公里
前十七篇讲完了 OpenClaw 的每一个内部系统。现在回到最实际的问题：怎么让它跑起来，怎么让它健康地跑下去。
OpenClaw 支持三种部署路径，每种适合不同的场景：本地直接安装（适合实验、私人工作流和开发，上手最快，维护最少）；VPS 或云实例（适合 24 小时在线、多平台访问）；容器化部署（适合追求可重现的构建、依赖隔离和跨机器迁移的场景）。
选哪条路不是技术信仰问题，而是你对以下三个变量的权衡：稳定性需要（只在使用时跑，还是 7×24 在线）、硬件意愿（用已有的机器，还是专门买一台 VPS）、运维能力（接受 CLI 管理，还是需要更简单的方式）。
路径一：本地部署，五分钟上手
如果你只是想试用，或者工作流不需要 24 小时在线，本地直接安装是最快的路。
系统要求非常宽松：Node.js 22 或更高版本（node --version 确认），macOS、Linux、Windows 均支持，4GB 内存是舒适运行的下限，若要启用 Docker 沙箱需要额外安装 Docker Desktop 或 Docker Engine。
安装只需要一条命令：
npm install -g @openclaw/openclawopenclaw onboard
Onboarding Wizard 启动后按顺序引导你完成五个阶段（第三篇详细讲过），结束时 Gateway 已经在后台以 daemon 形式运行。macOS 上是 launchd，Linux 上是 systemd user unit，Windows 上是 Task Scheduler，各自实现开机自启。
完成后检查状态：
openclaw gateway status # Gateway 是否在响应openclaw channels status # 接入的通道是否在线openclaw doctor # 全面健康扫描
三条命令都绿，助手就绪。
本地部署有一个真实局限：笔记本合上之后，Gateway 在大多数系统上进入休眠，Telegram、WhatsApp 收到的消息不会被处理，直到你重新打开笔记本。如果这对你不可接受，就需要 VPS 部署或者一台长期开机的家用机（Mac Mini 是社区最常推荐的选项）。
路径二：VPS 部署，真正的 24 小时在线
VPS 部署模型提供真正的全天候可用性，让你能从任何地方访问 OpenClaw。一台 $6 美元一个月的 VPS——2 vCPU、4GB RAM、40GB SSD——足够跑一个单 Agent 实例，带三四个通道接入，没有 Docker 沙箱。启用 Docker 沙箱后 RAM 需求翻倍，建议 4GB 起步，多 Agent 并发时建议 8GB 以上。
社区实测成本最优的搭配：Hetzner CX22（2 vCPU、4GB RAM、约 $5/月）+ Caddy 反向代理 + Docker Compose。以下是一位社区成员记录的真实首次部署时间线：
第一天上午 10 点：克隆仓库，运行 ./docker-setup.sh，38 秒完成，容器自动启动。10 点 05 分：访问 Dashboard 报"unauthorized"，发现忘记在运行安装脚本前设置 OPENCLAW_GATEWAY_TOKEN。10 点 15 分：停止容器，设置环境变量，重跑安装脚本。Dashboard 加载成功，但出现"沙箱镜像缺失"警告。10 点 20 分：运行 ./scripts/sandbox-setup.sh 构建沙箱镜像，耗时 4 分钟。10 点 30 分：通过 Telegram 发送测试消息，3 秒内收到回复——第一次成功自动化。11 点：配置 Caddy 反向代理，忘记配置 WebSocket upgrade 头。
WebSocket upgrade 头是反向代理最常见的坑，Caddy 的正确配置：
openclaw.yourdomain.com {reverse_proxy localhost:18789 {header_up Host {host}header_up X-Real-IP {remote_host}transport http {versions 1.1 2}}}
Caddy 自动申请并续期 Let's Encrypt 证书，无需手动操作。Nginx 用户需要额外加 proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade" 三行，否则 WebSocket 长连接会被 Nginx 当成普通 HTTP 请求处理，导致连接在 60 秒后被强制断开。
VPS 上的 Gateway 绑定配置有一条铁律：不要把端口直接暴露给公网，使用反向代理，在 docker-compose.yml 里把端口绑定到 127.0.0.1:18789:18789 而不是 18789:18789。后者把端口暴露给所有网卡，包括公网 IP，任何人都能直接访问你的 Gateway API。
VPS 上的 Docker DOCKER-USER 防火墙策略需要特别注意：Docker 默认会修改 iptables 规则，可能绕过 ufw 等用户态防火墙。建议在 /etc/docker/daemon.json 里明确配置 "iptables": false，改用 nftables 或手动管理 DOCKER-USER 链，防止防火墙规则被 Docker 悄悄绕过。
路径三：Docker 部署，最可重现的环境
Docker 是可选的，只在以下场景下有意义：你想要一个隔离的、可随时丢弃的 Gateway 环境；或者你在没有本地安装的主机上运行 OpenClaw。如果你在自己的机器上运行，只想要最快的开发循环，用普通安装流程就好。
官方预构建镜像发布在 GitHub Container Registry，标签包括 latest、main、具体版本号（如 2026.2.26）：
docker pull ghcr.io/openclaw/openclaw:latest生产用途的 docker-compose.yml 最小配置：
services:openclaw-gateway:image: ghcr.io/openclaw/openclaw:latestcontainer_name: openclawrestart: unless-stoppeduser: "node:node" # 不以 root 运行ports:- "127.0.0.1:18789:18789" # 只绑定 loopbackenvironment:- OPENCLAW_AUTH_TOKEN=${OPENCLAW_AUTH_TOKEN}- ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}volumes:- ~/.openclaw:/root/.openclaw # 配置和状态持久化- ~/openclaw/workspace:/root/workspace # 工作区持久化healthcheck:test: ["CMD", "wget", "-qO-", "http://localhost:18789/health"]interval: 30stimeout: 10sretries: 3
有几条配置规则直接影响安全和稳定性。user: "node:node" 确保容器内进程不以 root 运行——以非 root 用户运行是 Docker 部署安全的最低基线。volumes 挂载必须同时挂载配置目录和工作区目录，缺少任何一个会导致数据在容器重建后丢失。restart: unless-stopped 确保容器在崩溃或 VPS 重启后自动恢复，而不是需要手动干预。
敏感环境变量不要写在 docker-compose.yml 里，用独立的 .env 文件：
# .env 文件，加入 .gitignoreOPENCLAW_AUTH_TOKEN=$(openssl rand -hex 32)ANTHROPIC_API_KEY=sk-ant-api03-...
Docker 部署有一个常见陷阱值得单独说：容器内没有 openclaw 命令可以直接敲，你需要通过 docker exec -it openclaw node openclaw.mjs <命令> 的方式调用 CLI。在 VPS 上创建一个 wrapper 脚本简化这个操作：
cat > /usr/local/bin/openclaw << 'EOF'#!/bin/bashdocker exec -it openclaw node openclaw.mjs "$@"EOFchmod +x /usr/local/bin/openclaw
之后 openclaw gateway status、openclaw channels list 等命令就能直接使用了。
路径四：Fly.io 托管，无服务器运维
对于不想管理 VPS 的用户，Fly.io 提供了最接近"托管 OpenClaw"的体验，官方仓库里有专门的 fly.toml 配置文件。
核心流程：
fly auth loginfly apps create my-openclawfly secrets set OPENCLAW_AUTH_TOKEN="$(openssl rand -hex 32)"fly secrets set ANTHROPIC_API_KEY="sk-ant-api03-..."fly volumes create openclaw_data --size 10 # 持久化存储fly deploy
fly.toml 里的几个关键配置：min_machines_running = 1 确保始终有一个实例在线（Fly 默认会在闲置后休眠实例）；[mounts] 把卷挂载到 /root/.openclaw；[checks] 配置 /health 健康探针，Fly 检测到不健康时自动重启。
Fly.io 的免费配额（2 个共享 vCPU、256MB RAM）不够运行 OpenClaw，建议用 shared-cpu-1x 配置（512MB RAM），约 $2-3/月。
仓库里还有 fly.private.toml，是私有网络部署的配置变体，Gateway 只在 Fly 的私有 6PN 网络里可见，不暴露公网端口，通过 WireGuard 隧道访问。
路径五：Nix 部署，声明式的极致
对 NixOS 用户或者追求完全声明式部署的人，github.com/openclaw/nix-openclaw 提供了 Nix flake 集成：
# flake.nix{inputs = {openclaw.url = "github:openclaw/nix-openclaw";};outputs = { nixpkgs, openclaw, ... }: {nixosConfigurations.myserver = nixpkgs.lib.nixosSystem {modules = [openclaw.nixosModules.openclaw{services.openclaw = {enable = true;package = openclaw.packages.x86_64-linux.openclaw;settings = {gateway.port = 18789;agents.defaults.model.primary = "anthropic/claude-sonnet-4-5";};};}];};};}
nixos-rebuild switch 之后，OpenClaw 作为 systemd 服务启动，配置由 Nix 管理，nixos-rebuild一键回滚，完全不需要手动操作配置文件。
openclaw doctor：诊断与自修复
无论哪种部署方式，openclaw doctor 是运维工具箱里最重要的单条命令。它执行超过 40 项检查，覆盖配置、网络、认证、沙箱、版本兼容性等维度：
openclaw doctor # 只检查，不修改openclaw doctor --fix # 发现问题后自动修复（需要确认）openclaw doctor --full # 包含耗时较长的深度检查
典型的输出片段：
✅ Gateway 正在运行（PID 42）✅ Auth token 已配置✅ 沙箱镜像：openclaw-sandbox:bookworm-slim（已找到）⚠️ Gateway 绑定：0.0.0.0（建议限制为 loopback 或 lan）⚠️ DM 策略：open（建议改为 pairing 或 allowlist）❌ Telegram channel：过期的 Bot Token（上次成功连接：72 小时前）
--fix 标志自动调整风险配置项，比如把 0.0.0.0 绑定改为 lan。但 --fix 不是万能药——它只处理配置层面的问题，通道 Token 过期这类需要重新授权的问题，还是需要人工操作。
doctor 还负责遗留配置迁移。每次大版本升级后，旧版本的配置 Schema 里可能有字段被重命名或移动。doctor 检测这些遗留字段，在 --fix 模式下自动把它们迁移到新位置，让你不需要手动翻阅 changelog 查找每个迁移点。
更新：三种频道，两种策略
OpenClaw 的更新频道通过 openclaw update --channel <频道> 切换：
stable 是默认频道，每次发布都经过完整的测试周期，适合生产部署。版本号格式是 YYYY.M.D，比如 2026.2.26。
beta 比 stable 提前几天发布，包含即将进入 stable 的功能，适合想早一点用到新特性但能接受偶发 bug 的用户。
dev 是每次合并 main 分支时自动发布的滚动版本，适合开发者追踪最新进展，不适合生产环境。
本地安装的更新：
openclaw update # 更新到当前频道的最新版本openclaw update --check # 只检查是否有更新，不安装
Docker 部署的更新更简洁：
docker compose pulldocker compose up -d
你的对话记录、设置和下载的模型存在 Docker volumes 里，跨更新持久保存。
更新的最佳实践是：每次更新后运行一次 openclaw doctor，确认更新没有引入配置不兼容问题。如果出现问题，openclaw gateway logs --lines 100 查看最近日志，定位具体错误。
健康监控：不要等到助手停摆才发现
一个真正在生产环境运行的助手，需要主动监控，而不是靠你偶尔发一条消息测试它是否还活着。
Gateway 健康探针：/health 端点返回 JSON，包含 Gateway 运行状态、连接的通道数量、活跃 Session 数。把这个端点接入你现有的 uptime 监控（UptimeRobot、Uptime Kuma、Better Uptime 等），Gateway 停响应时立刻告警。
通道健康检查：openclaw channels status 展示每个通道的最后成功连接时间。gateway.channelHealthCheckMinutes 配置项控制 Gateway 自动轮询通道健康的间隔，默认 5 分钟，发现断线自动重连。
模型认证监控（第十三篇提到过）：
0 9 * * * openclaw models status --check || \openclaw message send --channel telegram \"⚠️ 模型认证即将到期，请检查 /model status"
内存与 Session 增长：长期运行的实例需要定期检查 ~/.openclaw/ 目录的磁盘占用。Session JSONL 文件不设上限会无限增长，建议配置 session.maintenance.maxDiskBytes，或者手动定期运行 openclaw sessions cleanup。
日志轮转：Gateway 日志写到 ~/.openclaw/logs/gateway.log，默认没有自动轮转。在 Linux 上配置 logrotate：
~/.openclaw/logs/*.log {dailyrotate 7compressmissingoknotifempty}
备份：三个目录，一条命令
OpenClaw 的所有持久化状态集中在两个目录：~/.openclaw/（配置、Session、内存索引）和 workspace 目录（SOUL.md、AGENTS.md、Skills 等工作区文件）。
备份只需要这两个目录：
# 手动备份tar -czf openclaw-backup-$(date +%Y%m%d).tar.gz \~/.openclaw/ ~/openclaw/workspace/# 定时备份（每天凌晨 3 点）0 3 * * * tar -czf \~/backups/openclaw-$(date +%Y%m%d).tar.gz \~/.openclaw/ ~/openclaw/workspace/ \&& find ~/backups -name "openclaw-*.tar.gz" -mtime +30 -delete
把备份文件推到云存储（S3、Backblaze B2、rclone 支持的任何后端）是防止 VPS 磁盘故障的必要操作。如果你的 workspace 已经是一个 git 仓库（强烈推荐），workspace 的备份就等于 git push，不需要额外的 tar 命令。
跨机器迁移的步骤非常简单：在新机器上安装 OpenClaw，解压备份包覆盖 ~/.openclaw/ 和 workspace 目录，运行 openclaw doctor --fix 检查路径是否需要调整（特别是绝对路径引用），再运行 openclaw gateway start。迁移完成，对话历史、记忆、Skills、通道配置全部还原。
有几个字段在机器迁移后需要重新配置：Telegram 和 WhatsApp 的连接 Session（需要重新扫码登录）；设备节点的配对（新机器的 IP 变了，节点需要重新配对）；Tailscale 集成（新机器需要重新 tailscale up）。
常见故障排查速查表
Gateway 无法启动：openclaw gateway logs --lines 50 查看最近日志。90% 的情况是：端口 18789 已被占用（lsof -i :18789）；配置文件有 JSON 语法错误（openclaw config validate）；Node.js 版本低于 22（node --version）。
通道连接失败：openclaw channels logs --channel telegram --lines 30。常见原因：Bot Token 过期（重新从 BotFather 获取）；网络访问被防火墙屏蔽（检查 VPS 出站规则）；Webhook 类平台的回调地址不可达（检查反向代理配置）。
Agent 不回复消息：首先确认通道状态 openclaw channels status；再确认 dmPolicy 配置和你的账号是否在白名单里；发送 /status 命令——如果这个命令有回复但普通消息没有，说明 Agent 在执行时报错，查看 openclaw gateway logs。
内存占用持续增长：检查是否有长期运行的子 Agent Session 没有正常退出（openclaw sessions list --all）；检查 Docker 沙箱容器是否有残留（docker ps -a | grep openclaw-sandbox）；检查 QMD 内存后端的嵌入任务是否卡住（openclaw memory status）。
Docker 部署里 CLI 命令找不到：容器内没有全局 openclaw 命令，用 docker exec -it <容器名> node openclaw.mjs <命令> 代替，或者创建第三篇提到的 wrapper 脚本。
小结：一套值得长期运营的系统
这十八篇文章到这里走完了 OpenClaw 的全部重要系统。从一个奥地利开发者感恩节假期写出的一小时原型，到 33 万 Stars、600 位贡献者的开源项目，OpenClaw 的成功不只是时机好，更是因为它每一个设计决策都指向同一个目标：一个真正属于你的、在你的硬件上运行的、你能完全理解和掌控的 AI 个人助手。
部署是这个系统的最后一公里，也是很多人放弃的地方。但理解了前十七篇里的每一个组件是如何工作的，这最后一公里会变得非常具体：Gateway 监听 18789，Sessions 在 JSONL 文件里，记忆在 SQLite，Skills 在 Markdown，工具策略在 JSON5 配置——所有东西都是文件，都可以备份，都可以迁移，都可以用文本编辑器打开检查。
当你的助手在凌晨三点主动给你发来一条"今天的日历提醒：明早 9 点有重要会议"，它只是在执行一个定时任务，读了一份 Heartbeat Skill，调用了一个 Calendar API，通过 Telegram Channel Monitor 发出了一条消息。没有魔法，只是七个 JSONL 文件、一套 Session 锁、一个 WebSocket 连接、以及四层 System Prompt 叠加在一起运作的结果。
它不需要你完全理解所有细节才能工作，但在你需要的时候，每一个细节都在。
源码参考：docs/install/docker.md · fly.toml · fly.private.toml · scripts/docker/setup.sh · docs/platforms/ · github.com/openclaw/nix-openclaw基于 commit bf6ec64f 版本
——全系列完——
