已經能裝 OpenClaw、但不想把 Gateway 直接綁在公網介面的開發者，常在 Ubuntu 24.04 這類 VPS 上卡住：監聽位址怎麼選、systemd 如何做到可預期的重新啟動、Cloudflare Tunnel（或等效方案）怎樣只把回環連接埠暴露給受控網域名稱。本文提供與 Docker 正式環境篇、三平台安裝篇互補的「裸機 + 系統服務 + 通道」路徑：環境基準線、Gateway 設定要點、Unit 範例、通道路由與依症狀排除，並一併說明與穩定遠端 Mac 常駐結合的常見拓撲。
三平台安裝篇負責把「能跑起來」的入口講清楚；Docker 正式環境篇適合已容器化、希望用 Compose 或編排平台統一交付的團隊。本文面向另一類讀者：希望在裸機 Ubuntu 24.04上以最少抽象層跑 Gateway，用 systemd 承接當機復原與開機自動啟動，再用 Cloudflare Tunnel（或自建反向代理）把 TLS 與存取控制從應用程式裡抽離。三條路徑並非互斥——您可以先在裸機跑通，再決定是否映像化。
以下六個痛點，是我們在排除障礙工單裡最常見的「認知差」。對齊之後，後面的檢查表才有意義。
把「能 curl 通」當成「正式環境安全」：在 0.0.0.0 上開監聽而不做前段代理，等於把驗證與 TLS 全部壓在應用程式預設值上；一次設定漂移就可能被整網掃描。
忽略 Node 執行階段與 glibc 的耦合：Ubuntu 24.04 上混用舊版預編譯二進位或錯配 NODE_OPTIONS，會出現「本機能跑、服務起不來」的假陽性。
工作目錄與權限隨手寫在 /root：升級指令碼或日誌輪替一旦改權限，Gateway 讀設定失敗會在 systemd 裡表現為連續重新啟動，日誌卻被淹沒在上層。
健康檢查只測行程在不在：不驗證 HTTP 就緒與上游模型連通性時，負載平衡仍會把流量打進來，通道側卻回傳 502，排除方向會完全跑偏。
通道通了但路由指錯連接埠：cloudflared 的 ingress 與 Gateway 實際監聽不一致時，外網網域名稱能解析、內網卻永遠連不到正確回環連接埠。
把 Linux 閘道當「全能執行機」：需要 Xcode、模擬器或 Apple Silicon 特性的工作硬塞在 VPS 上，會把問題偽裝成「OpenClaw 不穩定」，本質是拓撲放錯層。
讀完本節，您應能判斷是否要走「回環監聽 + 通道」這條線；若答案是肯定的，請繼續看環境與分步指令。
選型時別只比較「安裝快不快」，要把攻擊面、可觀測性、復原／回滾路徑放在同一列。下表用於審查對齊，連接埠與映像版本請替換為您環境內的真實值。
| 維度 | Gateway 直綁公網 | Docker / Compose 正式環境 | systemd + 回環 + Tunnel |
|---|---|---|---|
| 暴露面 | 最大；依賴應用層 TLS 與防火牆規則 | 由 publish 連接埠與網路模式決定，易誤設 host 網路 | 行程僅監聽 127.0.0.1；公網入口在通道或邊緣 |
| 憑證與網域 | 需自建 ACME 或手動輪替 | 常外掛 Traefik / Caddy 或雲端 LB | Cloudflare 邊緣終止 TLS（或等效） |
| 重新啟動與排除 | 依賴外部守護或手動 | restart policy + 日誌驅動需另行設計 | systemd 內建重新啟動策略與 journal 順序清楚 |
| 適合團隊 | 極簡 PoC，不建議正式環境 | 已有容器規範與映像供應鏈 | 單台 VPS、要可指令碼化重現的中小團隊 |
正式環境閘道的關鍵不是「能不能存取」，而是「誰在什麼路徑上被授權存取」——把監聽縮到回環，是把這個問題從應用程式挪到更擅長的邊緣層。
以 Ubuntu 24.04 LTS 為例，建議跟隨 Node.js 目前 LTS 主版本（截至 2026 年初通常為 22.x 或官方文件建議線，請以 nodejs.org 為準），nvm、fnm 或 NodeSource 皆可，但正式環境請固定 minor 版本號並記錄升級窗口。系統套件管理員裡的 node 往往偏舊，不適合作為 Gateway 的唯一來源。
防火牆基準線建議：SSH 僅金鑰、ufw 預設 deny incoming，不要為 Gateway 業務連接埠開公網規則——外網只走通道。若必須直連除錯，用限時白名單或跳板機，並在變更紀錄裡寫明撤銷時間。
建立專用使用者與目錄：例如 openclaw 使用者，家目錄外另建 /var/lib/openclaw 存執行狀態，/etc/openclaw 存設定（權限 640／目錄 750），避免混在 root 下。
安裝固定版 Node 與套件鎖定檔：在儲存庫或部署機保留 package-lock.json／pnpm-lock.yaml，正式環境安裝使用 npm ci 或等效，杜絕「裝套件時順手 major 升級」。
驗證 glibc 與原生相依性：若 Gateway 依賴帶原生擴充的模組，先在目標機執行一次乾淨安裝與冒煙指令碼，確認無 dlopen 失敗。
設定時區與日誌時間：timedatectl 設為 UTC 或團隊統一時區，便於與通道與邊緣日誌關聯。
啟用 ufw 基準線：ufw allow OpenSSH 後 ufw enable；業務連接埠保持關閉，確認 ss -tlnp 中外網側看不到 Gateway 監聽。
預留健康檢查端點：在正式掛通道前，用 curl -fsS http://127.0.0.1:PORT/health（路徑以您的設定為準）寫進 Runbook，確保與 systemd 的 ExecStartPost 或外部探針一致。
提示：OpenClaw 具體子命令與設定檔名稱以官方文件為準；下文 Unit 與 YAML 中的路徑、連接埠均為可替換占位，請依實際安裝位置修改後再啟用。
監聽位址：正式環境建議 127.0.0.1:PORT，必要時可再加 Unix domain socket（若您的版本支援）。權杖：透過環境檔注入，拒絕寫進 world-readable 的設定；輪替時先寫新權杖、滾動重新啟動、再刪舊權杖。健康檢查：至少涵蓋行程存活、HTTP 就緒與「能到達模型控制面」三層中的一層半——否則通道只會告訴您「連不上」，不會告訴您「連錯層了」。
[Unit] Description=OpenClaw Gateway (loopback) After=network-online.target Wants=network-online.target [Service] User=openclaw Group=openclaw WorkingDirectory=/var/lib/openclaw EnvironmentFile=-/etc/openclaw/gateway.env # 請將 ExecStart 換成官方文件中的實際啟動命令 ExecStart=/usr/bin/node /opt/openclaw/gateway.mjs --config /etc/openclaw/gateway.yaml Restart=on-failure RestartSec=5 LimitNOFILE=1048576 # 日誌：優先 journal；如需檔案，搭配 logrotate 與權限 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target
啟用順序建議：systemctl daemon-reload → systemctl enable --now openclaw-gateway → systemctl status 看主行程是否穩定 → 本機 curl 健康檢查 → 再啟 cloudflared。
tunnel: <YOUR_TUNNEL_ID>
credentials-file: /etc/cloudflared/<YOUR_TUNNEL_ID>.json
ingress:
- hostname: claw.example.com
service: http://127.0.0.1:8787
- service: http_status:404
注意：通道憑證 JSON 權限應限制為 root 或專用使用者可讀；不要把憑證打進應用程式映像層或公共 CI 日誌。若使用自建 Nginx／Caddy 代替 Cloudflare，同樣保持「邊緣終止 TLS、上游僅回環」的結構即可。
日誌檢視順序（排除時依序掃一遍）：① journalctl -u openclaw-gateway -b --no-pager 看當機循環與環境變數是否載入；② 應用程式自身日誌目錄（若有）；③ journalctl -u cloudflared 或等效通道服務；④ 最後用 curl -v 從本機與外網各測一次，區分「行程問題」與「路由問題」。
連接埠類：EADDRINUSE 先用 ss -tlnp 找佔用者，確認不是上一次殭屍行程；改連接埠後記得同步通道 ingress 與內部探針。權限類：EACCES 查設定與金鑰檔案的 owner／group，systemd 的 User 必須與可讀身分一致。通道未通：外網 502 而本機 curl 正常，優先查 ingress 規則、通道行程是否連上 Cloudflare、以及 DNS 是否指到正確 zone。模型連通性：Gateway 日誌若出現逾時或 401，先在伺服器上直接 curl 模型供應商的基準介面（注意別把金鑰寫進 shell history），排除「出口 IP 被擋」與「權杖過期」。
典型拓撲是：Linux VPS 承載對外 Gateway、佇列與輕量編排；穩定遠端 Mac（實體 Apple Silicon）承載 Xcode 建置、模擬器與僅 macOS 可用的工具鏈。Gateway 收到工作後，將重活分發到 Mac 執行層——這樣既滿足「閘道不直出公網」的安全訴求，又不在 Linux 上硬跑不擅長的工作負載。站方可把 Mac 當作可訂購的執行節點，把 Linux 當作您自管的控制面，兩者用 SSH、佇列或內網通道銜接均可，關鍵是把失敗域切開：閘道掛了不影響 Mac 上既有建置快取，Mac 維護窗口也不應拖垮整個 API 入口。
127.0.0.1＋單一連接埠，避免雙疊誤監聽 IPv6 全網卡。Restart=on-failure 配合 RestartSec=5，比無限瞬啟更容易留下可讀日誌；必要時加 StartLimitIntervalSec 防止雪崩。http://127.0.0.1:PORT 而非 localhost，減少解析到 IPv6 ::1 而應用程式只綁 IPv4 的坑。單純「一台 Linux VPS＋通道」適合控制面與 API 聚合，但在 iOS CI／CD、模擬器、Metal 與 Xcode 鏈上會遇到硬邊界：要麼接受遠端無頭環境的相容性折損，要麼持續投入額外映像與維護人力。相較之下，把重活放在可獨占、可預期維護窗口的 Apple Silicon 遠端 Mac上，閘道層繼續用您熟悉的 systemd 與通道方案，整體失敗域更清晰。對於需要長期穩定跑 Agent 與建置流水線的團隊，NodeMini 的 Mac Mini 雲端租賃通常是更優解——控制面仍可放在自管 VPS，執行面則交給與 Apple 生態對齊的硬體與租期組合。
正式環境強烈建議只監聽回環，由通道或反向代理承接 TLS 與存取策略。若必須對公網開放連接埠，應疊加防火牆白名單、限流與稽核；複雜度通常高於通道方案。更多 OpenClaw 主題文章見 OpenClaw 專欄。
先在伺服器本機 curl 回環位址確認 Gateway 真就緒；再查通道服務的 ingress 與憑證；最後才懷疑上游模型或 DNS。訂購執行節點前可先看 租賃價格說明 對齊租期與地區。