Gateway

El Gateway es el servidor WebSocket de OpenClaw (canales, nodos, sesiones, ganchos). Los subcomandos en esta página se encuentran bajo openclaw gateway ….

Descubrimiento Bonjour

Configuración de mDNS local + DNS-SD de área amplia.

Resumen de descubrimiento

Cómo OpenClaw anuncia y encuentra gateways.

Configuración

Claves de configuración de nivel superior del gateway.

Ejecutar el Gateway

Ejecutar un proceso de Gateway local:

openclaw gateway

Alias en primer plano:

openclaw gateway run

Comportamiento de inicio

De forma predeterminada, el Gateway se niega a iniciarse a menos que gateway.mode=local esté establecido en ~/.openclaw/openclaw.json. Use --allow-unconfigured para ejecuciones ad-hoc/desarrollo.
Se espera que openclaw onboard --mode local y openclaw setup escriban gateway.mode=local. Si el archivo existe pero gateway.mode falta, trátelo como una configuración rota o dañada y repárela en lugar de asumir implícitamente el modo local.
Si el archivo existe y gateway.mode falta, el Gateway lo considera como un daño sospechoso en la configuración y se niega a “adivinar local” por usted.
El enlace más allá del loopback sin autenticación está bloqueado (barra de seguridad).
lan, tailnet y custom actualmente se resuelven a través de rutas BYOH solo IPv4.
BYOH solo IPv6 no es compatible de forma nativa en esta ruta hoy. Use un sidecar o proxy IPv4 si el host en sí es solo IPv6.
SIGUSR1 desencadena un reinicio en proceso cuando está autorizado (commands.restart está habilitado de forma predeterminada; establezca commands.restart: false para bloquear el reinicio manual, mientras que gateway tool/config apply/update siguen permitidos).
Los controladores SIGINT/SIGTERM detienen el proceso del gateway, pero no restauran ningún estado de terminal personalizado. Si envuelve la CLI con una interfaz de usuario de texto (TUI) o entrada en modo raw, restaure la terminal antes de salir.

Opciones

Puerto WebSocket (el valor predeterminado proviene de config/env; generalmente `18789`). Modo de enlace del escucha. `lan`, `tailnet` y `custom` actualmente se resuelven a través de rutas solo IPv4. Anulación del modo de autenticación. Anulación de token (también establece `OPENCLAW_GATEWAY_TOKEN` para el proceso). Anulación de contraseña. Lea la contraseña de la puerta de enlace desde un archivo. Exponga la puerta de enlace a través de Tailscale. Restablecer la configuración de serve/funnel de Tailscale al apagar. Hoy espera una dirección IPv4. Para BYOH solo IPv6, coloque un sidecar o proxy IPv4 delante de la puerta de enlace y apunte OpenClaw a ese punto final IPv4. Permitir el inicio de la puerta de enlace sin `gateway.mode=local` en la configuración. Omite el guardia de inicio solo para arranque ad-hoc/desarrollo; no escribe ni repara el archivo de configuración. Crear una configuración de desarrollo + espacio de trabajo si faltan (omite BOOTSTRAP.md). Restablecer configuración de desarrollo + credenciales + sesiones + espacio de trabajo (requiere `--dev`). Matar cualquier escucha existente en el puerto seleccionado antes de comenzar. Registros detallados. Mostrar solo los registros del backend de la CLI en la consola (y habilitar stdout/stderr). Estilo de registro de Websocket. Alias para `--ws-log compact`. Registrar eventos de flujo de modelo sin procesar en l. Ruta l de flujo sin procesar.

Reiniciar el Gateway

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

openclaw gateway restart --safe solicita al Gateway en ejecución que realice una comprobación previa del trabajo activo de OpenClaw antes de reiniciarse. Si hay operaciones en cola, entrega de respuestas, ejecuciones integradas o ejecuciones de tareas activas, el Gateway informa de los bloqueos, agrupa las solicitudes duplicadas de reinicio seguro y se reinicia una vez que se complete el trabajo activo. El restart normal mantiene el comportamiento existente del administrador de servicios por compatibilidad. Use --force solo cuando desee explícitamente la ruta de anulación inmediata.

