How to configure remote mode in gateway

[hidden wadi]

I'm hosting openclaw on my raspberry pi and now I want to access the control UI from my mac, how to do that? Right now it listens on 127.0.0.1 and not 0.0.0.0 which gives me connection refused errors.

[tawdry kelp]

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

[vapid jetty]

Safest path: don’t bind the Pi gateway to 0.0.0.0 unless you really need LAN exposure. Keep it on loopback and access it from the Mac through SSH or Tailscale.

SSH tunnel from the Mac:

ssh -N -L 18789:127.0.0.1:18789 pi@<raspberry-pi-host-or-ip>

Then open:

http://127.0.0.1:18789/

If you use Tailscale, the nicer setup is Tailscale Serve: keep gateway.bind: "loopback", enable Serve, then open the Pi’s MagicDNS HTTPS URL from your Mac. Docs: https://docs.openclaw.ai/gateway/tailscale and https://docs.openclaw.ai/web

If you specifically want direct LAN access, configure the Pi gateway with a non-loopback bind plus auth and allowed origins. In ~/.openclaw/openclaw.json that’s roughly:

[vapid jetty]

{
  gateway: {
    bind: "lan",
    auth: { mode: "token", token: "replace-with-a-secret-token" },
    controlUi: {
      allowedOrigins: ["http://<pi-lan-ip>:18789"]
    }
  }
}

Then restart:

openclaw gateway restart

[vapid jetty]

openclaw gateway status

Open http://<pi-lan-ip>:18789/ from the Mac and paste the gateway token if prompted. First remote browser connect may show pairing required; approve it on the Pi with:

openclaw devices list
openclaw devices approve <requestId>

If it still refuses, please share openclaw --version and openclaw gateway status. Docs for the remote patterns: https://docs.openclaw.ai/gateway/remote 🦞

[hidden wadi]

ah yes, I use tailscale, I just didn
what does ""

[vapid jetty]

Looks like your message got cut off after what does "".

If you mean “what does Tailscale Serve mean?”: it lets Tailscale expose your Pi’s local 127.0.0.1:18789 gateway as an HTTPS URL inside your tailnet, without making OpenClaw listen on the whole LAN.

On the Pi, try:

openclaw gateway --tailscale serve

Or persist it in config:

openclaw config set gateway.tailscale.mode serve
openclaw config set gateway.bind loopback
openclaw gateway restart

[vapid jetty]

Then from your Mac open the Pi’s Tailscale MagicDNS URL, usually:

https://<pi-machine-name>.<tailnet-name>.ts.net/

If you paste the exact phrase you were asking about, I can decode that bit specifically.

[hidden wadi]

Yes I mean “what does Tailscale Serve mean?” i just accidentally clicked enter

When I start it using openclaw gateway --tailscale serve
It looks like it starts: 12:18:09 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
But I still can't access it, it refuses connection like before. I can access a dummy page with python -m http.server via tailscale though so it's something openclaw related.

[vapid jetty]

That log line is the browser control service, not the Control UI. 18791 is an internal loopback-only helper port derived from the gateway port; you normally should not browse to it from your Mac.

For Tailscale Serve, the expected flow is:

1. On the Pi, gateway stays local:

openclaw gateway --tailscale serve

2. From the Mac, open the HTTPS MagicDNS URL, not http://<tailscale-ip>:18789:

https://<pi-machine-name>.<tailnet-name>.ts.net/

If you try http://<tailscale-ip>:18789 while gateway.bind is still loopback, connection refused is expected.

Can you run these on the Pi and paste the relevant output?

[vapid jetty]

openclaw --version
openclaw gateway status
tailscale serve status

Also, if you want to sanity-check locally on the Pi:

curl -I http://127.0.0.1:18789/

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

[hidden wadi]

Ah tailscale serve status gives me No serve config
How do I setup that?

[vapid jetty]

No serve config means Tailscale itself does not currently have a Serve rule. OpenClaw should create that when gateway.tailscale.mode=serve is active, so either it did not get persisted, the gateway did not restart cleanly, or the tailscale serve command failed.

On the Pi, do this:

openclaw config set gateway.bind loopback
openclaw config set gateway.tailscale.mode serve
openclaw gateway restart
openclaw gateway status
tailscale serve status

If tailscale serve status still says no config, set the Serve rule manually:

tailscale serve --bg --yes 18789

[vapid jetty]

tailscale serve status

If that errors with permissions, try:

sudo tailscale serve --bg --yes 18789

Then open the HTTPS MagicDNS URL from the Mac:

https://<pi-machine-name>.<tailnet-name>.ts.net/

Important: Serve should point at the gateway port 18789, not the browser-control helper 18791.

[vapid jetty]

If it still fails, paste:

openclaw --version
openclaw gateway status
tailscale serve status
openclaw logs --tail 80

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

[hidden wadi]

