La mayoría de las configuraciones deberían usar un solo Gateway porque un único Gateway puede gestionar múltiples conexiones de mensajería y agentes. Si necesitas un aislamiento más fuerte o redundancia (p. ej., un bot de rescate), ejecuta Gateways separados con perfiles/puertos aislados.Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Mejor configuración recomendada
Para la mayoría de los usuarios, la configuración más sencilla de bot de rescate es:- mantener el bot principal en el perfil predeterminado
- ejecutar el bot de rescate en
--profile rescue - usar un bot de Telegram completamente separado para la cuenta de rescate
- mantener el bot de rescate en un puerto base diferente, como
19789
Inicio rápido del bot de rescate
Usa esto como ruta predeterminada salvo que tengas una razón de peso para hacer otra cosa:openclaw --profile rescue onboard:
- usa el token del bot de Telegram separado
- conserva el perfil
rescue - usa un puerto base al menos 20 más alto que el del bot principal
- acepta el espacio de trabajo de rescate predeterminado salvo que ya gestiones uno tú mismo
gateway install final no es necesario.
Por qué funciona esto
El bot de rescate se mantiene independiente porque tiene su propio:- perfil/configuración
- directorio de estado
- espacio de trabajo
- puerto base (más los puertos derivados)
- token del bot de Telegram
- fácil de mantener solo para operadores
- token e identidad de bot separados
- independiente de la instalación del canal/app del bot principal
- ruta sencilla de recuperación basada en DM cuando el bot principal está roto
Qué cambia --profile rescue onboard
openclaw --profile rescue onboard usa el flujo normal de incorporación, pero
escribe todo en un perfil separado.
En la práctica, eso significa que el bot de rescate obtiene su propio:
- archivo de configuración
- directorio de estado
- espacio de trabajo (por defecto
~/.openclaw/workspace-rescue) - nombre de servicio gestionado
Configuración general de múltiples Gateway
El diseño de bot de rescate anterior es el valor predeterminado más fácil, pero el mismo patrón de aislamiento funciona para cualquier par o grupo de Gateways en un host. Para una configuración más general, asigna a cada Gateway adicional su propio perfil con nombre y su propio puerto base:Lista de verificación de aislamiento
Mantén estos valores únicos por instancia de Gateway:OPENCLAW_CONFIG_PATH— archivo de configuración por instanciaOPENCLAW_STATE_DIR— sesiones, credenciales y cachés por instanciaagents.defaults.workspace— raíz del espacio de trabajo por instanciagateway.port(o--port) — único por instancia- puertos derivados de navegador/canvas/CDP
Mapeo de puertos (derivado)
Puerto base =gateway.port (o OPENCLAW_GATEWAY_PORT / --port).
- puerto del servicio de control del navegador = base + 2 (solo loopback)
- el host de canvas se sirve en el servidor HTTP del Gateway (el mismo puerto que
gateway.port) - los puertos CDP del perfil de navegador se asignan automáticamente desde
browser.controlPort + 9 .. + 108
Notas de navegador/CDP (error común)
- No fijes
browser.cdpUrlen los mismos valores en múltiples instancias. - Cada instancia necesita su propio puerto de control del navegador y rango CDP (derivados de su puerto de gateway).
- Si necesitas puertos CDP explícitos, define
browser.profiles.<name>.cdpPortpor instancia. - Chrome remoto: usa
browser.profiles.<name>.cdpUrl(por perfil, por instancia).
Ejemplo manual de entorno
Comprobaciones rápidas
gateway status --deepayuda a detectar servicios launchd/systemd/schtasks obsoletos de instalaciones anteriores.- el texto de advertencia de
gateway probe, comomultiple reachable gateways detected, solo es esperado cuando ejecutas intencionadamente más de un Gateway aislado.