-
-
Notifications
You must be signed in to change notification settings - Fork 69.1k
[Bug]: Remote Control UI over Tailscale stays stuck on "pairing required" despite gateway.auth.mode=none, trustedProxies, and gateway.mode=local #42931
Description
Bug type
Regression (worked before, now fails)
Summary
Remote Control UI over Tailscale Serve loads, but chat consistently disconnects with pairing required even after setting trustedProxies, gateway.auth.mode=none, and gateway.mode=local.
Steps to reproduce
- Run OpenClaw
2026.3.8on a remote Hetzner Linux server. - Expose the loopback gateway through Tailscale Serve:
https://<redacted>.ts.net -> http://127.0.0.1:18789 - Configure gateway with:
mode: localbind: loopbackauth.mode: nonetrustedProxies: ["127.0.0.1/32","::1/128"]controlUi.allowedOrigins: ["https://<redacted>.ts.net"]
- Open the Control UI remotely in a browser.
- Navigate to Chat.
- Observe that the UI loads, but chat disconnects with
pairing required.
Expected behavior
Remote Control UI chat should connect successfully, or provide a working server-side pairing approval flow that can be completed from the host.
Actual behavior
The Control UI dashboard loads, but the chat websocket closes immediately and the UI shows:
Disconnected from gatewaypairing required
Gateway logs show:
code=1008 reason=pairing required
This still occurs with:
gateway.mode = localgateway.auth.mode = nonetrustedProxiesconfigured- browser control showing
auth=off
OpenClaw version
2026.3.8 (3caab92)
Operating system
Ubuntu 24.04 on Hetzner VPS
Install method
CLI/manual launch via: openclaw gateway --allow-unconfigured
Model
moonshot/kimi-k2.5
Provider / routing chain
openclaw gateway -> Moonshot API (kimi-k2.5) Remote access path: browser -> Tailscale Serve -> http://127.0.0.1:18789
Config file / key location
~/.openclaw/openclaw.json ; gateway
Additional provider/model setup details
Model/provider configuration is otherwise working. A local PC OpenClaw instance on the same version (2026.3.8) works normally with the same provider family.
Relevant gateway config:
gateway.mode = localgateway.bind = loopbackgateway.auth.mode = nonegateway.trustedProxies = ["127.0.0.1/32","::1/128"]gateway.controlUi.allowedOrigins = ["https://<redacted>.ts.net"]gateway.remote.url = "https://<redacted>.ts.net"
Logs, screenshots, and evidence
Startup log:
[gateway] auth mode=none explicitly configured; all gateway connections are unauthenticated.
[canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /root/.openclaw/canvas)
[heartbeat] started
[health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
[gateway] agent model: moonshot/kimi-k2.5
[gateway] listening on ws://127.0.0.1:18789, ws://[::1]:18789
[browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=off)
Failing websocket log:
[ws] closed before connect conn=... remote=127.0.0.1 fwd=... origin=https://<redacted>.ts.net host=<redacted>.ts.net ua=Mozilla/5.0 (...) code=1008 reason=pairing required
Before adding trustedProxies, logs showed:
Proxy headers detected from untrusted address. Connection will not be treated as local.
After adding:
"trustedProxies": [
"127.0.0.1/32",
"::1/128"
]
that proxy trust message disappeared, but pairing required remained.
CLI local loopback also failed:
gateway connect failed: Error: pairing required
[openclaw] Failed to start CLI: Error: gateway closed (1008): pairing required
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /root/.openclaw/openclaw.json
**Impact and severity**
Affected: Remote Control UI users accessing OpenClaw through Tailscale Serve on a remote host
Severity: High (blocks chat usage remotely)
Frequency: 100% repro in this setup
Consequence: Dashboard loads, but remote chat is unusable and the apparent pairing approval path is also blocked
Additional information
This appears to be specific to remote Control UI / remote browser device behavior.
Local OpenClaw on my PC works normally on the same version (`2026.3.8`), so this may be a regression or a remote-pairing-specific bug rather than a general gateway failure.
I also tested:
- `gateway.mode = remote`
- `gateway.mode = local`
- `gateway.auth.mode = token`
- `gateway.auth.mode = none`
The issue persisted after disabling gateway auth entirely and after fixing proxy trust.
Open question: is this expected behavior for remote Control UI chat over Tailscale, or is the pairing path broken/regressed in this scenario?Impact and severity
No response
Additional information
No response