Hub sieciowy
Ten hub prowadzi do podstawowych dokumentów opisujących, jak OpenClaw łączy, paruje i zabezpiecza urządzenia przez localhost, LAN i tailnet.Model podstawowy
Większość operacji przechodzi przez Gateway (openclaw gateway), pojedynczy długotrwale działający proces, który zarządza połączeniami kanałów i płaszczyzną sterowania WebSocket.
- Najpierw loopback: Gateway WS domyślnie działa pod
ws://127.0.0.1:18789. Bindy poza loopback wymagają prawidłowej ścieżki auth gateway: auth współdzielonym sekretem przez token/hasło albo poprawnie skonfigurowanego wdrożeniatrusted-proxypoza loopback. - Zalecany jest jeden Gateway na host. Dla izolacji uruchamiaj wiele gateway z odizolowanymi profilami i portami (Multiple Gateways).
- Host canvas jest udostępniany na tym samym porcie co Gateway (
/__openclaw__/canvas/,/__openclaw__/a2ui/), chroniony przez auth gateway przy bindzie poza loopback. - Dostęp zdalny to zwykle tunel SSH albo Tailscale VPN (Remote Access).
Parowanie i tożsamość
- Pairing overview (DM + nodes)
- Gateway-owned node pairing
- Devices CLI (pairing + token rotation)
- Pairing CLI (DM approvals)
- Bezpośrednie lokalne połączenia loopback mogą być automatycznie zatwierdzane do parowania, aby zachować płynne UX na tym samym hoście.
- OpenClaw ma też wąską ścieżkę self-connect dla zaufanych helperów backend/container-local opartych na współdzielonym sekrecie.
- Klienci tailnet i LAN, w tym bindy tailnet na tym samym hoście, nadal wymagają jawnego zatwierdzenia parowania.