Modèle central
La plupart des opérations passent par le Gateway (openclaw gateway), un unique processus de longue durée qui possède les connexions de canaux et le plan de contrôle WebSocket.
- Loopback d’abord : le WS du Gateway utilise par défaut
ws://127.0.0.1:18789. Les liaisons non-loopback nécessitent un chemin d’authentification Gateway valide : authentification par jeton/mot de passe à secret partagé, ou déploiement non-loopbacktrusted-proxycorrectement configuré. - Un Gateway par hôte est recommandé. Pour l’isolation, exécutez plusieurs gateways avec des profils et ports isolés (Gateways multiples).
- L’hôte Canvas est servi sur le même port que le Gateway (
/__openclaw__/canvas/,/__openclaw__/a2ui/), protégé par l’authentification Gateway lorsqu’il est lié au-delà du loopback. - L’accès distant se fait généralement via un tunnel SSH ou le VPN Tailscale (Accès distant).
Association + identité
- Vue d’ensemble de l’association (DM + nœuds)
- Association de nœuds détenue par le Gateway
- CLI des appareils (association + rotation de jetons)
- CLI d’association (approbations par DM)
- Les connexions directes en local loopback peuvent être approuvées automatiquement pour l’association afin de garder une expérience fluide sur le même hôte.
- OpenClaw dispose aussi d’un chemin étroit d’auto-connexion locale au backend/conteneur pour les flux d’assistants à secret partagé de confiance.
- Les clients tailnet et LAN, y compris les liaisons tailnet sur le même hôte, nécessitent toujours une approbation explicite de l’association.
Découverte + transports
Nœuds + transports
- Vue d’ensemble des nœuds
- Protocole de pont (nœuds hérités, historique)
- Runbook des nœuds : iOS
- Runbook des nœuds : Android