2026 OpenClaw Linux 雲主機最小暴露面：防火牆樣板、Gateway 回環綁定與 SSH 隧道管理面存取，對比 HTTPS 公網反代的決策矩陣與分級排障 FAQ

在公有雲 Linux 上跑 OpenClaw Gateway，常見風險是管理面與資料面混在同一監聽位址，再被安全組或本機防火牆誤放行。建議順序：防火牆預設拒絕 → Gateway 綁回環 → SSH 本地轉發接管理面；若必須對公網開 HTTPS，再用矩陣對照成本與風險。常駐與日誌分級可併讀 OpenClaw Linux 常駐排障：systemd、logs 與連接埠探測 FAQ。

防火牆樣板：預設拒絕＋白名單放行

除 SSH 與必要出站外一律關閉；Gateway 只聽回環時不必在公網安全組開 Gateway 埠。nftables 骨架如下（鏈名請對照發行版），重點是 policy drop 與明確放行 SSH。

# table inet filter { chain input { type filter hook input priority 0;
#   policy drop
#   ct state established,related accept
#   iif lo accept
#   tcp dport 22 accept   # 或你實際的 SSH 埠
# } }

ufw 請先 default deny 再白名單放行；IPv6 不用時應關安全組，避免雙棧漏封。雲廠商安全組與主機防火牆應同向收斂：安全組只放行 SSH（或跳板網段），主機層再細拆 loopback 與 established；避免「安全組全開、只靠 ufw」或反過來只改一層。

Gateway 綁定回環：把資料面留在本機

監聽設為 127.0.0.1（或 Unix socket）可避免誤設成 0.0.0.0 直曝公網。Nginx／Caddy 反代應 upstream 指回環並終止 TLS；管理 Web UI 不宜與公網入口共用同一監聽堆疊。若必須讓 Webhook 打到公網，建議把「入站 Webhook」與「管理 UI」拆成不同程序或不同路徑權限，降低單一埠被掃到後的橫向風險。

SSH 隧道管理面：本機瀏覽器接到雲上回環

例：ssh -L 18789:127.0.0.1:18789 user@vps -N，瀏覽器開 http://127.0.0.1:18789。建議 ServerAliveInterval、ExitOnForwardFailure yes。Telegram／Discord 通道權限見 OpenClaw Telegram 與 Discord 雙通道接入實操 FAQ，避免與管理 UI token 混放。

決策矩陣：僅回環＋SSH vs HTTPS 公網反代

實務上可先採「回環＋SSH」把行為跑穩，再評估是否真的需要公網 HTTPS：若只有少數管理員、且合規允許跳板，維持隧道往往比維護憑證與 WAF 更省心力；若必須對行動裝置或第三方 Webhook 開入口，再把 HTTPS 當成獨立專案做加固與監控，而不是預設選項。

分級排障 FAQ

L1 連通：隧道通了但頁面不行？本機與伺服器各跑一次 curl -v http://127.0.0.1:…，後者失敗代表 Gateway 未聽回環或未啟動。

L2 程序／防火牆：ss -lntp 若見 0.0.0.0，改 unit 與啟動參數鎖回環並複查安全組；日誌分級見常駐排障文。

L3 反代／TLS：502 間歇多為 upstream 埠錯、逾時過短或 ACME 續期寫錯 server 區塊。

每次變更監聽或反代後，用同一組 curl／ss 指令做「變更前後對照截圖」，寫進變更單，可大幅縮短下次值班的猜測時間。