已读完三平台安装与 Docker 生产篇、但仍希望把 OpenClaw Gateway 以裸机 Node + systemd跑在 Ubuntu 24.04 VPS 上，并用 Cloudflare Tunnel（或同类隧道）避免网关直接对公网监听？本文给出与 Docker 路径的分工、痛点拆解、两张对照表、systemd 与隧道配置示例、六步落地 Runbook、三条硬口径，并链至《装后排错》《Docker 生产篇》与《三平台安装》，便于可复盘上线。
裸机部署把依赖版本、文件权限、监听地址与进程守护全部压回宿主机。若仍沿用开发笔记本上「临时前台跑 Gateway」的习惯，VPS 重启后服务消失、journal 里没有结构化字段、安全组与 ufw 规则不一致，都会让排障变成口述历史。📌 先把下面六类痛点拆开，再复制粘贴配置片段。
sudo npm i -g 升级，生产与文档不一致；应在 systemd 里显式 ExecStart 使用固定 Node 路径或版本管理器提供的 shim。0.0.0.0 时，若防火墙漏一条规则即对全网暴露控制面；与隧道联用时通常应退回 127.0.0.1，由隧道进程做入站。openclaw，会出现「手动能跑、服务起不来」的经典权限差。cloudflared 指向错误本地端口时，外网 502 与 Gateway 日志无关，容易误判为模型超时。ExecStart 与配置哈希，失败时无法分钟级退回。下面两张表把「Docker vs 裸机」与「隧道 vs 直连反向代理」压成评审材料。
与《进阶实战：Gateway 安全与 Secrets》的关系是：进阶篇讲令牌、暴露面与 Secrets 轮换；本篇讲在 Linux 宿主机上如何把监听面收敛到回环并交给隧道，两者叠加才能形成「入口在边缘、密钥在仓库、进程在 systemd」的闭环。若尚未完成 onboard 与模型密钥配置，请先回到三平台安装篇把最小可运行路径走通，再切到本文做生产化。
《Docker 与 Gateway 生产篇》覆盖镜像固定、卷挂载与 Compose 回滚；本篇覆盖宿主机服务单元 + 隧道。表 1 用于架构评审，不是非黑即白的站队。
| 维度 | Docker / Compose（站内生产篇） | 裸机 Node + systemd（本文） |
|---|---|---|
| 复现性 | 镜像与 digest 可锁定，环境一致性强 | 依赖宿主机软件栈，需要用配置管理与版本钉扎补偿 |
| 排障粒度 | 先查容器日志与卷权限，再进 exec | 可直接 strace/systemtap（若组织允许），适合短期深度排障 |
| 与现有运维工具 | 需容器监控与镜像仓库流程 | 沿用 journald、Prometheus node_exporter、既有备份脚本 |
| 升级路径 | 换镜像 tag / digest，卷迁移清晰 | Node 与全局包联动升级，需要回滚脚本 |
| 典型适用 | 团队已容器化、要统一运行时 | 必须跑在裸机、或与遗留 systemd 服务强耦合 |
隧道把 TLS 与公网入口交给云边缘；Nginx/Caddy 常在 VPS 本机终止 TLS 并反代到回环口。二者可组合，但监听面必须只开需要的最小集合。下表用于与安全组规则对照。
| 模式 | Gateway 监听 | 公网暴露面 | 运维注意点 |
|---|---|---|---|
| 隧道 → 本机回环 | 127.0.0.1:PORT（PORT 以 OpenClaw 文档为准） | 无直连 Gateway 端口；仅有隧道进程出站 | 校验隧道配置文件 ingress 与本地服务端口一致 |
| 本机 Nginx/Caddy 反代 | 通常仍建议回环上游 | 443 由反代监听；需证书续期与限流 | 与 ufw、云安全组三重核对，避免重复开放 |
| 不推荐：Gateway 直连 0.0.0.0 | 全网卡监听 | 控制面直接对公网 | 除非叠加严格令牌、IP 允许列表与 WAF，否则攻击面过大 |
# /etc/systemd/system/openclaw-gateway.service（示例骨架，ExecStart 以官方 CLI 为准） [Unit] Description=OpenClaw Gateway (bare metal) After=network-online.target Wants=network-online.target [Service] User=openclaw Group=openclaw WorkingDirectory=/var/lib/openclaw Environment=NODE_ENV=production # 使用固定 Node 绝对路径，避免 PATH 漂移 ExecStart=/usr/bin/node /path/to/openclaw/cli.js gateway start --bind 127.0.0.1 Restart=on-failure RestartSec=5 LimitNOFILE=65535 [Install] WantedBy=multi-user.target
# cloudflared config 片段示例：将公网主机名转发到本机 Gateway
tunnel: <your-tunnel-id>
credentials-file: /etc/cloudflared/<tunnel>.json
ingress:
- hostname: claw.example.com
service: http://127.0.0.1:18789
- service: http_status:404
注意：示例中的端口与可执行路径仅为占位；上线前必须以当前 OpenClaw 版本文档与 openclaw --help 输出为准，并在变更单里记录哈希与回滚命令。
openssl 版本；与《三平台安装》对齐最低 Node 要求。home 下却用 root 启动。127.0.0.1 后用 curl 或文档中的健康检查路径探活，再套隧道。systemctl daemon-reload && systemctl enable --now；用 journalctl -u openclaw-gateway -f 观察启动顺序错误。ExecStart 与配置 tarball；升级失败时能在目标 RTO 内切回。落地时建议把本机探活与隧道外侧探活写成两条独立的健康检查：前者只验证 Gateway 进程与回环端口；后者验证 DNS、证书链与边缘路由。发布变更时若只更新其中一条，容易出现「内网绿、外网红」的误判。另可在工单模板中强制填写「OpenClaw 版本号 + Node 次版本 + cloudflared 版本」，避免口头对齐，并保留 journal 导出片段便于审计留痕。
curl -v 127.0.0.1:PORT 再查隧道日志；本地不通＝应用层，本地通外网不通＝隧道或 DNS。补充：在仅跑 Gateway 与隧道的轻量 VPS 上，CPU 看似闲置但延迟抖动时，优先查单进程文件描述符上限、长连接与 WebSocket 会话数以及到模型供应商的 TLS 往返，而不是先加 vCPU。
仅租用一台通用 Linux VPS 能跑通 demo，但休眠策略、磁盘 IO 波动、与桌面环境无关的 headless 约束仍会影响长期自动化。要把 OpenClaw 当生产工作流的一部分，需要可重复的进程守护、可审计的监听面、以及与团队现有 CI/密钥流程对齐。
若同时还要跑 iOS 构建、模拟器或图形化排错，Linux VPS 无法替代 Apple Silicon 环境；许多团队会把Gateway 放在 Linux 边缘、把重构建与 Xcode 任务卸载到远程 Mac。纯靠临时笔记本或碎片化桌面，很难为 7×24 的 Agent 与无人值守任务提供稳定执行层：合盖休眠与权限弹窗会持续消耗排障人时。MACCOME 提供多地区 Mac Mini M4 / M4 Pro 物理节点，适合作为 OpenClaw 的构建与常驻执行后端；边缘 Linux 负责隧道与入口收敛时，远程 Mac 负责 Apple 工具链与长期会话。可先查阅 帮助中心，再按 租赁价格 与区域公开页落单。
试点建议：先在短租节点验证「隧道 + 远程 Mac 侧任务」的端到端延迟，再决定是否把 Gateway 与构建角色拆到不同机器，避免单点既跑入口又跑重编译。
常见问题
Docker 生产篇已经够用，为什么还要裸机 systemd？
容器路径适合复现与隔离；裸机路径适合与现有 systemd/备份/审计强耦合或需要宿主机级排障的场景。可对照《Docker 生产篇》选型，不必二选一。
Gateway 应该用 127.0.0.1 还是 0.0.0.0？
配合隧道或本机反代时优先回环监听，缩小暴露面；若必须直连公网，需叠加防火墙、令牌与监控。装后验证见《doctor 与排错篇》。
OpenClaw 入门命令与平台差异在哪里看？
见《三平台安装与平台选择》；需要价格与区域时打开 租赁价格说明。