Aller au contenu
Guides

La passerelle OpenClaw, expliquée

Tous les guides mentionnent la passerelle et peu l’expliquent. C’est l’unique processus toujours actif auquel tout le reste parle, et la plupart des erreurs des forums la concernent. Ce qu’elle est, comment savoir si elle va bien, et ce qu’en fait un hébergeur.

5 min de lecture

Tous les guides OpenClaw mentionnent la passerelle et peu l’expliquent. C’est l’unique processus toujours actif auquel tout le reste parle, et la plupart des erreurs que les gens collent dans les forums, des boucles d’appairage au tableau de bord qui refuse de se connecter, la concernent. Voici ce qu’elle est, comment savoir si elle va bien, et ce qu’en fait un hébergeur managé.

Ce qu’est la passerelle

Un seul processus pour le routage, le plan de contrôle et les connexions aux canaux, sur un unique port multiplexé : le canal de contrôle WebSocket, les API HTTP, les routes des plugins, l’interface de contrôle et les hooks. Par défaut, elle se lie à l’interface locale, donc rien ne l’atteint de l’extérieur de la machine à moins de passer par un tunnel ou de l’exposer délibérément derrière un secret partagé.

  • L’interface de contrôle vit sur le port de la passerelle, 18789 par défaut, et exige le jeton de passerelle.
  • Les rechargements de configuration surveillent le fichier actif et remplacent l’instantané en mémoire de façon atomique.
  • Le battement de cœur, les automatisations et les workers des canaux tournent tous à l’intérieur, ce qui explique qu’un seul processus bloqué donne l’impression que tout est cassé.

Comment savoir si elle va bien

Le projet donne une échelle de commandes, et elle vaut la peine d’être mémorisée : l’état, l’état de la passerelle, suivre les journaux, doctor, puis sonder les canaux. Saine veut dire que le runtime tourne, que la sonde de connectivité répond ok et que chaque canal signale un transport actif ; tout le reste a sa propre page de runbook, classée par symptôme, des mises à jour et retours arrière au canal qui se connecte mais ne délivre rien.

gateway.err.log a accumulé plus de 109 000 erreurs.

Les pannes dont vous lirez le récit

  • Appairage requis, en boucle : le client et la passerelle ne sont pas d’accord sur qui a été approuvé.
  • Une interface de contrôle qui ne se connecte pas : en général le jeton, le port ou un tunnel tombé.
  • Des installations en double après une mise à jour, où deux versions pensent chacune posséder le service.
  • La pression mémoire sur un petit hôte, qui termine le processus avec le code de sortie 137.

Ce qu’en fait un hébergeur managé

Sur Diali, la passerelle est ce que vous ne voyez jamais. Elle tourne dans l’instance sandboxée de votre assistant, son port n’est pas sur Internet, les mises à jour sont testées d’abord sur nos propres agents, et le tableau de bord montre le fil d’activité et le bouton de redémarrage plutôt que le répertoire des journaux. OpenClaw hébergé sur Diali est la page pour cela ; le runtime en dessous est le même que celui de la documentation.

Si vous l’exploitez vous-même

  • Gardez-la sur l’interface locale et passez par un tunnel ; exposez-la uniquement derrière un secret partagé.
  • Apprenez l’échelle des cinq commandes avant d’en avoir besoin.
  • Sauvegardez le répertoire d’état ; la passerelle en est propriétaire.

Et lisez le guide du battement de cœur avant de vous demander pourquoi la passerelle a dépensé pendant votre sommeil.

Commencer

Arrêtez de lire, construisez le vôtre

Configurez un agent, choisissez un canal, et faites-le travailler dans l’application que vous gardez déjà ouverte.