OpenClaw Remote Access Guide

Keep the Gateway bound to a controlled interface and bring the client to it through an authenticated transport. A public bind plus a weak shared token is not a safe substitute for a private route.

SSH tunnel

For a Gateway listening on loopback at the remote host, forward the port to your computer:

ssh -N -L 18789:127.0.0.1:18789 user@gateway-host

Then open:

http://127.0.0.1:18789/

The browser reaches its own loopback port, while SSH carries traffic to the remote Gateway loopback address. Keep the terminal session open while using the UI.

Private tailnet

Tailscale can provide a stable private route and HTTPS termination. Preserve Gateway authentication unless you have deliberately configured and verified Tailscale identity handling. Direct tailnet or LAN connections can still require explicit device approval.

Use wss:// for mobile pairing and other remote browser paths that leave loopback. Treat a generated pairing QR or setup code as a short-lived credential.

Verify on both ends

On the Gateway host:

openclaw gateway status
openclaw status --all
openclaw logs --follow

On the client, load the Control UI and confirm the expected Gateway name before approving a device request.

Expected result

• The Gateway remains unavailable on an unintended public address.
• The private route or SSH tunnel reaches the Control UI.
• Authentication succeeds before pairing.
• The approved browser reconnects without repeated requests.

If localhost works on the host but the tunnel does not, inspect the SSH target and forwarding command. If the page loads but the WebSocket fails, use Control UI cannot connect.