Die meisten Operationen laufen über das Gateway (openclaw gateway), einen einzelnen Dauerprozess, der Channel-Verbindungen und die WebSocket-Steuerungsebene verwaltet.

Grundregeln

• Ein Gateway pro Host wird empfohlen. Nur das Gateway darf die WhatsApp-Web-Session besitzen. Für Rescue-Bots oder strikte Isolation kannst du mehrere Gateways mit isolierten Profilen und Ports betreiben. Siehe Mehrere Gateways.
• Loopback zuerst: Der Gateway-WebSocket bindet standardmäßig an ws://127.0.0.1:18789. Der Assistent generiert standardmäßig ein Gateway-Token, auch für Loopback. Für Tailnet-Zugriff starte mit openclaw gateway --bind tailnet --token ..., da Tokens bei Nicht-Loopback-Bindungen Pflicht sind.
• Nodes verbinden sich per LAN, Tailnet oder SSH-Tunnel mit dem Gateway-WebSocket. Die veraltete TCP-Bridge ist deprecated.
• Der Canvas-Host wird vom Gateway-HTTP-Server auf demselben Port wie das Gateway bereitgestellt (Standard 18789):
  • /__openclaw__/canvas/
  • /__openclaw__/a2ui/ Wenn gateway.auth konfiguriert ist und das Gateway über Loopback hinaus bindet, sind diese Routen durch die Gateway-Authentifizierung geschützt. Node-Clients verwenden node-spezifische Capability-URLs, die an ihre aktive WS-Session gebunden sind. Siehe Gateway-Konfiguration (canvasHost, gateway).
• Für Remote-Nutzung wird typischerweise ein SSH-Tunnel oder ein Tailnet-VPN eingesetzt. Siehe Remote-Zugriff und Discovery.