How can I connect OpenClaw Gateway from a different machine on my LAN?

By default, the Gateway listens only on 127.0.0.1 (localhost). You need to change the 'gateway.bind' setting to 'lan' (or 'custom' with a specific IP) and restart the service. Also, ensure your host firewall allows inbound TCP connections on port 18789.

Why did 'openclaw tui' stop working after I set 'gateway.bind=custom'?

The Terminal UI (TUI) attempts to connect to 127.0.0.1 internally. When you use a 'custom' bind to lock the listener to a specific LAN IP (e.g., 192.168.0.x), localhost is no longer bound. The TUI will launch but remain unresponsive, with no error messages shown.

What is the correct way to allow LAN access without breaking the local TUI?

Set 'gateway.bind' to 'lan'. This binds the Gateway to 0.0.0.0, which accepts connections from both the local machine (fixing the TUI) and external LAN clients. To maintain security, use your system firewall to restrict external access instead of relying on the bind IP.

Why am I still unable to connect from another host after changing the config file?

Applying settings to the config JSON is not enough; you must restart the systemd service ('systemctl --user restart openclaw-gateway.service'). Additionally, your OS firewall (like ufw or iptables) must be explicitly configured to allow incoming traffic on port 18789/tcp from your bot's IP or subnet.

How to Configure OpenClaw Gateway for LAN Access & Fix TUI Errors

March 28, 2026

OpenClaw Gateway LAN Bind — Step by Step

This document records the exact steps used to change OpenClaw Gateway from localhost-only (127.0.0.1) to LAN-accessible, so a Discord bot on a different machine can connect.

This is a note about a custom cross-host deployment, not a claim about the only official way to run OpenClaw. The official basic layout keeps the Gateway-managed Discord integration on the same machine. This document covers the case where you intentionally separate the bot host and the OpenClaw host, then connect them directly over LAN WebSocket.

Important: These steps were verified in one specific environment. Your setup may differ. Treat this as a practical reference, not a universal guarantee.

table of contents

The starting state

Out of the box, the Gateway was listening on:

127.0.0.1:18789

Only the same machine could connect directly. In this deployment, any remote WebSocket connection from another host was silently refused until the bind was changed.

What we changed

We switched from loopback to a specific LAN IP:

Before: 127.0.0.1:18789
After: 192.168.0.108:18789

Two settings were changed:

gateway.bind = custom
gateway.customBindHost = 192.168.0.108

We chose custom instead of 0.0.0.0 to limit exposure to one LAN interface.

Where the config lives

The bind setting is in the OpenClaw user config, not in the git-tracked repo:

~/.openclaw/openclaw.json

Changing the bind does not modify any tracked files. git pull on the OpenClaw repo will not revert this.

The systemd service file to check:

~/.config/systemd/user/openclaw-gateway.service

Commands we ran

openclaw config set gateway.bind custom
openclaw config set gateway.customBindHost 192.168.0.108
systemctl --user restart openclaw-gateway.service

That’s it. Three commands.

How to verify

Check that the service is running:

systemctl --user --no-pager --full status openclaw-gateway.service

Confirm the listen address changed:

ss -lntup | grep 18789

Expected result:

Before: 127.0.0.1:18789
After: 192.168.0.108:18789

Firewall

Changing the bind alone is not enough. The firewall must also allow 18789/tcp from the bot host.

Recommended approaches:

Allow only the bot server’s IP
Allow only the LAN subnet

Do not expose this port to the internet.

Alternative: listen on all interfaces

If you want to bind to 0.0.0.0 instead of a specific IP:

openclaw config set gateway.bind lan
systemctl --user restart openclaw-gateway.service

This listens on all interfaces. Firewall rules become more important in this case.

Warning: `custom` bind breaks `openclaw tui`

This is the trap we hit after the initial setup.

If you use gateway.bind = custom with a specific IP like 192.168.0.108, the gateway only listens on that address. The LAN bot works. But openclaw tui on the same machine silently breaks — it tries to connect to ws://127.0.0.1:18789, which is no longer listening.

What you see: TUI opens, message input appears, but no response ever comes. No error is shown.

What happened: 127.0.0.1 is not bound. Only 192.168.0.108 is.

The fix: Switch from custom to lan:

openclaw config set gateway.bind lan
systemctl --user restart openclaw-gateway.service
ss -ltnp | grep 18789
openclaw tui

Now both work:

0.0.0.0:18789 — accepts connections from LAN (bot) and localhost (TUI)
Firewall still controls who can reach the port from outside

Our recommendation: Use lan instead of custom unless you have a specific reason to bind to one IP only. The firewall is the right place to restrict access, not the bind address.

How to revert

To go back to localhost-only:

openclaw config set gateway.bind loopback
systemctl --user restart openclaw-gateway.service

Summary

OpenClaw Gateway defaults to 127.0.0.1 — remote connections are silently refused
Set gateway.bind=custom and gateway.customBindHost=<your LAN IP> to fix this
Restart the gateway service
Open 18789/tcp in the firewall
The bot on the other machine can now connect via ws://192.168.0.108:18789
But custom bind breaks openclaw tui on the same machine — switch to lan to fix both

No one tells you this when you first try to connect from another host. Now you know.