Openclaw手机连不上自家服务器排查

手机配对自家服务器上的 OpenClaw 网关。主机、端口、令牌全填对了,证书指纹也对上、点了「信任」,最后界面还是弹出一句:「连接问题 · 无法访问您的 Gateway」。

排障排了一个多小时。最后发现,问题不在网关,不在证书,在服务器上三个端口的反代配置。一个看起来完全正常、却把 WebSocket 请求转发给了博客程序的 443 端口。

记录:2026-08-09 上午 · 一次 OpenClaw 手机节点配对排障

01

现象:什么都对了,还是连不上

OpenClaw 官方 App 手动配对网关,流程走到底:证书指纹从服务器抓下来、SHA-256 核对一致,点了信任,然后就卡在 「连接问题」。

这个报错最迷惑的地方在于:证书信任弹窗是正常出现的。按直觉,证书都过了,说明网络通、TLS 通,那剩下的就是令牌问题。但令牌明明是对的。

证书信任通过 ≠ 连接成功。TLS 握手和 WebSocket 建连是两回事,中间隔着一整层反代。

02

排障:服务器侧全绿,手机侧全红

STEP 1 · 网关健康检查 openclaw status 一切正常:网关运行中、ws 可达、auth token 有效、8443 端口代理正常。

STEP 2 · 证书指纹核对 从 thinkspc.fun:8443 抓取 Let’s Encrypt 证书,计算 SHA-256 指纹,与 App 要求一致。

STEP 3 · 关键一击:网关日志 查看 11:43~11:49 的网关日志,没有任何来自手机的 WebSocket 连接记录。

网关日志里没有连接记录,意味着手机发的请求根本没到网关。服务端全绿、请求却到不了,问题只可能出在中间那一层:反向代理。

03

根因:443 端口把请求转发给了博客

检查 nginx 配置,真相大白。服务器上有三个监听端口,反代目标完全不一样:

80 → 301 跳转 https 正常

443 → 127.0.0.1:8090(Halo 博客) ❌ 抢了网关的流量

8443 → 127.0.0.1:18789(OpenClaw 网关) ✅ 正确

OpenClaw 的 device-pair 插件,publicUrl 配置指向 wss://thinkspc.fun/gateway,默认走 443 端口。而 nginx 的 443 端口,/ 路径反代给的是 Halo 博客(8090),只有 8443 端口才带 WebSocket upgrade 头、正确转发给网关(18789)。

为什么证书信任能通过?因为 443 和 8443 用的是同一张 Let’s Encrypt 证书,TLS 握手照样成功,信任弹窗正常出现。但紧接着的 WebSocket 升级请求,被 443 转发给了博客程序。博客不认识 WebSocket 协议,连接直接失败,App 报「连接问题」。

最坑的地方就在这里:证书是同一个,信任流程完全正常,肉眼可见的一切都对,只有请求被悄悄转发错了地方。

04

修复:让配对码指向 8443

把 publicUrl 从 wss://thinkspc.fun/gateway 改成 wss://thinkspc.fun:8443,重新生成配对码,手机重新配对,openclaw nodes approve 放行设备,一次通过。

顺带还踩了两个小坑,一并记录:

bootstrap token 有效期只有 10 分钟,过期要重新生成配对码,不能用旧的反复试。

手动设置里端口默认填 18789 是内网端口,公网连接必须走 8443。

443 是「看起来最对」的默认端口,恰恰是最容易踩的坑。

05

三条经验

1. 证书信任通过,不代表 WebSocket 能通。TLS 和 WS 是两层,中间还夹着反代。信任弹窗正常,只说明 TLS 握手成功,不代表升级请求能到应用。

2. 服务端日志里没有连接记录,先查代理层,别查应用层。这次如果继续在网关配置里找原因,永远找不到。请求根本没到网关。「日志无记录」本身就是最重要的线索。

3. 多端口公网服务器,先画一张端口对照表。80/443/8443 各自反代到哪、带不带 WS 支持,写清楚。一次画表十分钟,排查时省一小时。

排查连通性问题,直接用Ai来帮你修复，先回答「请求到底到了哪一层」,再谈修哪里。

· 如果你也在自建 OpenClaw 网关,欢迎交流