OPENCLAW 2026
CHROME_RELAY_
18792_HEALTH_
SSH_TUNNEL.
2026 年一類高頻工單：Telegram／企業 IM／Control UI 皆正常，但一啟用 Chrome Relay（瀏覽器工具鏈） 就「全紅」——擷取網頁、點選 DOM、截圖鏈路全斷。真相往往不是 Gateway 掛了，而是 Relay 本機 HTTP 服務（常見預設埠 18792） 未啟動、被占用，或擴充功能未 attach 至目標分頁；若在遠端 Mac 上常駐 Gateway，筆電側還要再疊一層 SSH 本機埠轉發 才能把 curl http://127.0.0.1:18792/health 探針接到真源。本文給出症狀—分層—證據矩陣、五步可重現 Runbook（健康檢查→單程序→繫結位址→隧道→logs 分診），並明確與「頻道無回覆」類故障的切分診斷，避免把 Relay 問題誤判為 Token 或 WebSocket。可與《Gateway 權杖與 LaunchAgent》《Gateway WebSocket 握手》《SSH 與 VNC 遠端 Mac》併讀。
1. 痛點拆解：Relay 是「旁路」，勿與主鏈路混為一談
1）健康檢查未寫入值班腳本：團隊只監控 Gateway 埠與頻道 webhook，Relay 程序靜默退出數小時無人發現。2）雙實例爭用同一 Telegram token 與雙 Relay 爭用 18792 是不同物種——前者報 409／靜默，後者是 EADDRINUSE 或間歇 502。3）遠端 headless 場景下「localhost」語意分裂：你在筆電上 curl 的是本機 loopback，而 Relay 實際跑在 SSH 工作階段另一頭的 Mac 上。4）瀏覽器側權限與網站隔離：擴充功能未固定至工作設定檔、或企業政策禁止 unpacked 擴充功能，會造成「Gateway 綠、工具鏈紅」的假矛盾。
2. 症狀—分層矩陣：先判定「哪一層紅了」
| 現象 | 優先層 | 首選證據 |
|---|---|---|
curl 18792 連線被拒 | Relay 程序未監聽／崩潰 | 本機或隧道後的 curl -v 與程序清單 |
| HTTP 200 但工具呼叫逾時 | 擴充功能未 attach／分頁休眠 | Relay 日誌中的 tab attach 關鍵字 |
| 頻道正常、僅瀏覽器工具失敗 | Relay 或 Chrome 設定層 | 對照 openclaw channels probe 成功而 relay 自檢失敗 |
| 僅遠端 Mac 必現 | 繫結位址或 SSH 隧道 | 遠端 127.0.0.1 vs 0.0.0.0 與防火牆 |
3. 五步 Runbook：從探針到工單閉環
Step 1 凍結埠號與文件版本
在工單中寫明 OpenClaw 小版本、Relay 埠（預設 18792 以你環境為準）、Chrome 頻道與設定檔路徑；禁止「口頭預設埠」。
Step 2 健康檢查（本機或隧道後）
對 Relay HTTP 根或 /health 路徑執行 curl；記錄 HTTP 狀態、TLS 與否、首位元組時間。
Step 3 單程序與埠占用
確認僅一個 Relay 監聽目標埠；衝突時顯式結束陳舊程序或改設定埠並同步 CLI。
Step 4 遠端 Mac：SSH 本機轉發
從筆電將遠端 Relay 對映到本機 loopback，避免把 Gateway 暴露於公網；隧道斷線應有自動重連或值班重啟策略。
Step 5 logs 分層
先 openclaw logs 過濾 relay／chrome 關鍵字，再決定是否下鑽 Gateway WebSocket 與頻道層。
4. 與「頻道無回覆」的切分：避免錯誤升級範圍
| 探針結果 | 結論傾向 | 不建議動作 |
|---|---|---|
| channels probe OK，18792 拒絕 | 隔離在 Relay | 立即輪換 Gateway token |
| 18792 OK，頻道無回 | 回到頻道／Gateway | 重裝 Chrome 擴充功能盲操作 |
| 兩者皆失敗 | 分兩張子工單並行 | 單執行緒混查導致日誌污染 |
5. 深度案例：遠端 Mac 上「綠 Gateway、紅工具鏈」的三小時定位
「我們以為 WebSocket 又掛了，其實是筆電沒建 SSH 隧道卻在本機 curl 18792——當然全拒絕。」
某自動化小組於 2026 年 Q2 將 OpenClaw Gateway 固定在一台通風良好的遠端 Mac mini 上，Telegram 與內部 webhook 皆穩定。啟用瀏覽器取數技能後，Agent 日誌出現大量「relay unreachable」。第一反應是升級 OpenClaw 與重配 Ed25519 裝置身分；兩小時無進展。第三小時依本文矩陣回退：在遠端 Mac 本機執行 curl 18792 為 200，而從工程師筆電執行則為連線被拒——結論鎖定為隧道缺失與文件未寫明「探針應在哪一側執行」。補齊 ssh -L 與 systemd／launchd 側自動拉起說明後，故障關閉。
6. 產業觀察：瀏覽器工具鏈正在成為「第二控制面」
隨著技能包大量依賴網頁擷取與半結構化 DOM 操作，Relay 的可用性 SLA 正在與 Gateway 並列。維運需要把埠號、程序、擴充功能版本與 health 探針寫進與 API 閘道同級的監控目錄。
在合規場景下，把 Relay 與 Chrome 使用者資料目錄隔離到專用 macOS 使用者或遠端節點，比讓工程師共用日常瀏覽器設定更可稽核；這與把重負載 OpenClaw 遷到可租賃的遠端 Apple Silicon 同一邏輯：責任邊界清晰、升級視窗可控。
若你希望 OpenClaw 在圖形與網頁工具鏈上更穩、更少被筆電睡眠與瀏覽器政策綁架，可直接租賃 MACGPU 遠端 Mac：在固定 SKU 上固化 Relay+Gateway+頻道的對照映像，把本文 Runbook 作為變更驗收清單執行。
7. 三道硬門檻（寫進變更單）
第一道：合併前必須通過 18792（或你們約定埠）健康檢查。第二道：遠端場景必須附一張「探針執行主機」示意圖（筆電 vs 遠端）。第三道：Relay 升級與 Gateway 升級不得同一張工單混發，除非已證明根因耦合。
8. 可引用數字門檻
① 健康檢查 p95 延遲相對基線放大 >2.5× 凍結當日技能發布。② 同一埠 EADDRINUSE 出現 ≥2 次／週則觸發設定稽核。③ Relay 相關錯誤在 openclaw logs 中占比 >40% 的滾動視窗內，必須拆分獨立子服務監控。
9. FAQ
問：18792 一定是官方固定埠嗎？答：以你安裝的 OpenClaw 版本文件為準；本文以 18792 作為社群常見約定範例。問：能否把 Relay 繫結到 0.0.0.0 省隧道？答：評估暴露面與 mTLS／鑑權；生產更推薦 SSH 或 Tailscale。