你已在 VPS 或家裡伺服器上跑起 OpenClaw Gateway，卻不想把 18789 埠位暴露到公網；又希望筆記型電腦、另一台 Linux 或手機節點能像連內部服務一樣接 CLI／WebSocket。本文以 Tailscale 私網通道＋預設迴環綁定說明拓撲邊界、權杖與環境變數、遠端 CLI 檢查清單，並專章拆解「通道通、RPC／工作階段卻不對勁」的分流排錯。讀畢可對齊與站內 Cloudflare Tunnel＋systemd 篇的分工，以及在重負載情境如何自然銜接 獨佔遠端 Mac 算力。
OpenClaw Gateway 預設把控制面綁在 127.0.0.1，本質是把可攻面壓在作業系統已承諾的邊界內：只有本機程序能直接觸及 WebSocket／HTTP 控制面。許多初部署的人為了「遠端也能 openclaw」直接把監聽位址改為 0.0.0.0，再用手寫防火牆補洞──在示範環境可行，在正式或長期執行場景卻會把未授權掃描、權杖外洩、CORS 誤設一併放大。
掃描面以指數成長：一旦埠位對公網可連，自動化掃描會在幾小時內上門；即使用了強權杖，日誌也會充滿雜訊，SOC 警示難以收斂。
和「最小可攻面」安全文的假設衝突：站內《閘道安全加固》強調迴環、權杖輪換與執行審批；把 bind 打開到全網，等同自廢第一層門檻。
分流的訊號被汙染：公網路徑上還有 CDN、業者 NAT、公司 Proxy；你會以為是 OpenClaw 出問題，實則是 half-close、MTU 等層層雜訊。
法遵稽核難寫清楚：「誰從哪個公網 IP 連進 Agent 控制面」要對應到自然人很痛；在私網 tailnet 內，機身身分＋ACL 比較好寫進內部規程。
多 Gateway 拓撲更難收斂：同一台主機上再跑第二個實驗實體時，埠位碰撞與權杖混用機率陡升。
和遠端 Mac 應用情境不一致：真正需要長期算力的是 Xcode、模擬器與大容量快取；閘道較宜維持輕量，把重活排程到獨佔節點。
比較穩的模型是：維持 Gateway 在 loopback，以受管網路層（Tailscale 等）解決可達性。這和只把資料庫綁 127.0.0.1 再經由 SSH 通道存取，是同一類習慣。若你較熟 Cloudflare Tunnel，可先對讀 Linux VPS＋systemd＋Cloudflare Tunnel 以理解「邊緣入口」和本文「純 tailnet」的差別。
| 面向 | Loopback＋Tailscale | 直接 bind 公網 | Cloudflare Tunnel |
|---|---|---|---|
| 信任模型 | 以 tailnet 身分＋ACL，預設走私網 | 仰賴防火牆＋權杖，可攻面大 | 以邊緣身分與 Tunnel 憑證為主，偏公網入口 |
| 維運負擔 | 中：要顧好 ACL 與主機名稱 | 起步低，長期風險高 | 中至高：DNS、憑證、回源策略 |
| 與 OpenClaw 預設設定的契合度 | 高：通常不必改 bind | 低：常誘導大開 bind | 中：Tunnel 指回 loopback 埠位 |
| 常見使用情境 | 個人與小型團隊的內部編排 | 不建議作為正式上線主路徑 | 需從公網做受控入口者 |
「通道只解路由問題，不取代驗證；權杖與執行審批一樣要全開。」
Tailscale 的價值在於把多裝置收進單一信任域，讓你能用穩定主機名去連 100.x 區段；它不會自動取代閘道端的權杖。若你 ACL 放太寬（例如 *:*），等於在 tailnet 內部複製了一個「小公網」。
在 2026 年常見拓撲裡，也會遇到子網路路由（subnet router）與 exit node：前者讓沒有裝 Tailscale 的內部網段仍能被 tailnet 碰到；後者讓指定裝置的出口流量交另一部機轉送。若 Gateway 和資料庫同在一個雲專有網路裡，而你的筆電只上 tailnet，就該釐清「哪些來源能進 DB 埠」──否則會出現「Gateway 本機 curl 得到 DB、遠端 CLI 卻間歇 500」的錯覺，本質是 ACL 或路由不對稱。
另一個高頻細節是 MagicDNS 與搜尋網域：有些企業網路會把 *.ts.net 解析劫持到內部 DNS；排錯時可在筆電上同時以 dig 對公眾與尾網內建解析比對，避免把「DNS 混用」誤當成 OpenClaw 工作階段異常。把結論寫進維運手冊後，新成員 on-boarding 能省掉反覆踩坑。
在 Gateway 主機上安裝並登入 Tailscale 之後，先在同一 tailnet 的筆記型電腦上驗證 ping 與 tailscale ping 的 RTT；再到 Admin 主控台核對：節點是否打上正確 tag、是否啟用 MagicDNS，以及 ACL 是否明確允許從維運子網到 Gateway 角色上的 TCP 18789（或自訂埠位）。
// ACL 片段示範：只允許帶 tag:ops 的機器連到 Gateway 節點的 18789
{
"groups": { "group:ops": ["alice@github", "bob@github"] },
"tagOwners": { "tag:gateway": ["group:ops"] },
"acls": [
{
"action": "accept",
"src": ["tag:ops"],
"dst": ["tag:gateway:18789"]
}
]
}
注意：上例只說明形狀。實際 ACL 還要覆蓋 exit node、子網路路由與手機節點的最小權限；變更後務必在測試裝置上重連 tailnet 再驗一次。
建議驗收清單寫入變更單：① Gateway 程序仍聽在 127.0.0.1:18789；② 從維運機在「不靠 SSH 本機轉送」的情況下，應能經由 tailnet IP 打到同一份健康檢查端點（實際路徑依你的部署版本而定）；③ 雲上安全性群組或家裡 router 的公網入站關掉對 18789 的放行。若希望對照「渠道路徑不進訊息」的題型，可讀 channels 探針與 dmPolicy 門控 專文。
以下假設主機上 openclaw doctor 已全綠；若尚未完成首跑，請先讀 全平台安裝與首跑排錯 再回本文。
確認監聽位址：在伺服器上執行 lsof -nP -iTCP:18789 -sTCP:LISTEN，應看到綁在 127.0.0.1。若變成 *:18789，先還原設定再談通道。
釘死權杖來源：優先以環境變數 OPENCLAW_GATEWAY_TOKEN 注入，避免把長效密鑰寫進可能同步的設定庫。
在筆電設定 remote：於客戶端 ~/.openclaw/openclaw.json 增加指向 tailnet 主機名與埠的 remote 區段（欄位名以目前 CLI 說明為準），且 WebSocket URL 用 ws:// 或 wss:// 與內部政策一致。
一併匯出埠位變數：非預設埠時，讓 OPENCLAW_GATEWAY_PORT 在服務端與客戶端工作階段一致，避免「doctor 過了、遠端 CLI 卻打錯埠」。
釐清 TLS 終止點：若在 tailnet 內又套了本機反向代理，要確認 WebSocket 升級標頭沒被中間層剝除。
把一次成功工作階段的日誌指紋留底：同一份工單內同時放 gateway status、doctor 與失敗重現，日後升級版本才好對照。
// 客戶端 ~/.openclaw/openclaw.json 示意（欄位以官方 CLI 為準）
{
"gateway": {
"remote": {
"url": "ws://openclaw-gateway.tailnet-1234.ts.net:18789",
"token": "use-env-or-osx-keychain-instead-of-plaintext"
}
}
}
提示：不要讓閘道與大型編譯或重檔案工作綁死在同一台小記憶體 VPS；當 Agent 要長期跑 xcodebuild 或大型依賴快取時，較穩的是把執行面放到獨佔遠端 Mac，閘道只做工作階段與工具編排。選型可先參考 租賃價格說明 對照磁碟與地區方案。
| 現象 | 優先懷疑 | 建議動作 |
|---|---|---|
| tailscale ping 通、CLI 卻逾時 | 埠位未進 ACL，或本機防火牆未放行走迴環轉送鏈 | 先在伺服器本機驗證 loopback，再一層層向外 |
| HTTP 401／驗證失敗 | 權杖不一致、環境變數未匯入 systemd 單元 | 對齊 unit 的 Environment= 與目前 shell 設定 |
| WebSocket 立刻斷／gateway closed(1000) | 小版升級後 scope 或工作階段不相容 | 對照站內 gateway closed 排錯文收斂權杖與 scope |
| 渠道路在、訊息不進 | 未配對／dmPolicy 擋下 | 執行 channels 探針子指令並對照政策表 |
若在升級閘道小版後，突然變成「同一 ACL、同一權杖，卻只有遠端 CLI 能重現」的狀況，優先比對發行說明裡的破壞性變更與預設埠表，再回退到上一個已知正常版本做二分法；在還沒釐清監聽矩陣前，不要反覆亂改 ACL，否則工單只會充滿假陽性。
18789 作多工控制面（以發行說明為準）；若改埠，systemd、Docker Compose 與客戶端 remote 三邊要同步，否則排錯容易卡在「半套程序讀到舊埠」。tag:gateway 等標籤後，ACL 行數會隨團隊線性成長；維運手冊要寫死「人員離職即刪機＋撤銷尾網裝置」的固定步驟。只仰賴直接公網 bind 或過寬的 tailnet ACL，在 2026 年都容易把 Agent 控制面推進難以稽核的狀態；而把所有重計算都壓在與閘道同一台小 VPS，則會同時撞記憶體與磁碟上限。前者欠身分與網路層的縱深，後者則沒有雲主機那種可水平擴張的執行面。
比較穩的組合是：閘道維持輕量常駐＋tailnet 收斷可觸面＋重活卸到獨佔 macOS 節點。在需要穩定 Xcode 工具鏈、長期線上工作階段，以及可寫合約的磁碟水位時，NodeMini 的 Mac Mini 雲端租賃常是更合理的選項。
封包從 tailnet 進入目標主機的通訊堆疊後，由本機程序把流量轉到 127.0.0.1:18789；你不需要把閘道改成監聽所有介面。關鍵在 ACL、本機防火牆與權杖。若要一併評估 Mac 算力，可先參考租賃價格說明。
該文處理「從公網安全連進內部服務」的邊緣路由；本文處理「只在 tailnet 內、維持 loopback」的私網模型。可擇一或分層組合，但不要在沒有釐清驗證鏈的狀況下疊床架屋。
可從網站 OpenClaw 分類列表依主題篩選；連線與帳號相關問題也可對照說明中心內與 SSH／遠端算力相關的章節。