OpenClaw 远程网关与 SSH 隧道 —— 为什么 Loris Tunnel 适合你的技术栈
如果你用 OpenClaw 搭配远程网关，那你已经在依赖 SSH 本地端口转发：桌面应用在本地访问 ws://127.0.0.1:18789，SSH 隧道把流量送到服务器上的网关。这套做法简单、安全、标准，但隧道一断就会失效。
Loris Tunnel 是一个管理 SSH 隧道（本地、远程和动态转发）的桌面 GUI，支持自动重连，并清晰展示连接健康状态。如果你希望 OpenClaw 的远程网关工作流稳定到「无聊」，它是天然的搭档。
OpenClaw 对网络的要求
根据 OpenClaw 的远程网关配置文档，通常的形态是：
- 在客户端，OpenClaw 连接
ws://127.0.0.1:18789（一个本地端口）。 - SSH 把该本地端口转发到远程主机上的
127.0.0.1:18789，也就是网关监听的位置。
在 ~/.ssh/config 中，这通常表现为某个专用主机别名下的 LocalForward 18789 127.0.0.1:18789，外加一个后台 ssh -N 会话，或在 macOS 上用 Launch Agent 保活。
这样确实能用——直到 Wi-Fi 抖动、机器休眠、远程主机重启，或者你需要多级跳板机。那时你就在调 lsof、ps 和 launchctl，而不是在用产品。
裸用 ssh -N 拖慢效率的地方
对 OpenClaw 用户来说，隧道不是「锦上添花」，而是控制面的一部分。当它出问题时：
- 应用无法到达网关，直到你发现并重启转发。
- 笔记本上的休眠与网络切换尤其痛苦。
- 多级路径（堡垒机 → 内网主机）在一次性的命令里很容易写错。
- Windows 和 macOS 团队可能不共用同一套 shell 脚本或 Launch Agent 片段。
你不需要把 SSH 从技术栈里去掉——你需要一种每天都能一致地创建、监控和恢复同一批转发的方式。
Loris Tunnel 如何支持同样的 OpenClaw 转发
Loris Tunnel 正是为这类问题设计的：长期存活的 SSH 端口转发，配上面向操作者的控制项。
| OpenClaw 式网关的需求 | Loris Tunnel 的做法 |
|---|---|
稳定地本地转发到远端 127.0.0.1:18789 | 新建隧道：本地端口 18789 → 远端 127.0.0.1:18789（也可从 SSH 命令导入）。 |
| 网络抖动后自动恢复 | 智能重连（带退避），无需手动重启。 |
| 可观测性 | 界面中的延迟监控与隧道状态，而不只是「它坏了」。 |
| 复杂路径 | 网关不在可直连主机上时，使用多级跳板机链。 |
| SOCKS 或其他转发 | 一个应用内支持**本地、远程和动态（SOCKS5）**模式。 |
复用你现有的 SSH 配置
如果你已经在用 LocalForward 18789 127.0.0.1:18789，通常可以把等价的 ssh 命令粘贴到 Loris Tunnel 的导入器中，再调整标签、跳板机和自动启动。完整功能导览见产品简介。
一个实用的心智模型
- 网关仍然留在 OpenClaw 期望的服务器（或虚拟机）上，不做改动。
- 笔记本或工作站上的 Loris Tunnel 负责那条 SSH 转发，把网关的 WebSocket 暴露在回环地址上。
- OpenClaw.app 继续在本地使用
ws://127.0.0.1:18789；它不关心隧道是由ssh -N还是 Loris Tunnel 维持的，只关心端口可达且稳定。
适合谁
- 日常使用 OpenClaw、但希望少守着终端的开发者和运维人员。
- 已经按 OpenClaw 远程网关文档配置过，希望同样的语义、更好的韧性的人。
- 需要在 macOS 与 Windows 上使用同一个可移植工具做 SSH 转发的团队。
获取 Loris Tunnel
- 版本发布：GitHub — loris-tunnel-app
- 产品概览：Loris Tunnel 简介
关于 OpenClaw
OpenClaw 及其网关、端口约定记录在 openclaws.io。Loris Tunnel 是独立的 SSH 隧道管理器；两者搭配是一种常见的运维模式，而非厂商打包的集成。
小结
OpenClaw + SSH 隧道是远程网关的正确架构。Loris Tunnel 让这套架构更适合日常运行：可视化管理、自动重连、多级跳转支持，以及更少花在抢救失效 ssh -N 会话上的时间——这样你可以专注在 agent 上，而不是管道上。