OPENCLAW 2026
CHROME_RELAY_
18792_HEALTH_
SSH_TUNNEL.
2026 年一类高频工单：Telegram / 钉钉 / 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 vs 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 侧自动拉起说明后，故障关闭。该案例说明：Relay 排错的第一性原理是「loopback 在哪台机器上」。
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。问：与 Chrome DevTools Protocol 直接连有何区别？答：Relay 提供 OpenClaw 侧的编排与鉴权收敛，排错仍从 health 与 logs 分层入手。问：Windows 笔记本连远程 Mac 一样吗？答：隧道语法一致，注意本地防火墙对转发端口的拦截。