mirror of
https://github.com/openclaw/openclaw.git
synced 2026-04-02 07:26:40 +02:00
5ee054e9db
- network.md: add Core model prose (loopback-first, canvas host, remote access) from the 22-line network-model.md stub - network-model.md: add redirect note pointing to /network#core-model - bridge-protocol.md: replace scattered deprecation notes with prominent <Warning> callout at the top
2.3 KiB
2.3 KiB
summary, read_when, title
| summary | read_when | title | |||
|---|---|---|---|---|---|
| Network hub: gateway surfaces, pairing, discovery, and security |
|
Network |
Network hub
This hub links the core docs for how OpenClaw connects, pairs, and secures devices across localhost, LAN, and tailnet.
Core model
Most operations flow through the Gateway (openclaw gateway), a single long-running process that owns channel connections and the WebSocket control plane.
- Loopback first: the Gateway WS defaults to
ws://127.0.0.1:18789. Tokens are required for non-loopback binds. - One Gateway per host is recommended. For isolation, run multiple gateways with isolated profiles and ports (Multiple Gateways).
- Canvas host is served on the same port as the Gateway (
/__openclaw__/canvas/,/__openclaw__/a2ui/), protected by Gateway auth when bound beyond loopback. - Remote access is typically SSH tunnel or Tailscale VPN (Remote Access).
Key references:
Pairing + identity
- Pairing overview (DM + nodes)
- Gateway-owned node pairing
- Devices CLI (pairing + token rotation)
- Pairing CLI (DM approvals)
Local trust:
- Local connections (loopback or the gateway host’s own tailnet address) can be auto‑approved for pairing to keep same‑host UX smooth.
- Non‑local tailnet/LAN clients still require explicit pairing approval.