openclaw gateway restart --safe --skip-deferral ejecuta el mismo reinicio coordinado compatible con OpenClaw que --safe, pero omite el control de aplazamiento de trabajo activo para que el Gateway emita el reinicio inmediatamente incluso cuando se informen bloqueadores. Úselo como la vía de escape del operador cuando un aplazamiento ha sido fijado por una ejecución de tarea atascada y --safe por sí solo esperaría indefinidamente. --skip-deferral requiere --safe.

Perfilado del Gateway

Establezca OPENCLAW_GATEWAY_STARTUP_TRACE=1 para registrar los tiempos de las fases durante el inicio del Gateway, incluido el retraso eventLoopMax por fase y los tiempos de la tabla de búsqueda de complementos para el trabajo de índice instalado, registro de manifiestos, planificación de inicio y mapa de propietarios.
Establezca OPENCLAW_GATEWAY_RESTART_TRACE=1 para registrar líneas restart trace: con alcance de reinicio para el manejo de señales de reinicio, drenaje de trabajo activo, fases de apagado, siguiente inicio, tiempos de listo y métricas de memoria.
Establezca OPENCLAW_DIAGNOSTICS=timeline con OPENCLAW_DIAGNOSTICS_TIMELINE_PATH=<path> para escribir una línea de tiempo de diagnóstico de inicio JSONL de mejor esfuerzo para arneses de QA externos. También puede habilitar la marca con diagnostics.flags: ["timeline"] en la configuración; la ruta aún se proporciona a través de variables de entorno. Agregue OPENCLAW_DIAGNOSTICS_EVENT_LOOP=1 para incluir muestras del bucle de eventos.
Ejecute pnpm build primero, luego pnpm test:startup:gateway -- --runs 5 --warmup 1 para comparar el inicio de Gateway con la entrada de la CLI integrada. El benchmark registra la primera salida del proceso, /healthz, /readyz, tiempos de traza de inicio, retraso del bucle de eventos y detalles de tiempo de la tabla de búsqueda de complementos.
Ejecute pnpm build primero, luego pnpm test:restart:gateway -- --case skipChannels --runs 1 --restarts 5 para comparar el reinicio de Gateway en proceso con la entrada de la CLI integrada en macOS o Linux. El benchmark de reinicio usa SIGUSR1, habilita tanto las trazas de inicio como las de reinicio en el proceso hijo, y registra el siguiente /healthz, el siguiente /readyz, tiempo de inactividad, tiempo de disponibilidad, CPU, RSS y métricas de traza de reinicio.
Trate /healthz como actividad (liveness) y /readyz como disponibilidad lista para usar. Las líneas de traza y la salida del benchmark son para atribución de propietario; no trate un intervalo de traza o una muestra como una conclusión de rendimiento completa.

Consultar un Gateway en ejecución

Todos los comandos de consulta usan WebSocket RPC.

Predeterminado: legible por humanos (con color en TTY).
--json: JSON legible por máquina (sin estilo/indicador de carga).
--no-color (o NO_COLOR=1): desactivar ANSI manteniendo el diseño humano.

`—url

: URL de WebSocket de Gateway. - —token

: token de Gateway. - —password

: contraseña de Gateway. - —timeout

: tiempo de espera/presupuesto (varía según el comando). - —expect-final`: esperar una respuesta “final” (llamadas de agente).

`gateway health`

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

El endpoint HTTP /healthz es un sondeo de vida (liveness probe): retorna una vez que el servidor puede responder HTTP. El endpoint HTTP /readyz es más estricto y permanece en rojo mientras los sidecars de plugins de inicio, canales o hooks configurados aún se estén estabilizando. Las respuestas de readiness detalladas locales o autenticadas incluyen un bloque de diagnóstico eventLoop con el retraso del bucle de eventos, la utilización del bucle de eventos, el ratio de núcleos de CPU y una marca degraded.

`gateway usage-cost`

Obtener resúmenes de costos de uso de los registros de sesiones.

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

Número de días a incluir.

`gateway stability`

Obtener el grabador de estabilidad de diagnóstico reciente de un Gateway en ejecución.

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

