已讀完三平臺安裝與 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 入門命令與平臺差異在哪裡看？
見《三平臺安裝與平臺選擇》；需要價格與區域時打開 租賃價格說明。