Que OpenClaw muestre Servicio no disponible no identifica un único fallo. En el hilo de la comunidad de IceWhale de febrero de 2026, la resolución de problemas reveló sucesivamente tres capas distintas: un token de puerta de enlace obligatorio, permisos insuficientes para inspeccionar Docker desde la cuenta del host de ZimaOS y, finalmente, un contenedor de OpenClaw que nunca había completado su configuración inicial.
El hilo es especialmente útil porque algunas sugerencias intermedias resultaron ser incorrectas para la imagen empaquetada de Big-Bear. Añadir una variable GATEWAY_MODE la variable de entorno no resolvió el bucle de reinicios, y añadir --gateway.mode=local al comando incorrecto produjo un opción desconocida error. La documentación actual de OpenClaw confirma que gateway.mode=local debe estar en la configuración persistente de OpenClaw y que las implementaciones de Docker deben ejecutar el proceso de incorporación o configuración para crear dicha configuración.
Primero comprueba si el contenedor de OpenClaw se está ejecutando realmente
La publicación original mostraba que la aplicación OpenClaw informaba de que no se estaba ejecutando correctamente y mostraba un consejo sobre OPENCLAW_GATEWAY_TOKEN.
Antes de cambiar la configuración de la aplicación, inspecciona el estado del contenedor desde el host de ZimaOS o CasaOS:
docker ps -a | grep openclawSi el contenedor se está reiniciando o ha salido, consulta sus registros:
docker logs big-bear-openclaw --tail 100El nombre exacto del contenedor puede variar. Usa docker ps -a para identificar el nombre real en lugar de asumir que siempre es big-bear-openclaw.
Generar y almacenar OPENCLAW_GATEWAY_TOKEN
La primera sugerencia de la comunidad fue generar un token aleatorio seguro para la puerta de enlace:
openssl rand -hex 32Si OpenSSL no está disponible, el hilo ofrecía una alternativa local para generar bytes aleatorios:
head -c 32 /dev/urandom | xxd -p -c 32La documentación oficial actual de Docker de OpenClaw también usa OPENCLAW_GATEWAY_TOKEN para la autenticación de la puerta de enlace. Su script de configuración estándar genera un token y lo escribe en el archivo .env archivo automáticamente. En una aplicación de CasaOS empaquetada manualmente, introduce el valor generado en el campo de variables de entorno que espera esa imagen.
Trata este token como un secreto. No lo pegues en un foro público, una captura de pantalla, un ticket de soporte ni un repositorio.
Un error de permisos de Docker no es un error de permisos de OpenClaw
Después de añadir un token, el autor original encontró lo siguiente:
permiso denegado al intentar conectarse al socket del demonio de Docker
/var/run/docker.sock: connect: permission denied
La recomendación de la comunidad fue elevar los privilegios temporalmente antes de ejecutar comandos administrativos de Docker:
sudo -i
docker psUsa privilegios de root solo para los comandos que realmente los requieran. No debilites /var/run/docker.sock permisos ni hagas que el socket de Docker sea accesible para cualquiera solo para eliminar el error. El acceso a Docker otorga, en la práctica, control administrativo sobre el host.
El error real de OpenClaw era «Falta la configuración»
Una vez que se pudo acceder a los registros de Docker, apareció el mensaje importante:
Falta la configuración. Ejecuta `openclaw setup` o establece `gateway.mode=local`
Esto era más práctico que la página genérica de «Servicio no disponible». La documentación actual de la puerta de enlace de OpenClaw confirma que esta se niega a iniciarse normalmente a menos que su configuración contenga:
gateway.mode = localEl OpenClaw actual también indica que cualquiera de las dos opciones configuración de openclaw o openclaw onboard --mode local escribe el modo de puerta de enlace local en la configuración persistente.
Por qué GATEWAY_MODE=local no solucionó esta imagen
Una respuesta intermedia de la comunidad sugirió añadir:
GATEWAY_MODE=localEl usuario lo intentó y el bucle de reinicio continuó. Es una corrección importante que debe conservarse: la documentación oficial actual de OpenClaw no define una variable genérica GATEWAY_MODE variable de entorno como sustituto de la configuración persistente gateway.mode configuración utilizada por este flujo de trabajo.
No conviertas cada clave de configuración con puntos de OpenClaw en una variable de entorno inventada en mayúsculas. Usa el método de configuración documentado para la imagen exacta de OpenClaw o la plantilla de implementación.
Por qué --gateway.mode=local produjo «Opción desconocida»
Un intento posterior de la comunidad añadió:
--gateway.mode=localal comando del contenedor de CasaOS. La imagen devolvió entonces:
unknown option '--gateway.mode'El hilo identificó correctamente el motivo: CasaOS estaba añadiendo el indicador a una capa de comandos que no lo aceptaba. La CLI actual de OpenClaw utiliza comandos como openclaw gateway, configuración de openclaw, openclaw onboard, y openclaw config set; gateway.mode es una clave de configuración, no un indicador de ejecución universal de nivel superior que pueda colocarse en cualquier parte de un comando de contenedor.
La imagen de Big-Bear necesitaba un directorio de configuración persistente e inicializado
El diagnóstico final de la comunidad se centró en este montaje:
/DATA/AppData/big-bear-openclaw
→ /home/node/.openclawEl contenedor esperaba su configuración en /home/node/.openclaw, pero el directorio montado no se había inicializado. Esto coincide con la documentación actual de OpenClaw para Docker: el directorio de configuración montado contiene los datos persistentes openclaw.json, datos del perfil de autenticación y secretos respaldados por el entorno.
La sugerencia final del hilo fue ejecutar la configuración dentro del contenedor para que el directorio montado recibiera una configuración real de OpenClaw. Sin embargo, el autor original no volvió para confirmar el resultado después de esa última respuesta. Considérala el diagnóstico más sólido del hilo, no una resolución final verificada.
Prefiere la incorporación actual de Docker de OpenClaw en una instalación nueva
Para una implementación actual, sigue la guía oficial de instalación de Docker de OpenClaw en lugar de reconstruir la secuencia de solución de problemas de 2026 error por error.
OpenClaw ofrece actualmente un script de configuración de Docker que:
- compila o descarga la imagen de la puerta de enlace;
- ejecuta la incorporación;
- genera un token de puerta de enlace;
- escribe la configuración persistente;
- crea los directorios de secretos necesarios;
- inicia la puerta de enlace mediante Docker Compose.
Para una implementación de Docker sin interfaz gráfica, OpenClaw también documenta una incorporación no interactiva con el modo de puerta de enlace local y autenticación mediante token. Es preferible a inventar manualmente variables de entorno o añadir indicadores no compatibles.
Patrón de configuración manual actual
La guía actual de Docker de OpenClaw documenta un patrón manual equivalente a:
openclaw onboard --mode local --no-install-daemon
openclaw config set gateway.mode local
openclaw config set gateway.bind lanEn Docker Compose, esos comandos normalmente se ejecutan mediante el contenedor de CLI o de incorporación específico definido por el proyecto. No pegues comandos del host en una imagen empaquetada de CasaOS sin comprobar primero su punto de entrada y sus montajes.
La documentación actual de la CLI de la puerta de enlace de OpenClaw confirma que openclaw setup y openclaw onboard --mode local crean la configuración local necesaria de la puerta de enlace.
Usa el mismo token de la puerta de enlace en la interfaz de control
La documentación actual de Docker de OpenClaw expone la interfaz de control en el puerto 18789 en la configuración estándar de Compose e indica a los usuarios que peguen en la configuración de la interfaz el token de la puerta de enlace del entorno de implementación.
Una discrepancia de tokens puede provocar fallos de autenticación después de que la puerta de enlace esté operativa, pero es diferente de un contenedor que se cierra repetidamente porque no existe ninguna configuración. Diagnostica primero el inicio y después la autenticación de la interfaz.
No conviertas --allow-unconfigured en una solución permanente
OpenClaw proporciona --allow-unconfigured para un inicio puntual o de desarrollo. La documentación actual indica explícitamente que omite la protección del modo local sin escribir ni reparar la configuración. Es útil para realizar pruebas, pero no sustituye la incorporación adecuada de un servidor persistente.
Lista de comprobación para solucionar problemas del servicio OpenClaw no disponible
- Comprueba si el contenedor de OpenClaw está en ejecución, detenido o reiniciándose.
- Lee los registros actuales del contenedor antes de cambiar la configuración.
- Confirma
OPENCLAW_GATEWAY_TOKENexiste y se trata como un secreto. - Si los comandos de Docker fallan con un error de permisos en el socket, usa un shell administrativo autorizado en lugar de debilitar los permisos del socket de Docker.
- Busca específicamente
Falta la configuraciónogateway.mode=localerrores. - Confirma que la ruta AppData del host esté montada en el directorio de configuración de OpenClaw que espera la imagen.
- Ejecuta el flujo compatible de configuración o incorporación de OpenClaw para que
openclaw.jsonse crea en el almacenamiento persistente. - No dependas de
GATEWAY_MODE=locala menos que la documentación exacta de la imagen lo defina explícitamente. - No añadas
--gateway.mode=locala un comando arbitrario del contenedor de CasaOS. - Reinicia el contenedor y vuelve a comprobar los registros después de escribir la configuración.
- Solo después de que la puerta de enlace permanezca activa, diagnostica la autenticación mediante token de la interfaz de control o la configuración del proveedor del modelo.
Preguntas frecuentes sobre la indisponibilidad del servicio de OpenClaw
¿OpenClaw requiere OPENCLAW_GATEWAY_TOKEN?
Las implementaciones de OpenClaw en Docker admiten y suelen usar OPENCLAW_GATEWAY_TOKEN para la autenticación de la puerta de enlace. El script oficial de configuración puede generar uno automáticamente. Las imágenes de terceros empaquetadas pueden exponer el valor de otra manera, así que sigue el esquema de entorno real de la imagen.
¿Qué significa «permission denied /var/run/docker.sock»?
Significa que el usuario actual del host no puede acceder al demonio de Docker. Por sí solo, no significa que no se pueda escribir en el directorio de datos interno de OpenClaw. Usa una cuenta administrativa autorizada para realizar diagnósticos de Docker.
¿Cómo configuro gateway.mode=local?
Usa el comando compatible de configuración, incorporación o ajustes de OpenClaw para que el valor se escriba en openclaw.json. La documentación actual indica configuración de openclaw o openclaw onboard --mode local crea esta configuración.
¿Debería añadir GATEWAY_MODE=local?
No según este hilo. Esa sugerencia no resolvió el bucle de reinicio de la imagen empaquetada del usuario, y la documentación actual del proyecto considera gateway.mode como configuración, en lugar de como una variable de entorno genérica llamada GATEWAY_MODE.
¿Por qué --gateway.mode=local indica que es una opción desconocida?
Porque la opción se añadió a la capa de comando incorrecta en el paquete de CasaOS. Una clave de configuración con puntos no es automáticamente un argumento de línea de comandos válido para todos los binarios o puntos de entrada de OpenClaw.
¿Se resolvió definitivamente el hilo de la comunidad?
El hilo llegó a un diagnóstico final sólido —un directorio de configuración persistente sin inicializar— y recomendó ejecutar configuración de openclaw dentro del contenedor. El autor original no publicó una confirmación final después de esa última instrucción, por lo que la página no debe afirmar una resolución verificada que la fuente no contiene.