Número máximo de eventos recientes a incluir (máx. `1000`). Filtrar por tipo de evento de diagnóstico, como `payload.large` o `diagnostic.memory.pressure`. Incluir solo eventos después de un número de secuencia de diagnóstico. Leer un paquete de estabilidad persistente en lugar de llamar al Gateway en ejecución. Use `--bundle latest` (o simplemente `--bundle`) para el paquete más reciente en el directorio de estado, o pase una ruta JSON de paquete directamente. Escribir un zip de diagnóstico de soporte compartible en lugar de imprimir detalles de estabilidad. Ruta de salida para `--export`.

Privacidad y comportamiento del paquete

Los registros mantienen metadatos operacionales: nombres de eventos, recuentos, tamaños de bytes, lecturas de memoria, estado de cola/sesión, nombres de canal/complemento y resúmenes de sesión redactados. No mantienen texto de chat, cuerpos de webhook, salidas de herramientas, cuerpos de solicitud o respuesta sin procesar, tokens, cookies, valores secretos, nombres de host o identificadores de sesión sin procesar. Establezca diagnostics.enabled: false para deshabilitar el grabador por completo.
En salidas fatales del Gateway, tiempos de espera de apagado y fallas de inicio al reiniciar, OpenClaw escribe la misma instantánea de diagnóstico en ~/.openclaw/logs/stability/openclaw-stability-*.json cuando el grabador tiene eventos. Inspeccione el paquete más reciente con openclaw gateway stability --bundle latest; --limit, --type y --since-seq también se aplican a la salida del paquete.

`gateway diagnostics export`

Escribe un archivo zip de diagnóstico local diseñado para adjuntar a reportes de errores. Para el modelo de privacidad y el contenido del paquete, consulte Exportación de diagnósticos.

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

Ruta de salida del archivo zip. Por defecto es una exportación de soporte en el directorio de estado. Máximo de líneas de registro sanitizadas a incluir. Máximo de bytes de registro a inspeccionar. URL WebSocket de Gateway para la instantánea de salud. Token de Gateway para la instantánea de salud. Contraseña de Gateway para la instantánea de salud. Tiempo de espera de la instantánea de estado/salud. Omitir la búsqueda del paquete de estabilidad persistido. Imprimir la ruta escrita, el tamaño y el manifiesto como JSON.

La exportación contiene un manifiesto, un resumen en Markdown, la forma de la configuración, detalles saneados de la configuración, resúmenes de registros saneados, instantáneas saneadas de estado/salud del Gateway, y el paquete de estabilidad más reciente cuando existe uno.

Está pensado para ser compartido. Mantiene detalles operativos que ayudan a la depuración, como campos de registro seguros de OpenClaw, nombres de subsistemas, códigos de estado, duraciones, modos configurados, puertos, IDs de complementos, IDs de proveedores, configuraciones de características no secretas, y mensajes de registro operativos redactados. Omite o redacta el texto del chat, los cuerpos de los webhooks, las salidas de las herramientas, las credenciales, las cookies, los identificadores de cuenta/mensaje, el texto de indicaciones/instrucciones, los nombres de host y los valores secretos. Cuando un mensaje estilo LogTape parece ser texto de carga útil de usuario/chat/herramienta, la exportación mantiene solo que un mensaje fue omitido más su conteo de bytes.

`gateway status`

gateway status muestra el servicio Gateway (launchd/systemd/schtasks) más una sonda opcional de la capacidad de conectabilidad/autenticación.

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

Añade un objetivo de sondeo explícito. Los remotos configurados + localhost todavía son sondeados. Autenticación por token para el sondeo. Autenticación por contraseña para el sondeo. Tiempo de espera del sondeo. Omite el sondeo de conectividad (vista de solo servicio). Escanee también los servicios de nivel del sistema. Actualice el sondeo de conectabilidad predeterminado a un sondeo de lectura y salga con código distinto de cero cuando ese sondeo de lectura falle. No se puede combinar con `--no-probe`.

Semántica de estado

