Files
bot/docs/zh-CN/gateway/remote.md
zeekay acaeda400a Eradicate OpenClaw — resolve merge conflicts and finish the rebrand
Three coordinated things:

1. Resolve the committed upstream/main merge conflicts. 94 files were
   sitting with raw <<<<<<< HEAD ... >>>>>>> upstream/main blocks. Every
   conflict had HanzoBot/Bot on HEAD and OpenClaw on upstream. Resolved
   by keeping HEAD everywhere — 540 conflict blocks.

2. Rewrite remaining OpenClaw text refs.
     OPENCLAW   → HANZO_BOT
     OpenClaw   → HanzoBot          (PascalCase type identifiers)
     openclaw   → bot               (codebase convention — botToken,
                                    botUsername etc.; avoids invalid
                                    hyphenated JS identifiers)
     openclaw[_]/openclaw[A-Z] → bot[_]/bot[A-Z]   (compound)
     ai.openclaw.x → ai.hanzo.bot.x  (JVM package path)

3. Delete or rename openclaw-named file paths (116 of them). Dead
   duplicates with a Bot-named canonical from the partial migration:
   deleted. Otherwise renamed.
     ai/openclaw/**           → deleted (ai/hanzo/bot/** canonical)
     Sources/OpenClaw*/       → deleted (Sources/Bot* canonical)
     Tests/OpenClawIPCTests/  → deleted (Tests/BotIPCTests canonical)
     OpenClawKit/             → deleted (BotKit canonical)
     openclaw-tools.*.ts      → deleted (bot-tools.*.ts canonical)
     openclaw-root.ts etc.    → deleted (bot-root.ts canonical)
     types.openclaw.ts        → deleted (types.bot.ts canonical)
     extensions/*/openclaw.plugin.json → renamed hanzo-bot.plugin.json
     docs/start/openclaw.md   → renamed hanzo-bot.md (+ zh-CN)
     docs/assets/openclaw-*.png, whatsapp-openclaw*.jpg → deleted
     scripts/.../openclaw-*   → deleted (bot/hanzo-bot parallels)
     openclaw.mjs             → deleted (hanzo-bot.mjs is package.bin)

Then patched 65 broken JS/TS import strings where hanzo-bot had ended
up inside an import path ('./types.hanzo-bot.js' → './types.bot.js'
etc., since the on-disk filename uses the brand-neutral bot- prefix).

Pre-existing lint debt cleaned up to get oxlint --type-aware to 0/0:
removed the dead i18n test that referenced a path no longer existing;
defined the missing DIDConfig and WalletConfig types in types.base.ts
(they were imported but never declared); dropped unused imports;
collapsed redundant type assertion and a tautological meta.bot lookup
that the openclaw→bot rename made redundant.

The a2ui.bundle.js generated artifact is kept at its pre-rebrand
contents — it gets regenerated by 'pnpm canvas:a2ui:bundle' from
sources I cannot rebuild in this commit; the source side is clean.

Verified: 0 occurrences of openclaw (case-insensitive) in tree source
content, 0 file or directory paths with openclaw in the name; oxlint
--type-aware src test reports 0/0.
2026-05-11 17:56:29 -07:00

5.3 KiB
Raw Permalink Blame History

read_when, summary, title, x-i18n
read_when summary title x-i18n
运行或排查远程 Gateway 网关设置问题
使用 SSH 隧道(Gateway WS)和 tailnet 进行远程访问 远程访问
generated_at model provider source_hash source_path workflow
2026-02-03T07:48:40Z claude-opus-4-5 pi 7e00bd2e048dfbd829913bef0f40a791b8d8c3e2f8a115fc0a13b03f136ebc93 gateway/remote.md 15

远程访问(SSH、隧道和 tailnet)

本仓库通过在专用主机(桌面/服务器)上运行单个 Gateway 网关(主节点)并让客户端连接到它来支持"SSH 远程"。

  • 对于操作员(你/macOS 应用):SSH 隧道是通用的回退方案。
  • 对于节点(iOS/Android 和未来的设备):连接到 Gateway WebSocket(LAN/tailnet 或根据需要通过 SSH 隧道)。

核心理念

  • Gateway WebSocket 绑定到你配置端口的 loopback(默认为 18789)。
  • 对于远程使用,你通过 SSH 转发该 loopback 端口(或使用 tailnet/VPN 减少隧道需求)。

常见的 VPN/tailnet 设置(智能体所在位置)

将 Gateway 网关主机视为"智能体所在的位置"。它拥有会话、身份验证配置文件、渠道和状态。 你的笔记本电脑/桌面(和节点)连接到该主机。

1) tailnet 中始终在线的 Gateway 网关(VPS 或家庭服务器)

在持久主机上运行 Gateway 网关,并通过 Tailscale 或 SSH 访问它。

  • 最佳用户体验: 保持 gateway.bind: "loopback" 并使用 Tailscale Serve 作为控制 UI。
  • 回退方案: 保持 loopback + 从任何需要访问的机器建立 SSH 隧道。
  • 示例: exe.dev(简易 VM)或 Hetzner(生产 VPS)。

当你的笔记本电脑经常休眠但你希望智能体始终在线时,这是理想的选择。

2) 家庭桌面运行 Gateway 网关,笔记本电脑作为远程控制

笔记本电脑不运行智能体。它远程连接:

  • 使用 macOS 应用的 Remote over SSH 模式(设置 → 通用 → "HanzoBot runs")。
  • 应用打开并管理隧道,因此 WebChat + 健康检查"直接工作"。

操作手册:macOS 远程访问。

3) 笔记本电脑运行 Gateway 网关,从其他机器远程访问

保持 Gateway 网关在本地但安全地暴露它:

  • 从其他机器到笔记本电脑的 SSH 隧道,或
  • Tailscale Serve 控制 UI 并保持 Gateway 网关仅 loopback。

指南:Tailscale 和 Web 概览。

命令流(什么在哪里运行)

一个 Gateway 网关服务拥有状态 + 渠道。节点是外围设备。

流程示例(Telegram → 节点):

  • Telegram 消息到达 Gateway 网关。
  • Gateway 网关运行智能体并决定是否调用节点工具。
  • Gateway 网关通过 Gateway WebSocket 调用节点(node.* RPC)。
  • 节点返回结果;Gateway 网关回复到 Telegram。

说明:

  • 节点不运行 Gateway 网关服务。 除非你有意运行隔离的配置文件,否则每台主机只应运行一个 Gateway 网关(参见多 Gateway 网关)。
  • macOS 应用的"节点模式"只是通过 Gateway WebSocket 的节点客户端。

SSH 隧道(CLI + 工具)

创建到远程 Gateway WS 的本地隧道:

ssh -N -L 18789:127.0.0.1:18789 user@host

隧道建立后:

  • hanzo-bot health 和 hanzo-bot status --deep 现在通过 ws://127.0.0.1:18789 访问远程 Gateway 网关。
  • hanzo-bot gateway {status,health,send,agent,call} 在需要时也可以通过 --url 指定转发的 URL。

注意:将 18789 替换为你配置的 gateway.port(或 --port/BOT_GATEWAY_PORT)。

CLI 远程默认值

你可以持久化远程目标,以便 CLI 命令默认使用它:

{
  gateway: {
    mode: "remote",
    remote: {
      url: "ws://127.0.0.1:18789",
      token: "your-token",
    },
  },
}

当 Gateway 网关仅限 loopback 时,保持 URL 为 ws://127.0.0.1:18789 并先打开 SSH 隧道。

通过 SSH 的聊天 UI

WebChat 不再使用单独的 HTTP 端口。SwiftUI 聊天 UI 直接连接到 Gateway WebSocket。

  • 通过 SSH 转发 18789(见上文),然后让客户端连接到 ws://127.0.0.1:18789。
  • 在 macOS 上,优先使用应用的"Remote over SSH"模式,它会自动管理隧道。

macOS 应用"Remote over SSH"

macOS 菜单栏应用可以端到端驱动相同的设置(远程状态检查、WebChat 和语音唤醒转发)。

操作手册:macOS 远程访问。

安全规则(远程/VPN)

简短版本:保持 Gateway 网关仅 loopback,除非你确定需要绑定。

  • Loopback + SSH/Tailscale Serve 是最安全的默认设置(无公开暴露)。
  • 非 loopback 绑定(lan/tailnet/custom,或当 loopback 不可用时的 auto)必须使用身份验证令牌/密码。
  • gateway.remote.token 仅用于远程 CLI 调用——它不启用本地身份验证。
  • gateway.remote.tlsFingerprint 在使用 wss:// 时固定远程 TLS 证书。
  • 当 gateway.auth.allowTailscale: true 时,Tailscale Serve 可以通过身份标头进行身份验证。如果你想使用令牌/密码,请将其设置为 false。
  • 将浏览器控制视为操作员访问:仅限 tailnet + 有意的节点配对。

深入了解:安全。