GatewayGateway

Le Gateway est le serveur WebSocket d’OpenClaw (canaux, nœuds, sessions, hooks). Les sous-commandes de cette page se trouvent sous GatewayOpenClawopenclaw gateway ….

BonjourDécouverte Bonjour

Configuration mDNS locale + DNS-SD étendu.

Aperçu de la découverte

Comment OpenClaw annonce et trouve les gateways.

Configuration

Clés de configuration de premier niveau du gateway.

Exécuter le Gateway

Exécuter un processus Gateway local :

openclaw gateway

Alias pour le premier plan :

openclaw gateway run

Comportement au démarrage

Par défaut, le Gateway refuse de démarrer sauf si gateway.mode=local est défini dans ~/.openclaw/openclaw.json. Utilisez --allow-unconfigured pour les exécutions ad-hoc/dev.
openclaw onboard --mode local et openclaw setup sont censés écrire gateway.mode=local. Si le fichier existe mais que gateway.mode est manquant, considérez cela comme une configuration cassée ou corrompue et réparez-la au lieu d’assumer implicitement le mode local.
Si le fichier existe et que gateway.modeGateway est manquant, le Gateway considère cela comme une suspicion de dommage sur la configuration et refuse de “deviner local” pour vous.
La liaison au-delà du loopback sans authentification est bloquée (garde-fou de sécurité).
lan, tailnet et custom résolvent actuellement sur les chemins BYOH IPv4 uniquement.
Le BYOH IPv6 uniquement n’est pas pris en charge nativement sur ce chemin aujourd’hui. Utilisez un sidecar ou un proxy IPv4 si l’hôte lui-même est en IPv6 uniquement.
SIGUSR1 déclenche un redémarrage en processus lorsqu’il est autorisé (commands.restart est activé par défaut ; définissez commands.restart: false pour bloquer le redémarrage manuel, tandis que gateway tool/config apply/update restent autorisés).
Les gestionnaires SIGINT/SIGTERMCLITUI arrêtent le processus de gateway, mais ils ne restaurent aucun état de terminal personnalisé. Si vous enveloppez le CLI avec une TUI ou une saisie en mode brut, restaurez le terminal avant la sortie.

Options