gateway status permanece disponible para diagnósticos incluso cuando la configuración local de la CLI falta o no es válida.
El gateway status predeterminado comprueba el estado del servicio, la conexión WebSocket y la capacidad de autenticación visible en el momento del handshake. No prueba las operaciones de lectura/escritura/administración.
Las sondas de diagnóstico no son mutantes para la autenticación de dispositivos por primera vez: reutilizan un token de dispositivo almacenado en caché existente cuando hay uno, pero no crean una nueva identidad de dispositivo CLI ni un registro de emparejamiento de dispositivo de solo lectura solo para verificar el estado.
gateway status resuelve los SecretRefs de autenticación configurados para la autenticación de sonda cuando es posible.
Si un SecretRef de autenticación requerido no se resuelve en esta ruta de comando, gateway status --json informa rpc.authWarning cuando falla la conectividad/autenticación de la sonda; pase --token/--password explícitamente o resuelva primero la fuente del secreto.
Si la sonda tiene éxito, se suprimen las advertencias de auth-ref no resueltas para evitar falsos positivos.
Cuando la sonda está habilitada, la salida JSON incluye gateway.version cuando el Gateway en ejecución lo informa; --require-rpc puede volver a la carga útil RPC de status.runtimeVersion si la sonda de handshake de seguimiento no puede proporcionar metadatos de versión.
Use --require-rpc en scripts y automatización cuando un servicio de escucha no es suficiente y también necesita que las llamadas RPC con ámbito de lectura estén saludables.
--deep añade un escaneo de mejor esfuerzo para instalaciones adicionales de launchd/systemd/schtasks. Cuando se detectan múltiples servicios tipo gateway, la salida humana imprime sugerencias de limpieza y advierte que la mayoría de las configuraciones deberían ejecutar un gateway por máquina.
--deep también informa un traspaso de reinicio reciente del supervisor del Gateway cuando el proceso del servicio salió limpiamente para un reinicio del supervisor externo.
--deep ejecuta la validación de configuración en modo consciente de complementos (pluginValidation: "full") y expone las advertencias configuradas del manifiesto del complemento (por ejemplo, metadatos de configuración de canal faltantes) para que las verificaciones de humo de instalación y actualización las detecten. El gateway status predeterminado mantiene la ruta rápida de solo lectura que omite la validación de complementos.
La salida humana incluye la ruta del archivo de registro resuelta más la instantánea de rutas/validez de configuración CLI vs servicio para ayudar a diagnosticar la deriva del perfil o del directorio de estado.

Verificaciones de deriva de autenticación de Linux systemd

En las instalaciones de Linux systemd, las verificaciones de deriva de autenticación del servicio leen ambos valores Environment= y EnvironmentFile= de la unidad (incluyendo %h, rutas entre comillas, múltiples archivos y archivos opcionales -).
Las verificaciones de deriva resuelven los SecretRefs gateway.auth.token utilizando el entorno de tiempo de ejecución combinado (primero el entorno de comandos del servicio, luego el respaldo del entorno del proceso).
Si la autenticación por token no está activa de manera efectiva (gateway.auth.mode explícito de password/none/trusted-proxy, o modo no establecido donde la contraseña puede ganar y ningún candidato de token puede ganar), las verificaciones de deriva de token omiten la resolución del token de configuración.

`gateway probe`

gateway probe es el comando “depurar todo”. Siempre sondea:

su puerta de enlace remota configurada (si está configurada), y
localhost (bucle de retorno) incluso si se configura el remoto.

Si pasas --url, ese objetivo explícito se añade antes de ambos. La salida humana etiqueta los objetivos como:

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

openclaw gateway probe
openclaw gateway probe --json

Interpretación

Reachable: yes significa que al menos un objetivo aceptó una conexión WebSocket.
Capability: read-only|write-capable|admin-capable|pairing-pending|connect-only informa lo que la sonda pudo probar sobre la autenticación. Es independiente de la accesibilidad.
Read probe: ok significa que las llamadas RPC de detalle de ámbito de lectura (health/status/system-presence/config.get) también tuvieron éxito.
Read probe: limited - missing scope: operator.read significa que la conexión tuvo éxito pero la RPC de ámbito de lectura es limitada. Esto se informa como una accesibilidad degradada, no como un fallo total.
Read probe: failed después de Connect: ok significa que el Gateway aceptó la conexión WebSocket, pero los diagnósticos de lectura de seguimiento expiraron o fallaron. Esto también es una accesibilidad degradada, no un Gateway inalcanzable.
Al igual que gateway status, la sonda reutiliza la autenticación de dispositivo en caché existente, pero no crea una identidad de dispositivo por primera vez ni el estado de emparejamiento.
El código de salida es distinto de cero solo cuando ningún objetivo sondeado es alcanzable.

