Hub réseau
Ce hub relie la documentation principale expliquant comment OpenClaw connecte, appaire et sécurise les appareils sur localhost, le LAN et le tailnet.Modèle principal
La plupart des opérations passent par la passerelle (openclaw gateway), un processus unique de longue durée qui possède les connexions aux canaux et le plan de contrôle WebSocket.
- Loopback d’abord : la passerelle WS utilise par défaut
ws://127.0.0.1:18789. Les liaisons non loopback nécessitent un chemin valide d’authentification de la passerelle : authentification par jeton/mot de passe à secret partagé, ou un déploiementtrusted-proxynon loopback correctement configuré. - Une passerelle par hôte est recommandé. Pour l’isolation, exécutez plusieurs passerelles avec des profils et ports isolés (Multiple Gateways).
- Le canvas host est servi sur le même port que la passerelle (
/__openclaw__/canvas/,/__openclaw__/a2ui/), protégé par l’authentification de la passerelle lorsqu’il est lié au-delà de loopback. - L’accès distant se fait généralement via un tunnel SSH ou un VPN Tailscale (Remote Access).
- Architecture de la passerelle
- Protocole de passerelle
- Runbook de la passerelle
- Surfaces web + modes de liaison
Pairage + identité
- Vue d’ensemble du pairage (DM + nœuds)
- Pairage de nœuds géré par la passerelle
- CLI Devices (pairage + rotation de jeton)
- CLI Pairing (approbations DM)
- Les connexions directes locales loopback peuvent être auto-approuvées pour le pairage afin de garder l’expérience sur le même hôte fluide.
- OpenClaw dispose aussi d’un chemin étroit d’auto-connexion backend/conteneur local pour des flux d’assistance à 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 pairage.
Découverte + transports
Nœuds + transports
- Vue d’ensemble des nœuds
- Protocole de bridge (nœuds hérités, historique)
- Runbook de nœud : iOS
- Runbook de nœud : Android