Port WebSocket (la valeur par défaut provient de la configuration/de l'environnement ; généralement `18789`). Mode de liaison de l'écouteur. `lan`, `tailnet` et `custom` résolvent actuellement uniquement via des chemins IPv4. Remplacement du mode d'authentification. Remplacement du jeton (définit également `OPENCLAW_GATEWAY_TOKEN` pour le processus). Remplacement du mot de passe. Lire le mot de passe de la passerelle depuis un fichier. Exposer le Gateway via Tailscale. Réinitialiser la configuration serveur/entonoir de Tailscale à l'arrêt. Attend une adresse IPv4 aujourd'hui. Pour le BYOH IPv6 uniquement, placez un sidecar ou proxy IPv4 devant le Gateway et pointez OpenClaw vers ce point de terminaison IPv4. Autoriser le démarrage de la passerelle sans `gateway.mode=local` dans la configuration. Contourne la garde de démarrage uniquement pour l'amorçage ad-hoc/dev ; n'écrit pas et ne répare pas le fichier de configuration. Créer une configuration de développement + un espace de travail s'ils sont manquants (saute BOOTSTRAP.md). Réinitialiser la configuration dev + les identifiants + les sessions + l'espace de travail (nécessite `--dev`). Tuer tout écouteur existant sur le port sélectionné avant de démarrer. Journaux verbeux. Afficher uniquement les journaux backend CLI dans la console (et activer stdout/stderr). Style de journal WebSocket. Alias pour `--ws-log compact`. Enregistrer les événements bruts du flux de modèle dans l. Chemin l du flux brut.

Redémarrer le Gateway

openclaw gateway restart
openclaw gateway restart --safe
openclaw gateway restart --safe --skip-deferral
openclaw gateway restart --force

openclaw gateway restart --safe demande au Gateway en cours d’exécution d’effectuer un contrôle préliminaire du travail OpenClaw actif avant le redémarrage. Si des opérations en file d’attente, la livraison de réponses, les exécutions intégrées ou les exécutions de tâches sont actives, le Gateway signale les bloquants, fusionne les demandes de redémarrage sécurisé en double et redémarre une fois le travail actif écoulé. Le simple restart conserve le comportement existant du gestionnaire de services pour la compatibilité. Utilisez --force uniquement lorsque vous souhaitez explicitement le chemin de substitution immédiat.

openclaw gateway restart --safe --skip-deferral exécute le même redémarrage coordonné sensible à OpenClaw que --safe, mais contourne la porte de report du travail actif afin que le Gateway émette le redémarrage immédiatement, même lorsque des bloquants sont signalés. Utilisez-le comme l’échappatoire de l’opérateur lorsqu’un report a été épinglé par une exécution de tâche bloquée et que --safe seul attendrait indéfiniment. --skip-deferral nécessite --safe.

Profilage du Gateway

Définissez OPENCLAW_GATEWAY_STARTUP_TRACE=1 pour consigner les minutages des phases lors du démarrage du Gateway, y compris le délai eventLoopMax par phase et les minutages de la table de recherche des plugins pour l’index installé, le registre de manifeste, la planification du démarrage et le travail de la carte des propriétaires.
Définissez OPENCLAW_GATEWAY_RESTART_TRACE=1 pour consigner les lignes restart trace: limitées au redémarrage pour la gestion des signaux de redémarrage, l’évacuation du travail actif, les phases d’arrêt, le prochain démarrage, le minutage de préparation et les métriques de mémoire.
Définissez OPENCLAW_DIAGNOSTICS=timeline avec OPENCLAW_DIAGNOSTICS_TIMELINE_PATH=<path> pour écrire une chronologie de diagnostic de démarrage JSONL au mieux pour les harnais de QA externes. Vous pouvez également activer l’indicateur avec diagnostics.flags: ["timeline"] dans la configuration ; le chemin est toujours fourni par env. Ajoutez OPENCLAW_DIAGNOSTICS_EVENT_LOOP=1 pour inclure les échantillons de la boucle d’événements.
Exécutez d’abord pnpm build, puis pnpm test:startup:gateway -- --runs 5 --warmup 1GatewayCLI pour comparer les performances de démarrage du Gateway par rapport à l’entrée CLI intégrée. Le benchmark enregistre la première sortie du processus, /healthz, /readyz, les timings de trace de démarrage, le délai de la boucle d’événements et les détails de timing de la table de recherche des plugins.
Exécutez d’abord pnpm build, puis pnpm test:restart:gateway -- --case skipChannels --runs 1 --restarts 5GatewayCLImacOSLinux pour comparer les performances de redémarrage du Gateway en cours de processus par rapport à l’entrée CLI intégrée sur macOS ou Linux. Le benchmark de redémarrage utilise SIGUSR1, active à la fois les traces de démarrage et de redémarrage dans le processus enfant, et enregistre le prochain /healthz, le prochain /readyz, le temps d’arrêt, le temps de disponibilité, le CPU, le RSS et les métriques de trace de redémarrage.
Traitez /healthz comme une indication de vivacité et /readyz comme une indication de disponibilité utilisable. Les lignes de trace et la sortie du benchmark sont destinées à l’attribution de responsabilité ; ne traitez pas une span de trace ou un échantillon comme une conclusion de performance complète.

Interroger un Gateway en cours d’exécution

Toutes les commandes de requête utilisent le RPC WebSocket.

Par défaut : lisible par l’homme (coloré en TTY).
--json : JSON lisible par machine (sans style/spinner).
--no-color (ou NO_COLOR=1) : désactive ANSI tout en conservant la mise en page humaine.

`—url

Gateway : URL WebSocket du Gateway. - —token

Gateway : Jeton du Gateway. - —password

Gateway : Mot de passe du Gateway. - —timeout

: délai/budget (varie par commande). -—expect-final` : attendre une réponse « finale » (appels d’agent).

`gateway health`

openclaw gateway health --url ws://127.0.0.1:18789

Le point de terminaison HTTP /healthz est une sonde de vivacité : il retourne une réponse dès que le serveur peut répondre aux requêtes HTTP. Le point de terminaison HTTP /readyz est plus strict et reste rouge tant que les sidecars de plugins de démarrage, les canaux ou les hooks configurés sont encore en cours de stabilisation. Les réponses de readiness détaillées locales ou authentifiées incluent un bloc de diagnostic eventLoop avec le délai de la boucle d’événements, l’utilisation de la boucle d’événements, le ratio de cœurs CPU et un indicateur degraded.

`gateway usage-cost`

Récupérer les résumés des coûts d’utilisation à partir des journaux de session.

openclaw gateway usage-cost
openclaw gateway usage-cost --days 7
openclaw gateway usage-cost --json

Nombre de jours à inclure.

`gateway stability`

Récupérer l’enregistreur de stabilité de diagnostic récent à partir d’un Gateway en cours d’exécution.

openclaw gateway stability
openclaw gateway stability --type payload.large
openclaw gateway stability --bundle latest
openclaw gateway stability --bundle latest --export
openclaw gateway stability --json

Nombre maximum d'événements récents à inclure (max `1000`). Filtrer par type d'événement de diagnostic, tel que `payload.large` ou `diagnostic.memory.pressure`. Inclure uniquement les événements après un numéro de séquence de diagnostic. Lire un bundle de stabilité persisté au lieu d'appeler le Gateway en cours d'exécution. Utilisez `--bundle latest` (ou simplement `--bundle`) pour le bundle le plus récent sous le répertoire d'état, ou passez directement un chemin JSON de bundle. Écrire un zip de diagnostics de support partageable au lieu d'imprimer les détails de stabilité. Chemin de sortie pour `--export`.

Confidentialité et comportement du bundle

Les enregistrements conservent les métadonnées opérationnelles : noms d’événements, comptages, tailles en octets, lectures de mémoire, état de la file/session, noms de channel/plugin et résumés de session expurgés. Ils ne conservent pas le texte des discussions, les corps de webhook, les sorties d’outils, les corps de requête ou de réponse bruts, les jetons, les cookies, les valeurs secrètes, les noms d’hôte ou les identifiants de session bruts. Définissez diagnostics.enabled: false pour désactiver complètement l’enregistreur.
En cas de sortie fatale du Gateway, de délais d’arrêt et d’échecs de démarrage au redémarrage, OpenClaw écrit le même instantané de diagnostic dans ~/.openclaw/logs/stability/openclaw-stability-*.json lorsque l’enregistreur contient des événements. Inspectez le bundle le plus récent avec openclaw gateway stability --bundle latest ; --limit, --type et --since-seq s’appliquent également à la sortie du bundle.

`gateway diagnostics export`

Écrivez un fichier zip de diagnostic local conçu pour être joint aux rapports de bugs. Pour le modèle de confidentialité et le contenu du bundle, consultez Exportation des diagnostics.

openclaw gateway diagnostics export
openclaw gateway diagnostics export --output openclaw-diagnostics.zip
openclaw gateway diagnostics export --json

Chemin de sortie du fichier zip. Par défaut, une exportation de support sous le répertoire d'état. Nombre maximum de lignes de journal nettoyées à inclure. Nombre maximum d'octets de journal à inspecter. URL WebSocket du Gateway pour l'instantané d'état. Jeton du Gateway pour l'instantané d'état. Mot de passe du Gateway pour l'instantané d'état. Délai d'attente de l'instantané d'état/de santé. Ignorer la recherche du bundle de stabilité persisté. Afficher le chemin écrit, la taille et le manifeste au format JSON.

L’export contient un manifeste, un résumé Markdown, la forme de la configuration, les détails nettoyés de la configuration, les résumés des journaux nettoyés, les instantanés d’état/health du Gateway nettoyés et le bundle de stabilité le plus récent s’il en existe un.

Il est destiné à être partagé. Il conserve des détails opérationnels qui aident au débogage, tels que les champs de journal OpenClaw sûrs, les noms de sous-systèmes, les codes d’état, les durées, les modes configurés, les ports, les identifiants de plugins, les identifiants de fournisseur, les paramètres de fonctionnalités non secrets et les messages de journal opérationnels expurgés. Il omet ou expurge le texte de chat, les corps de webhook, les sorties d’outils, les identifiants, les cookies, les identifiants de compte/message, le texte d’instruction/invite, les noms d’hôte et les valeurs secrètes. Lorsqu’un message de style LogTape ressemble au texte de la charge utile utilisateur/chat/outils, l’exportation conserve uniquement le fait qu’un message a été omis ainsi que son nombre d’octets.

`gateway status`

gateway status affiche le service Gateway (launchd/systemd/schtasks) ainsi qu’une sonde optionnelle de la capacité de connexion/authentification.

openclaw gateway status
openclaw gateway status --json
openclaw gateway status --require-rpc

Ajouter une cible de sonde explicite. Les hôtes distants configurés + localhost sont toujours sondés. Authentification par jeton pour la sonde. Authentification par mot de passe pour la sonde. Délai d'expiration de la sonde. Ignorer la sonde de connectivité (vue services uniquement). Analyser également les services de niveau système. Passer la sonde de connectivité par défaut à une sonde de lecture et quitter avec un code non nul lorsque cette sonde de lecture échoue. Ne peut pas être combiné avec `--no-probe`.

Sémantique de l'état

gateway status reste disponible pour le diagnostic même lorsque la configuration locale de la CLI est manquante ou non valide.
gateway status par défaut prouve l’état du service, la connexion WebSocket et la capacité d’auth visible au moment de la poignée de main. Cela ne prouve pas les opérations de lecture/écriture/administration.
Les sondes de diagnostic sont non mutantes pour la première authentification de l’appareil : elles réutilisent un jeton d’appareil existant en cache lorsqu’il en existe un, mais elles ne créent pas une nouvelle identité d’appareil CLI ni un enregistrement d’appareil en lecture seule juste pour vérifier l’état.
gateway status résout les SecretRefs d’auth configurés pour l’auth de sonde si possible.
Si un SecretRef d’auth requis n’est pas résolu dans ce chemin de commande, gateway status --json signale rpc.authWarning lorsque la connectivité/l’auth de la sonde échoue ; passez --token/--password explicitement ou résolvez d’abord la source du secret.
Si la sonde réussit, les avertissements d’auth-ref non résolus sont supprimés pour éviter les faux positifs.
Lorsque les sondes sont activées, la sortie JSON inclut gateway.version lorsque le Gateway en cours d’exécution le signale ; --require-rpc peut revenir à la charge utile RPC status.runtimeVersion si la sonde de poignée de main de suivi ne peut pas fournir les métadonnées de version.
Utilisez --require-rpc dans les scripts et l’automatisation lorsqu’un service d’écoute ne suffit pas et que vous avez besoin que les appels RPC de portée lecture soient également en bonne santé.
--deep ajoute une analyse au mieux pour les installations launchd/systemd/schtasks supplémentaires. Lorsque plusieurs services de type passerelle sont détectés, la sortie humaine imprime des conseils de nettoyage et avertit que la plupart des configurations doivent exécuter une passerelle par machine.
--deep signale également un transfert de redémarrage récent du superviseur Gateway lorsque le processus du service s’est terminé proprement pour un redémarrage du superviseur externe.
--deep exécute la validation de la configuration en mode compatible avec les plugins (pluginValidation: "full") et affiche les avertissements configurés du manifeste de plugin (par exemple métadonnées de configuration de channel manquantes) afin que les tests de fumée d’installation et de mise à jour les détectent. gateway status par défaut conserve le chemin rapide en lecture seule qui ignore la validation des plugins.
La sortie humaine inclut le chemin du fichier journal résolu ainsi que l’instantané des chemins/validité de la configuration CLI-vs-service pour aider à diagnostiquer la dérive du profil ou du répertoire d’état.

LinuxVérifications de dérive d'auth systemd Linux

Sur les installations Linux systemd, les vérifications de dérive d’auth du service lisent les valeurs Environment= et EnvironmentFile= à partir de l’unité (y compris %h, chemins entre guillemets, fichiers multiples et fichiers - facultatifs).
Les vérifications de dérive résolvent les SecretRefs gateway.auth.token en utilisant l’environnement d’exécution fusionné (environnement de commande du service en premier, puis repli vers l’environnement du processus).
Si l’auth par jeton n’est pas effectivement active (gateway.auth.mode explicite de password/none/trusted-proxy, ou mode non défini où le mot de passe peut l’emporter et aucun candidat de jeton ne peut l’emporter), les vérifications de dérive de jeton ignorent la résolution du jeton de configuration.

`gateway probe`

gateway probe est la commande « tout déboguer ». Elle sonde toujours :

votre passerelle distante configurée (si définie), et
localhost (boucle locale) même si une passerelle distante est configurée.

Si vous passez --url, cette cible explicite est ajoutée avant les deux. La sortie humaine étiquette les cibles comme suit :

URL (explicit)
Remote (configured) ou Remote (configured, inactive)
Local loopback

openclaw gateway probe
openclaw gateway probe --json

Interprétation

Reachable: yes signifie qu’au moins une cible a accepté une connexion WebSocket.
Capability: read-only|write-capable|admin-capable|pairing-pending|connect-only rapporte ce que la sonde a pu prouver concernant l’authentification. C’est distinct de l’accessibilité.
Read probe: ok signifie que les appels RPC de détail de portée de lecture (health/status/system-presence/config.get) ont également réussi.
Read probe: limited - missing scope: operator.read signifie que la connexion a réussi mais que le RPC de portée de lecture est limité. Cela est signalé comme une accessibilité dégradée, et non comme un échec total.
Read probe: failed après Connect: ok signifie que le Gateway a accepté la connexion WebSocket, mais que les diagnostics de lecture de suivi ont expiré ou échoué. Il s’agit également d’une accessibilité dégradée, et non d’un Gateway inaccessible.
Comme gateway status, la sonde réutilise l’authentification d’appareil existante en cache mais ne crée pas d’identité d’appareil ou d’état d’appariement pour la première fois.
Le code de sortie est non nul uniquement lorsqu’aucune cible sondée n’est accessible.

Sortie JSON

Niveau supérieur :

ok : au moins une cible est joignable.
degraded : au moins une cible a accepté une connexion mais n’a pas terminé les diagnostics complets de RPC.
capability : meilleure capacité observée sur les cibles joignables (read_only, write_capable, admin_capable, pairing_pending, connected_no_operator_scope ou unknown).
primaryTargetId : meilleure cible à traiter comme le gagnant actif dans cet ordre : URL explicite, tunnel SSH, distant configuré, puis local loopback.
warnings[] : enregistrements d’avertissement de meilleur effort avec code, message, et facultatif targetIds.
network : indications d’URL local loopback/tailnet dérivées de la configuration actuelle et du réseau hôte.
discovery.timeoutMs et discovery.count : le budget de découverte/résultat réel utilisé pour ce passage de sonde.

Par cible (targets[].connect) :

ok : joignabilité après connexion + classification dégradée.
rpcOk : succès du RPC complet.
scopeLimited : échec du RPC dû à une portée d’opérateur manquante.

Par cible (targets[].auth) :

role : rôle d’authentification signalé dans hello-ok si disponible.
scopes : portées accordées signalées dans hello-ok si disponible.
capability : la classification de capacité d’authentification remontée pour cette cible.

Codes d'avertissement courants

ssh_tunnel_failed : échec de la configuration du tunnel SSH ; la commande est revenue à des sondes directes.
multiple_gateways : plus d’une cible était accessible ; c’est inhabituel sauf si vous exécutez intentionnellement des profils isolés, tels qu’un robot de secours.
auth_secretref_unresolved : une auth SecretRef configurée n’a pas pu être résolue pour une cible ayant échoué.
probe_scope_limited : la connexion WebSocket a réussi, mais la sonde de lecture a été limitée par l’absence de operator.read.

À distance via SSH (parité avec l’app Mac)

Le mode “Remote over SSH” de l’application macOS utilise un transfert de port local pour que la passerelle distante (qui peut être liée uniquement à boucle locale) devienne accessible sur ws://127.0.0.1:<port>.

Équivalent CLI :

openclaw gateway probe --ssh user@gateway-host

`user@host` ou `user@host:port` (le port par défaut est `22`). Fichier d'identité. Choisir le premier hôte de passerelle découvert comme cible SSH à partir du point de terminaison de découverte résolu (`local.` plus le domaine étendu configuré, le cas échéant). Les indications TXT uniquement sont ignorées.

Configuration (facultatif, utilisé par défaut) :

gateway.remote.sshTarget
gateway.remote.sshIdentity

`gateway call <method>`

Assistant RPC de bas niveau.

openclaw gateway call status
openclaw gateway call logs.tail --params '{"sinceMs": 60000}'

Chaîne d'objet JSON pour les paramètres. URL WebSocket du Gateway. Jeton du Gateway. Mot de passe du Gateway. Budget de délai d'attente. Principalement pour les RPC de type agent qui diffusent des événements intermédiaires avant une charge utile finale. Sortie JSON lisible par machine.

Gérer le service Gateway

openclaw gateway install
openclaw gateway start
openclaw gateway stop
openclaw gateway restart
openclaw gateway uninstall

Installer avec un wrapper

Utilisez --wrapper lorsque le service géré doit démarrer via un autre exécutable, par exemple un shim de gestionnaire de secrets ou une aide d’exécution. Le wrapper reçoit les arguments normaux du Gateway et est responsable de lancer finalement openclaw ou Node avec ces arguments.

cat > ~/.local/bin/openclaw-doppler <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
exec doppler run --project my-project --config production -- openclaw "$@"
EOF
chmod +x ~/.local/bin/openclaw-doppler

openclaw gateway install --wrapper ~/.local/bin/openclaw-doppler --force
openclaw gateway restart

Vous pouvez également définir le wrapper via l’environnement. gateway install valide que le chemin est un fichier exécutable, écrit le wrapper dans le fichier ProgramArguments du service, et rend persistant OPENCLAW_WRAPPER dans l’environnement du service pour les réinstallations forcées ultérieures, les mises à jour et les réparations doctor.

OPENCLAW_WRAPPER="$HOME/.local/bin/openclaw-doppler" openclaw gateway install --force
openclaw doctor

Pour supprimer un wrapper persistant, effacez OPENCLAW_WRAPPER lors de la réinstallation :

OPENCLAW_WRAPPER= openclaw gateway install --force
openclaw gateway restart

Options de commande

gateway status : --url, --token, --password, --timeout, --no-probe, --require-rpc, --deep, --json
gateway install : --port, `—runtime

, —token, —wrapper

, —force, —json -gateway restart:—safe, —skip-deferral, —force, —wait

, —json -gateway uninstall|start:—json -gateway stop:—disable, —json`

Comportement du cycle de vie

Utilisez gateway restart pour redémarrer un service géré. Ne chaînez pas gateway stop et gateway start en remplacement d’un redémarrage.
Sur macOS, gateway stop utilise launchctl bootout par défaut, ce qui supprime le LaunchAgent de la session de démarrage actuelle sans rendre la désactivation persistante — La récupération automatique KeepAlive reste active pour les futurs plantages et gateway start réactive proprement sans launchctl enable manuel. Passez --disable pour supprimer de manière persistante KeepAlive et RunAtLoad afin que la passerelle ne redémarre pas jusqu’au prochain gateway start explicite ; utilisez ceci lorsqu’un arrêt manuel doit survivre aux redémarrages ou aux redémarrages système.
gateway restart --safe demande au Gateway en cours d’exécution de pré-vérifier le travail OpenClaw actif et de reporter le redémarrage jusqu’à ce que la livraison des réponses, les exécutions intégrées et les exécutions de tâches soient écoulées. --safe ne peut pas être combiné avec --force ou --wait.
gateway restart --wait 30s remplace le budget de drainage de redémarrage configuré pour ce redémarrage. Les nombres nus sont en millisecondes ; des unités telles que s, m et h sont acceptées. --wait 0 attend indéfiniment.
gateway restart --safe --skip-deferral exécute le redémarrage sécurisé compatible OpenClaw mais contourne la porte de report, de sorte que le Gateway émet le redémarrage immédiatement même lorsque des bloquants sont signalés. Porte de sortie de secours pour l’opérateur pour les reports d’exécutions de tâches bloquées ; nécessite --safe.
gateway restart --force ignore le drainage du travail actif et redémarre immédiatement. Utilisez-le lorsqu’un opérateur a déjà inspecté les bloquants de tâches répertoriés et souhaite récupérer la passerne immédiatement.
Les commandes de cycle de vie acceptent --json pour les scripts.

Authentification et SecretRefs lors de l'installation

Lorsque l’authentification par jeton nécessite un jeton et que gateway.auth.token est géré par SecretRef, gateway install vérifie que le SecretRef peut être résolu, mais ne persiste pas le jeton résolu dans les métadonnées de l’environnement du service.
Si l’authentification par jeton nécessite un jeton et que le SecretRef du jeton configuré n’est pas résolu, l’installation échoue de manière sécurisée au lieu de persister un texte brut de repli.
Pour l’authentification par mot de passe sur gateway run, privilégiez OPENCLAW_GATEWAY_PASSWORD, --password-file ou un gateway.auth.password soutenu par un SecretRef plutôt qu’un --password en ligne.
En mode d’authentification déduit, OPENCLAW_GATEWAY_PASSWORD limité au shell ne relâche pas les exigences de jeton d’installation ; utilisez une configuration durable (gateway.auth.password ou config env) lors de l’installation d’un service géré.
Si gateway.auth.token et gateway.auth.password sont tous deux configurés et que gateway.auth.mode n’est pas défini, l’installation est bloquée jusqu’à ce que le mode soit défini explicitement.

Découvrir les passerelles (Bonjour)

gateway discover recherche des balises Gateway (_openclaw-gw._tcp).

Multicast DNS-SD : local.
Unicast DNS-SD (Wide-Area Bonjour) : choisissez un domaine (exemple : openclaw.internal.) et configurez un DNS fractionné + un serveur DNS ; voir Bonjour.

Seules les passerelles avec la découverte Bonjour activée (par défaut) annoncent la balise.

Les enregistrements de découverte grande portée peuvent inclure ces indices TXT :

role (indication de rôle du Gateway)
transport (indication de transport, par ex. gateway)
gatewayPort (port WebSocket, généralement 18789)
sshPort (mode de découverte complète uniquement ; les clients définissent par défaut les cibles SSH sur 22 lorsqu’il est absent)
tailnetDns (nom d’hôte MagicDNS, si disponible)
gatewayTls / gatewayTlsSha256 (TLS activé + empreinte du certificat)
cliPath (mode de découverte complète uniquement)

`gateway discover`

openclaw gateway discover

Délai d'expiration par commande (browse/resolve). Sortie lisible par machine (désactive également le style/le spinner).

Exemples :

openclaw gateway discover --timeout 4000
openclaw gateway discover --json | jq '.beacons[].wsUrl'

GatewayGateway

Exécuter le Gateway

Options

Redémarrer le Gateway

Profilage du Gateway

Interroger un Gateway en cours d’exécution

gateway health

gateway usage-cost

gateway stability

gateway diagnostics export

gateway status

gateway probe