Salida JSON

Nivel superior:

ok: al menos un objetivo es alcanzable.
degraded: al menos un objetivo aceptó una conexión pero no completó el diagnóstico completo de detalles RPC.
capability: la mejor capacidad vista entre los objetivos alcanzables (read_only, write_capable, admin_capable, pairing_pending, connected_no_operator_scope, o unknown).
primaryTargetId: el mejor objetivo para tratar como el ganador activo en este orden: URL explícita, túnel SSH, remoto configurado y luego bucle local.
warnings[]: registros de advertencia de mejor esfuerzo con code, message y targetIds opcional.
network: sugerencias de URL de bucle local/tailnet derivadas de la configuración actual y la red del host.
discovery.timeoutMs y discovery.count: el presupuesto de descubrimiento/recuento de resultados real utilizado para este pase de sondas.

Por objetivo (targets[].connect):

ok: alcanzabilidad después de conectar + clasificación degradada.
rpcOk: éxito de RPC de detalles completos.
scopeLimited: fallo en el RPC de detalles debido a la falta de alcance de operador.

Por objetivo (targets[].auth):

role: rol de autenticación informado en hello-ok cuando esté disponible.
scopes: alcances otorgados informados en hello-ok cuando estén disponibles.
capability: la clasificación de capacidad de autenticación expuesta para ese objetivo.

Códigos de advertencia comunes

ssh_tunnel_failed: falló la configuración del túnel SSH; el comando recurrió a sondas directas.
multiple_gateways: se alcanzó más de un destino; esto es inusual a menos que ejecute intencionalmente perfiles aislados, como un bot de rescate.
auth_secretref_unresolved: no se pudo resolver una auth SecretRef configurada para un destino fallido.
probe_scope_limited: la conexión de WebSocket se realizó correctamente, pero la sonda de lectura se limitó por la falta de operator.read.

Remoto a través de SSH (paridad de la aplicación Mac)

El modo “Remoto sobre SSH” de la aplicación de macOS utiliza un redireccionamiento de puerto local para que la puerta de enlace remota (que puede estar vinculada solo a loopback) sea accesible en ws://127.0.0.1:<port>.

Equivalente en CLI:

openclaw gateway probe --ssh user@gateway-host

`user@host` o `user@host:port` (el puerto predeterminado es `22`). Archivo de identidad. Elija el primer host de puerta de enlace descubierto como destino SSH desde el punto final de descubrimiento resuelto (`local.` más el dominio de área amplia configurado, si lo hubiera). Se ignoran las sugerencias solo de TXT.

Configuración (opcional, se usa como valores predeterminados):

gateway.remote.sshTarget
gateway.remote.sshIdentity

`gateway call <method>`

Auxiliar RPC de bajo nivel.

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

Cadena de objeto JSON para parámetros. URL WebSocket de Gateway. Token de Gateway. Contraseña de Gateway. Presupuesto de tiempo de espera. Principalmente para RPCs de tipo agente que transmiten eventos intermedios antes de una carga final. Salida JSON legible por máquina.

Administrar el servicio Gateway

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

Instalar con un contenedor (wrapper)

Use --wrapper cuando el servicio administrado debe iniciarse a través de otro ejecutable, por ejemplo un shim de administrador de secretos o un asistente de ejecución. El contenedor recibe los argumentos normales de Gateway y es responsable de ejecutar finalmente openclaw o Node con esos argumentos.

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

También puede establecer el contenedor a través del entorno. gateway install valida que la ruta sea un archivo ejecutable, escribe el contenedor en el servicio ProgramArguments y persiste OPENCLAW_WRAPPER en el entorno del servicio para reinstalaciones forzadas posteriores, actualizaciones y reparaciones de doctor.

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

Para eliminar un contenedor persistente, borre OPENCLAW_WRAPPER al reinstalar:

OPENCLAW_WRAPPER= openclaw gateway install --force
openclaw gateway restart

