FYI If you started this journey before the 29th of January 2026: OpenClaw Bug Enables One-Click Remote Code Execution via Malicious Link (patched in: 2026.1.29).
Hi all. I have the same problem. I did as Simon suggested, restarted the gateway, and scanned the code again with the same result. Should I reinstall it as Andrew did? I’m on PC.
Well, the QR code timed out so I tried reinstalling and I get the same result: “gateway unreachable”. Everything on my PC side works. I can connect with Telegram.
Weird, ok, I got it to work. I had to restart my r1 to make the connection work…
I got that too. Have you got that fixed on your side?
Hi community, so I was able to reverse-enginner the OpenClaw flow somewhat and updated my ZeroClaw instance to be able to talk to R1 using OpenClaw implementation, but I was wondering if there is actually some documentation available from Rabbit on the protocol between R1 and OpenClaw, which could be used to enable the same integration with other *Claw variants?
i keep getting an invalid port on the rabbit r1 any help would be great
i keep getting an invalid port after scanning the ira code on the rabbit r1 any help would be great
scan with the camera during Openclaw, you get the following message: “secure connection required for external gateway.”
been trying to connect R1 to OpenClaw on a VPS on Tailscale only for a day or two now. Claude written notes below - still can’t get it to work 
Trying to connect Rabbit R1 to OpenClaw on a Hetzner VPS (Tailscale-only access)
Setup:
-
OpenClaw 2026.5.3-1 running on Ubuntu VPS (Hetzner)
-
Gateway bound to loopback only, Tailscale for secure access
-
R1 cannot join Tailscale network so needs a public endpoint
What we tried:
Tailscale Funnel — exposed the gateway via tailscale funnel 18789. The R1 rejected it with “gateway unreachable” — turns out the R1 requires a valid SSL certificate and WSS protocol, which Tailscale Funnel provides, but the R1 firmware still wouldn’t connect. Community post confirmed R1 only works with a proper domain + SSL.
Cloudflare Tunnel — set up cloudflared on the VPS pointing to localhost:18789, with a subdomain r1.domain.com. Got the tunnel working and confirmed via curl.
Pairing flow:
-
Used boondit.site/r1-moltbot-qr to generate QR (the official
rabbit.tech/r1-openclaw.shscript binds to0.0.0.0which is unsafe on a VPS) -
R1 successfully scanned QR, connected, and sent pairing request
-
Gateway received the request and showed it in
openclaw devices list --json
The blocking issue — approval timing: The R1 connects, sends its connect frame with a requestId, and waits approximately 175-200ms for a response. If not approved it disconnects. The openclaw devices approve <requestId> CLI command takes 3-4 seconds to execute (spawns a new process, connects to gateway via WebSocket, sends approval). By the time approval completes, the R1 has already given up and disconnected.
We confirmed this repeatedly in logs — the pattern every time:
-
08:53:42— R1 connects, rejected asnot-paired -
08:53:43— R1 retries, rejected -
08:53:44— R1 retries, rejected -
08:53:45— approval completes — R1 already gone
After approval, the R1 doesn’t retry automatically. Manual swipe left/right to retry occasionally catches it but the window is too tight to be reliable.
Also tried:
-
gateway.trustedProxiesset to["::1","127.0.0.1"]to fix proxy header warnings -
gateway.controlUi.allowInsecureAuth trueto access dashboard remotely -
Auto-approve polling loop in bash (1 second interval — still too slow)
-
gateway.pairing.autoApprove— config key doesn’t exist
Hi cianw,
I ran into the exact same problem you described and wanted to share how I solved it, in case it helps.
The issue is exactly as you diagnosed — the CLI is far too slow to approve within the R1’s connection window. The fix is to run a persistent Node.js script before scanning the QR code that pre-loads the OpenClaw modules and watches ~/.openclaw/devices/pending.json using fs.watch. The moment a new pairing request appears in that file, it calls device.pair.approve immediately — in about 15ms rather than 3–4 seconds — which is fast enough to catch the R1 before it disconnects.
The key insight is avoiding the CLI startup overhead entirely. By keeping the script running with modules already loaded and a pre-established file watcher, approval happens almost instantly when the request lands.
For the external gateway setup (Cloudflare Tunnel), the config is straightforward: service: http://127.0.0.1:18789 with the tunnel domain at port 443 over WSS — exactly as Simon described. I also added keepalive settings (keepAliveConnections: 10, keepAliveTimeout: 90s) to the cloudflared originRequest config to keep the WebSocket connection stable after pairing.
Hope this unblocks you!
Hi @simon,
It appears there’s now a WebSocket protocol version mismatch between the most up to date versions of R1’s OpenClaw client (v20260416.0, April 2026) using WebSocket protocol v3 and the OpenClaw gateway (2026.5.22, May 2026) using WebSocket protocol v4.
Wanted to check if there’s an OTA coming soon where this will be addressed?
Explanation of warn logs from deepseek flash 4 for reference:
Good question — let me show you the receipts. I found it in the detailed JSON logs at /tmp/openclaw/openclaw-2026-05-25.log:
```
protocol mismatch conn=92e409ae-5309-4c4c-bde9-1219ebdfa1c9
peer=<... obfuscated ...>
client=Rabbit R1 node v20260416.0
min=3 max=3 expected=4 probeMin=4
```
The key fields tell the whole story:
- client=Rabbit R1 — It's definitely your R1, confirmed by the user-agent okhttp/4.12.0
- peer=<...> — The R1's IP — same subnet as your MacBook at <...>
- min=3 max=3 — R1 says "I can only speak WebSocket protocol version 3"
- expected=4 probeMin=4 — Gateway says "I only speak version 4"
There were multiple attempts (3 connection tries logged) and every one got the same protocol mismatch error. Then the R1 gave up with code=1000 reason=bye — a clean close.
So the "gateway unreachable" message on the R1 is slightly misleading — it can reach the gateway, they just can't agree on a protocol version to talk to each other.
Thanks!
Hi! Yes you are correct. We are working on it but it may be a couple of weeks before we can get that updated.