#Node connection

1 messages · Page 1 of 1 (latest)

river thistleBOT Mar 8, 2026, 9:41 AM

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

novel shellBOT Mar 8, 2026, 9:43 AM

To “connect your local OpenClaw to the Gateway on your server”, you usually want remote mode on your local machine (local = client; server = runs the Gateway).

0) First: what version / OS?

Run this on both machines and paste the output if anything doesn’t work:

openclaw --version

1) On the server: make sure the Gateway is reachable over Tailscale

Two common good setups:

Option A (simple): bind the Gateway to tailnet

Server config (~/.openclaw/openclaw.json, JSON5):

{
  gateway: {
    bind: "tailnet",
    auth: { mode: "token", token: "REPLACE_WITH_A_REAL_TOKEN" },
  },
}

Generate / read the token on the server:

openclaw doctor --generate-gateway-token
openclaw config get gateway.auth.token

Confirm it’s listening:

openclaw gateway status

Docs: https://docs.openclaw.ai/help/faq#i-set-gatewaybind-lan-or-tailnet-and-now-nothing-listens-the-ui-says-unauthorized

Option B (more secure): keep loopback bind + use Tailscale Serve

The FAQ calls this “recommended” for remote dashboard access.
Docs: https://docs.openclaw.ai/help/faq#how-do-i-authenticate-the-dashboard-token-on-localhost-vs-remote

2) On your local PC: set OpenClaw to remote mode (client connects to server)

On your local PC, set:

openclaw config set gateway.mode remote
openclaw config set gateway.remote.url "ws://<your-server-tailscale-name-or-100.x.y.z>:18789"
openclaw config set gateway.remote.token "<paste-the-server-gateway.auth.token>"

Then verify the client can reach the server Gateway:

openclaw status

Remote-mode docs: https://docs.openclaw.ai/help/faq#how-do-i-run-openclaw-in-remote-mode-client-connects-to-a-gateway-elsewhere

3) If what you actually want is: “Gateway on server, but run commands on my local PC”

Then you want your local PC as a node (so the server Gateway can call system.run on your PC):

On the local PC:

export OPENCLAW_GATEWAY_TOKEN="<server token>"
openclaw node run --host <your-server-tailscale-name-or-100.x.y.z> --port 18789 --display-name "My PC"

On the server, approve the pairing:

openclaw devices list
openclaw devices approve <requestId>
openclaw nodes status

Node docs: https://docs.openclaw.ai/nodes

If you tell me:

your local OS (Windows/macOS/Linux),
whether you want remote mode or a node (or both),
and paste openclaw gateway status from the server,
I can point to the exact minimal config for your case.

novel shellBOT Mar 8, 2026, 10:14 AM

Your server Gateway is currently only listening on 127.0.0.1:18789:

Listening: 127.0.0.1:18789
So your Windows machine can’t reach it over Tailscale (Tailscale can only help if the service binds to a tailnet/lan interface, or you tunnel into loopback).

You have two good options:

Option A (simplest): bind the Gateway to tailnet

On the server, set:

openclaw config set gateway.bind tailnet
openclaw config set gateway.auth.mode token
# if you don’t already have one:
openclaw doctor --generate-gateway-token
openclaw config get gateway.auth.token
openclaw gateway restart

Then on Windows, run the node host pointing at the server’s Tailscale IP/DNS:

PowerShell:

$env:OPENCLAW_GATEWAY_TOKEN = "<paste token from server>"
openclaw node run --host <server-tailscale-ip-or-magicdns> --port 18789 --display-name "Windows Node"

Then back on the server, approve the pairing:

openclaw devices list
openclaw devices approve <requestId>
openclaw nodes status

Option B (keep Gateway on loopback): use an SSH tunnel (works great with Tailscale)

Keep the Gateway bound to 127.0.0.1, and from Windows create a tunnel:

ssh -N -L 18790:127.0.0.1:18789 leon@<server-tailnet-name-or-100.x.y.z>

In a second PowerShell window:

$env:OPENCLAW_GATEWAY_TOKEN = "<server token>"
openclaw node run --host 127.0.0.1 --port 18790 --display-name "Windows Node"

Approve it on the server the same way (openclaw devices list/approve).

Docs for this exact loopback+tunnel pattern: https://docs.openclaw.ai/nodes (see “Remote gateway via SSH tunnel (loopback bind)”).

Quick question

Do you want the Windows node host to run native Windows, or are you running OpenClaw inside WSL2? (Both work, but the install/paths can differ a bit.)

That error is expected (and it’s actually doing you a favor):

Your Gateway is loopback-only right now: Listening: 127.0.0.1:18789
And OpenClaw refuses plaintext ws:// to remote hosts by default (even over Tailscale), because it can’t assume the network is encrypted.

So: you need either a tunnel to loopback, or TLS (wss://).

Recommended fix (works with your current server config): SSH tunnel + localhost node

1) On Windows: open an SSH tunnel to the server

In PowerShell (keep this running):

ssh -N -L 18790:127.0.0.1:18789 leon@24fire.tail4fa7ac.ts.net

2) In a 2nd PowerShell window: start the node host pointed at localhost

First get the token from the server:

openclaw config get gateway.auth.token

Then on Windows:

$env:OPENCLAW_GATEWAY_TOKEN = "<paste token>"
openclaw node run --host 127.0.0.1 --port 18790 --display-name "Windows Node"

3) On the server: approve the pairing request

openclaw devices list
openclaw devices approve <requestId>
openclaw nodes status

This avoids both problems:

the node connects to ws://127.0.0.1:18790 (allowed)
the tunnel forwards to the server’s 127.0.0.1:18789

Docs: https://docs.openclaw.ai/nodes (Remote gateway via SSH tunnel)

Alternative (no SSH tunnel): use Tailscale Serve so you can use `wss://`

On the server:

openclaw gateway --tailscale serve

Then on Windows connect with TLS:

$env:OPENCLAW_GATEWAY_TOKEN = "<token>"
openclaw node run --host 24fire.tail4fa7ac.ts.net --port 443 --tls --display-name "Windows Node"

Docs: https://docs.openclaw.ai/gateway/tailscale

“Just make it work” break-glass (not recommended)

If you really want plaintext ws:// over tailnet:

you’d need the server Gateway bound to tailnet, and
set this env var on Windows:

$env:OPENCLAW_ALLOW_INSECURE_PRIVATE_WS = "1"

But I’d strongly stick to SSH tunnel or Serve + TLS.