Modelo principal
La mayoría de las operaciones fluyen a través del Gateway (openclaw gateway), un único proceso de larga duración que gestiona las conexiones de canales y el plano de control WebSocket.
- Primero loopback: el WS del Gateway usa de forma predeterminada
ws://127.0.0.1:18789. Los enlaces que no son loopback se niegan a iniciar sin una ruta válida de autenticación del gateway: autenticación con token/contraseña de secreto compartido, o un desplieguetrusted-proxyno loopback configurado correctamente. - Se recomienda un Gateway por host. Para aislamiento, ejecuta varios gateways con perfiles y puertos aislados (Varios Gateways).
- El host de Canvas se sirve en el mismo puerto que el Gateway (
/__openclaw__/canvas/,/__openclaw__/a2ui/), protegido por la autenticación del Gateway cuando se enlaza más allá de loopback. - El acceso remoto suele ser un túnel SSH o una VPN de Tailscale (Acceso remoto).
- Arquitectura del Gateway
- Protocolo del Gateway
- Runbook del Gateway
- Superficies web + modos de enlace
Emparejamiento + identidad
- Resumen de emparejamiento (DM + nodos)
- Emparejamiento de nodos gestionado por el Gateway
- CLI de dispositivos (emparejamiento + rotación de tokens)
- CLI de emparejamiento (aprobaciones por DM)
- Las conexiones directas de local loopback (sin encabezados reenviados/de proxy) pueden aprobarse automáticamente para el emparejamiento a fin de mantener fluida la UX en el mismo host.
- OpenClaw también tiene una ruta limitada de autoconexión local al backend/contenedor para flujos de asistentes de secreto compartido de confianza.
- Los clientes de tailnet y LAN, incluidos los enlaces de tailnet del mismo host, siguen requiriendo aprobación explícita de emparejamiento.
Descubrimiento + transportes
Nodos + transportes
- Resumen de nodos
- Protocolo de puente (nodos heredados, histórico)
- Runbook de nodos: iOS
- Runbook de nodos: Android