OpenClaw 公网访问部署记录

背景

在家用 OpenClaw（跑在懒猫微服上），学习、研究都很顺手。但到了公司也想连回来用。

公司网络环境特殊——电脑没有公网直接访问权限，只能通过公司应用 Icafe 上网。Icafe 是一个隔离浏览器环境，资源有限，内存占用一高就很卡。

之前在公司一直靠飞书网页版来连接家里的 OpenClaw。但飞书网页版本身就很占内存，在 Icafe 这种受限环境下更是臃肿卡顿，体验不好。

对比发现，OpenClaw 的 Control UI 在浏览器中直接打开，内存占用比飞书网页版小将近一个数量级。于是决定将 Control UI 暴露到公网，就有了这次部署——在懒猫微服与腾讯云 Lighthouse 之间搭一条 SSH 隧道，将 Lighthouse 作为跳板机实现公网访问。

网络架构

浏览器 → https://chat.<你的域名>
              │
              ▼
      腾讯云 Lighthouse（跳板机）
         Caddy 反代 → localhost:18789
              │
              ▼  SSH 反向隧道 (autossh)
              │  -R 18789:localhost:18789
              ▼
       懒猫微服 OpenClaw Gateway
              │
              └── Control UI (聊天界面)

关键实现

1. SSH 反向隧道

懒猫微服无法直接从公网访问，Lighthouse 也连不回懒猫微服。解决方案是在懒猫微服上建一条持久的 SSH 反向隧道：

autossh -M 0 -N -R 18789:localhost:18789 <用户名>@<跳板机IP>

• -R 18789:localhost:18789：将 OpenClaw Gateway 的 18789 端口映射到 Lighthouse 的 localhost:18789
• autossh 自动重连，配合 systemd 实现开机自启
• 端口绑定到 127.0.0.1，不暴露到公网

2. Caddy 反代

Lighthouse 上运行的 Caddy 为 chat 子域名配置反代：

chat.<你的域名> {
    header {
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "no-referrer"
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
    }
    reverse_proxy localhost:18789
}

• HTTPS 证书由 Caddy 自动申请管理
• 安全头防止点击劫持、MIME 嗅探等常见攻击

3. OpenClaw Gateway 配置

{
  "allowedOrigins": [
    "https://chat.<你的域名>",
    "https://<你要放行的其它域名>"
  ],
  "dangerouslyDisableDeviceAuth": true,
  "auth": {
    "mode": "token",
    "token": "${GATEWAY_TOKEN}"
  }
}

• allowedOrigins 限制 WebSocket 来源，防止跨站劫持
• token 存于 .env 文件，不硬编码在配置中

网络安全措施

过程回顾

这个部署中间折腾了不少：

• SSH 密钥限制时过于激进（restrict 直接锁死），不得不通过腾讯云 VNC 恢复
• Caddy 的 basic_auth 与 Control UI 的 WebSocket 冲突，浏览器弹出无休止的认证框
• 系统安全机制自动隐藏密钥导致 .env 文件内容被替换为 ***

每一步都在踩坑和填坑之间循环，最终才得到现在这个还算干净的结果。

使用

浏览器打开子域名，输入配置的 Gateway Token 即可进入 Control UI 聊天。