OpenClaw Network Hub: Gateway, Pairing, Discovery, and Security
This hub collects core documentation on how OpenClaw connects, pairs, and protects devices across localhost, LAN, and tailnet. It covers gateway architecture, loopback binding, remote access, and security.
Read this when
- You need the network architecture + security overview
- You are debugging local vs tailnet access or pairing
- You want the canonical list of networking docs
This hub collects the core documentation covering how OpenClaw connects, pairs, and protects devices across localhost, LAN, and tailnet.
Core model
Nearly all operations pass through the Gateway (openclaw gateway), which is a single long-running process responsible for owning channel connections and the WebSocket control plane.
- Loopback first: by default, the Gateway WS binds to
ws://127.0.0.1:18789. Starting with a non-loopback bind fails unless a valid gateway auth path exists: shared-secret token/password auth, or a properly configured non-loopbacktrusted-proxydeployment. - One Gateway per host is the suggested setup. To isolate workloads, run several gateways using separate profiles and ports (Multiple Gateways).
- Hosted widget documents and A2UI renderer assets are exposed on the same port as the Gateway (
/__openclaw__/canvas/,/__openclaw__/a2ui/), and Gateway auth guards them whenever the bind goes beyond loopback. - Remote access usually takes the form of an SSH tunnel or a Tailscale VPN (Remote Access).
Important references:
Pairing + identity
- Pairing overview (DM + nodes)
- Gateway-owned node pairing
- Devices CLI (pairing + token rotation)
- Pairing CLI (DM approvals)
Local trust:
- Direct local loopback connections, those without forwarded or proxy headers, can receive automatic approval for pairing, which keeps same-host UX smooth.
- OpenClaw also offers a narrow backend/container-local self-connect path intended for trusted shared-secret helper flows.
- Tailnet and LAN clients, including same-host tailnet binds, still demand explicit pairing approval.