Si Sonarr, Radarr, Lidarr, Transmission u otros contenedores de ZimaOS pueden comunicarse entre sí mediante la dirección IP, pero no pueden utilizar nombres estables como transmission:9091, el problema suele ser la resolución de nombres, no la conectividad básica entre contenedores. Esta distinción se convirtió en el hallazgo clave de este hilo de la comunidad de IceWhale de noviembre de 2025.
El puente predeterminado de Docker bridge La red no proporciona DNS automático para los nombres de los contenedores de la misma forma que un puente definido por el usuario. El hilo también reveló una segunda complicación específica de ZimaOS: las redes de puente creadas manualmente podían existir en Docker antes de aparecer correctamente en la interfaz web de ZimaOS, y la interfaz podía rechazar redes de Docker válidas por lo demás debido a las expectativas de las etiquetas de Compose.
El síntoma clave: la IP funciona, pero el nombre del contenedor falla
El usuario original quería que Radarr se conectara a Transmission utilizando:
http://transmission:9091Las direcciones IP de los contenedores cambiaban después de reinicios o actualizaciones, por lo que codificarlas manualmente no era fiable. Los contenedores podían comunicarse entre sí mediante IP, pero las llamadas basadas en el nombre de host fallaban.
Por qué el puente predeterminado de Docker no resuelve este problema
La documentación actual de Docker sobre redes de puente indica que los contenedores del puente predeterminado pueden comunicarse mediante IP, mientras que los puentes definidos por el usuario proporcionan resolución DNS automática entre contenedores.
Por lo tanto, que «todas las aplicaciones usen bridge» no significa necesariamente que estén utilizando un puente definido por el usuario con nombre y el DNS integrado de Docker.
Crear un puente definido por el usuario
sudo -i
docker network create media-netLos contenedores conectados al mismo puente definido por el usuario normalmente pueden resolverse entre sí mediante el nombre del contenedor o el alias de red.
La documentación actual de ZimaOS utiliza el mismo patrón
La documentación actual de ZimaSpace ahora utiliza explícitamente una red personalizada en su guía de Zabbix porque el puente predeterminado no proporciona el comportamiento de DNS deseado entre contenedores:
sudo docker network create zabbix-netConsulta la guía actual de instalación de ZimaOS para Zabbix.
El problema específico de ZimaOS: sincronización de la interfaz web
En el hilo original, crear un puente personalizado mediante Docker o Portainer no hacía que la red estuviera disponible inmediatamente desde la configuración de la aplicación ZimaOS. Los usuarios veían errores como:
se encontró la red internal-network, pero tiene una etiqueta incorrecta
com.docker.compose.network establecido en ""Después de realizar pruebas con un ingeniero, Zima-Giorgio dijo que la red de Docker funcionaba con normalidad, pero que la interfaz web podía estar desincronizada del backend de Docker.
El paso confirmado por la comunidad: reiniciar después de crear la red
sudo -i
docker network create net-a
docker network create net-b
reinicioDespués del reinicio, las redes recién creadas aparecieron en el panel de configuración de la aplicación. Otro participante confirmó que la ausencia del reinicio era el paso clave en su prueba y que la resolución de nombres funcionaba posteriormente en el puente personalizado.
Docker estándar normalmente no requiere reiniciar todo el host después de docker network create; este comportamiento específico de ZimaOS se observó en el hilo de 2025.
Aún persistía un problema de compatibilidad con las etiquetas de Compose
Incluso después de que el reinicio aclarara el problema de sincronización, el hilo documentó otra limitación. ZimaOS podía indicar que una red creada manualmente tenía una com.docker.compose.network etiqueta.
Zima-Giorgio finalmente dijo que la imposibilidad de elegir algunas redes creadas parecía ser un problema y que se derivaría al equipo. El hilo no contiene una confirmación posterior de que se hayan corregido todos los casos límite relacionados con la selección de redes.
Verificar la red desde Docker, no solo desde la interfaz de usuario
docker network inspect media-net
docker inspect CONTAINER_A
docker inspect CONTAINER_BA continuación, prueba la resolución de nombres desde un contenedor:
docker exec CONTAINER_A ping -c 2 CONTAINER_BSi la imagen no incluye ping, utiliza otra herramienta de diagnóstico disponible o un contenedor de prueba temporal en la misma red.
Usa nombres o alias en lugar de cambiar las direcciones IP
Cuando el DNS de Docker funcione en un puente definido por el usuario, configura las aplicaciones con un punto de conexión estable como:
http://transmission:9091o un alias de red definido en Compose.
¿Fue Cloudflared la causa?
El hilo original no identificó Cloudflared como la causa principal. La comunicación mediante IP ya funcionaba y el fallo coincidía con el comportamiento del DNS y la resolución de nombres de Docker.
Solución temporal: IP del host y puertos publicados
El autor original reservó temporalmente una IP estática de la red local para el host de ZimaOS y configuró las aplicaciones para usar esa IP junto con los puertos publicados. Esto puede funcionar, pero utiliza la ruta de puertos publicados del host en lugar del enrutamiento interno de Docker mediante nombres de servicio.
Lista de comprobación de resolución de nombres de contenedores de ZimaOS
- Confirma que la comunicación de IP a IP funciona.
- Comprueba si los contenedores están en el puente predeterminado o en un puente definido por el usuario con nombre.
- Crea un puente personalizado cuando necesites un DNS estable.
- Conecta todos los servicios necesarios a la misma red personalizada.
- En las versiones de ZimaOS correspondientes al hilo original, reinicia para que la interfaz web actualice el estado de la red de Docker.
- Verifica con
docker inspectydocker network inspect. - Prueba la resolución del nombre del contenedor desde el interior de otro contenedor.
- Si ZimaOS informa de una discrepancia en la etiqueta de Compose, trátala como un problema de la interfaz o de la integración, no como una prueba de que la red de Docker no es válida.
Preguntas frecuentes sobre el puente de Docker de ZimaOS
¿Por qué los contenedores del puente no pueden resolverse entre sí por nombre?
El puente predeterminado de Docker permite la comunicación mediante IP, pero no proporciona DNS automático por nombre de contenedor como sí lo hace un puente definido por el usuario.
¿Tengo que reiniciar después de docker network create?
Docker estándar normalmente no lo hace. En este hilo de ZimaOS de 2025, fue necesario reiniciar para que la interfaz web de ZimaOS obtuviera el nuevo estado de red.
¿Cloudflared rompe el DNS del puente de Docker?
El hilo original no lo estableció.
¿Debo asignar IP estáticas de Docker?
Normalmente no. Los DNS y alias de Docker definidos por el usuario son más portátiles que las IP de contenedor codificadas.