Opciones de comando

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`

Comportamiento del ciclo de vida

Use gateway restart para reiniciar un servicio administrado. No encadene gateway stop y gateway start como sustituto de reinicio.
En macOS, gateway stop usa launchctl bootout de forma predeterminada, lo que elimina el LaunchAgent de la sesión de arranque actual sin persistir una desactivación; la recuperación automática KeepAlive permanece activa para futuros bloqueos y gateway start se vuelve a activar correctamente sin un launchctl enable manual. Pase --disable para suprimir persistentemente KeepAlive y RunAtLoad para que la puerta de enlace no reaparezca hasta el próximo gateway start explícito; úselo cuando una detención manual debe sobrevivir a los reinicios o reinicios del sistema.
gateway restart --safe le pide a la puerta de enlace en ejecución que realice un verificación previa del trabajo activo de OpenClaw y difiera el reinicio hasta que se complete la entrega de respuestas, las ejecuciones integradas y las ejecuciones de tareas. --safe no se puede combinar con --force o --wait.
gateway restart --wait 30s anula el presupuesto de drenaje de reinicio configurado para ese reinicio. Los números simples son milisegundos; se aceptan unidades como s, m y h. --wait 0 espera indefinidamente.
gateway restart --safe --skip-deferral ejecuta el reinicio seguro compatible con OpenClaw pero omite la puerta de aplazamiento para que la puerta de enlace emita el reinicio inmediatamente incluso cuando se informan bloqueadores. Escapatoria del operador para aplazamientos de ejecuciones de tareas atascadas; requiere --safe.
gateway restart --force omite el drenaje de trabajo activo y se reinicia inmediatamente. Úselo cuando un operador ya haya inspeccionado los bloqueadores de tareas enumerados y desee tener la puerta de enlace ahora mismo.
Los comandos del ciclo de vida aceptan --json para secuencias de comandos.

Autenticación y SecretRefs en el momento de la instalación

Cuando la autenticación por token requiere un token y gateway.auth.token está gestionado por SecretRef, gateway install valida que el SecretRef se puede resolver, pero no persiste el token resuelto en los metadatos del entorno del servicio.
Si la autenticación por token requiere un token y el SecretRef del token configurado no está resuelto, la instalación falla de forma segura en lugar de persistir texto plano de respaldo.
Para la autenticación por contraseña en gateway run, se prefiere OPENCLAW_GATEWAY_PASSWORD, --password-file o un gateway.auth.password respaldado por SecretRef en lugar de --password en línea.
En el modo de autenticación inferido, OPENCLAW_GATEWAY_PASSWORD solo de shell no relaja los requisitos del token de instalación; use una configuración duradera (gateway.auth.password o configuración env) al instalar un servicio administrado.
Si tanto gateway.auth.token como gateway.auth.password están configurados y gateway.auth.mode no está establecido, la instalación se bloquea hasta que el modo se establezca explícitamente.

Descubrir gateways (Bonjour)

gateway discover escanea balizas de Gateway (_openclaw-gw._tcp).

DNS-SD de multidifusión: local.
DNS-SD de unidifusión (Bonjour de área amplia): elija un dominio (ejemplo: openclaw.internal.) y configure DNS dividido + un servidor DNS; consulte Bonjour.

Solo los gateways con el descubrimiento de Bonjour habilitado (predeterminado) anuncian la baliza.

Los registros de descubrimiento de área amplia pueden incluir estas sugerencias TXT:

role (sugerencia de rol de puerta de enlace)
transport (sugerencia de transporte, p. ej. gateway)
gatewayPort (puerto WebSocket, generalmente 18789)
sshPort (solo modo de descubrimiento completo; los clientes establecen los destinos SSH por defecto en 22 cuando está ausente)
tailnetDns (nombre de host MagicDNS, cuando está disponible)
gatewayTls / gatewayTlsSha256 (TLS habilitado + huella digital del certificado)
cliPath (solo modo de descubrimiento completo)

`gateway discover`

openclaw gateway discover

Tiempo de espera por comando (explorar/resolver). Salida legible por máquina (también deshabilita el estilo/indicador de carga).

Ejemplos:

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

Gateway

Ejecutar el Gateway

Opciones

Reiniciar el Gateway

Perfilado del Gateway

Consultar un Gateway en ejecución

gateway health

gateway usage-cost

gateway stability

gateway diagnostics export

gateway status

gateway probe