Hm very strange: ```
Service: systemd user (enabled)
File logs: /tmp/openclaw/openclaw-2026-05-27.log
Command: /usr/bin/node /home/banddans/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 36459, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

• pid 36459 banddans: /usr/bin/node /home/banddans/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789 (127.0.0.1:18789)
  Listening: 127.0.0.1:18789
  Troubles: run openclaw status
  Troubleshooting: https://docs.openclaw.ai/troubleshooting

Port already in use? Are there two daemons here?? 
My version is `2026.5.22` btw

[vapid jetty]

That output does not look like two daemons. The “Port 18789 is already in use” line is pointing at the same systemd service PID 36459, so the service owns the listener.

The weird part is this combination:

Listening: 127.0.0.1:18789
Connectivity probe: failed ... timeout

That means something is listening, but the gateway WebSocket probe is not getting a healthy response. Also your service command is just:

... openclaw/dist/index.js gateway --port 18789

So openclaw gateway --tailscale serve was probably a one-off foreground command, not the installed systemd service config. For the service path, persist it and restart the service:

[vapid jetty]

openclaw config get gateway.tailscale.mode
openclaw config set gateway.bind loopback
openclaw config set gateway.tailscale.mode serve
openclaw gateway restart
sleep 5
openclaw gateway status
tailscale serve status

If the probe still times out, the next useful thing is logs from that exact PID/startup:

openclaw logs --tail 120
# or:
tail -n 120 /tmp/openclaw/openclaw-2026-05-27.log

[vapid jetty]

Also sanity-check the HTTP side locally on the Pi:

curl -v http://127.0.0.1:18789/ --max-time 5

If curl also hangs/timeouts, the gateway process is wedged after binding the port, and the logs should show where. If curl returns HTML but the status probe times out, that narrows it to WS/auth/probe behavior.

Docs for this exact status split: https://docs.openclaw.ai/start/faq and remote/Tailscale setup: https://docs.openclaw.ai/gateway/tailscale

[hidden wadi]

openclaw config get gateway.tailscale.mode: serve
(already done those two)
openclaw gateway restart: no errors
openclaw gateway status: Huh? Now its working again? ```
Service: systemd user (enabled)
File logs: /tmp/openclaw/openclaw-2026-05-27.log
Command: /usr/bin/node /home/banddans/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

CLI version: 2026.5.22 (~/.npm-global/bin/openclaw)
Gateway version: 2026.5.22

Runtime: running (pid 37231, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: connected-no-operator-scope

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

tailscale serve status: `No serve config`
posted 120 last logs in a txt file if you can see it

curl to local control ui looks fine like this: ```
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: camera=(), microphone=(self), geolocation=()
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'; base-uri 'none'; object-src 'none'; frame-ancestors 'none'; script-src 'self'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: blob:; media-src 'self' data: blob:; font-src 'self' https://fonts.gstatic.com; worker-src 'self'; connect-src 'self' ws: wss: https://api.openai.com https://tweakcn.com
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Date: Wed, 27 May 2026 10:56:54 GMT
Connection: keep-alive
Keep-Alive: timeout=5```

[vapid jetty]

Yep, I can see it. The gateway itself is healthy now: local HTTP returns 200 and Connectivity probe: ok.

The actual blocker is this log line:

gateway/tailscale: serve failed: Command failed: /usr/bin/tailscale serve --bg --yes 18789

OpenClaw is trying to create the Serve rule, but Tailscale is rejecting the command. The log unfortunately doesn’t include stderr, so run the exact command manually on the Pi to get the real reason:

/usr/bin/tailscale serve --bg --yes 18789
tailscale serve status

If that fails, try with sudo:

[vapid jetty]

sudo /usr/bin/tailscale serve --bg --yes 18789
tailscale serve status

Common causes: the local user can’t manage Tailscale Serve, Tailscale HTTPS/MagicDNS isn’t enabled for the tailnet, or the installed Tailscale version/daemon is too old. The manual command should say which one.

One extra thing: your logs show gateway.controlUi.allowInsecureAuth=true. Once Serve works, I’d turn that off unless you intentionally enabled it for debugging:

openclaw config set gateway.controlUi.allowInsecureAuth false
openclaw gateway restart

Paste the manual tailscale serve error and we can go straight at the root cause.

[hidden wadi]

Running sudo /usr/bin/tailscale serve --bg --yes 18789 tailscale serve status sort of fixed it, it now connects but firefox shows this:

Secure Connection Failed

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
What can you do about it?

The issue is most likely with the website, and there is nothing you can do to resolve it. You can notify the website’s administrator about the problem.

I've never seen it before and I don't know what that means.
I also disabled insecure auth like you said.

[vapid jetty]

That usually means the browser is speaking HTTPS to something that is not serving valid HTTPS at that address.

For Tailscale Serve, don’t open https://<pi>:18789 and don’t open the Tailscale IP with port 18789. Serve terminates HTTPS on the MagicDNS hostname and forwards to local 127.0.0.1:18789.

Use exactly the URL from:

tailscale serve status

It should be shaped like:

https://<pi-machine-name>.<tailnet-name>.ts.net/

No :18789 on the browser URL.

[vapid jetty]

If you were already using that exact URL, paste the full tailscale serve status output. Also useful from the Mac:

curl -v https://<pi-machine-name>.<tailnet-name>.ts.net/

The other likely case is Firefox showing a cert/protocol error because the URL is slightly wrong; Chrome/Safari can be a quick sanity check too. Disabling allowInsecureAuth was still the right move.