Tu aplicación UniFi Network no necesita su propia dirección 192.168.x.x solo porque Docker le asigne al contenedor una dirección de puente 172.x. En el modo de puente normal, publica los puertos necesarios y configura el host de información de UniFi con un nombre de host o una IP accesible desde la LAN. Los dispositivos de la LAN se comunican con la dirección del host, mientras Docker mantiene el contenedor en su red privada.
El hilo de origen de 2026 confundía la IP interna de puente del contenedor con la dirección que deben usar los dispositivos de la LAN. La documentación actual de LinuxServer lo explica explícitamente: el contenedor de UniFi puede permanecer en modo de puente, y la adopción de dispositivos se gestiona configurando un host de información accesible y conservando el puerto 8080.
Por qué ves una dirección 172.x
Las redes de puente de Docker normalmente asignan a los contenedores direcciones privadas como 172.17.x.x. Esa dirección se utiliza para la red del contenedor, no es la dirección que deben usar tus switches y puntos de acceso desde la LAN física.
Usa la IP del host de ZimaOS para los puertos publicados
Si el servidor ZimaOS es 192.168.1.20 y UniFi publica los puertos 8443 y 8080, accedes a la interfaz y al endpoint de información a través del host:
https://192.168.1.20:8443
http://192.168.1.20:8080/informConfigura el host de información de UniFi
La documentación de UniFi de LinuxServer actual indica que los usuarios de Docker deben establecer el host de información o anulación con un nombre de host o una IP accesible para los dispositivos UniFi.
Normalmente, será la IP de ZimaOS en la LAN o un nombre DNS local estable.
Mantén el puerto 8080 asignado 1:1
LinuxServer advierte que la comunicación con los dispositivos UniFi requiere 8080:8080, a menos que también realices cambios equivalentes en las propiedades del sistema de UniFi. No asignes arbitrariamente el puerto de host 18080 al puerto 8080 del contenedor esperando que la adopción siga siendo estable.
El modo de host no equivale a “darle al contenedor su propia IP de la LAN”
El modo de red del host hace que el contenedor comparta el espacio de nombres de red del host. No crea una segunda dirección 192.168.x.x para el contenedor.
Si realmente necesitas una IP independiente en la LAN, se trata de un diseño macvlan/ipvlan, que añade ciertas limitaciones de enrutamiento y comunicación entre el host y el contenedor.
El modo de puente suele ser la opción más sencilla
El modo de puente mantiene la aplicación aislada, hace explícita la asignación de puertos y funciona con la anulación documentada del host de información. Normalmente es suficiente para adoptar y gestionar el controlador.
Recuerda el requisito de MongoDB externo
La aplicación UniFi Network actual de LinuxServer requiere una instancia externa de MongoDB. Si el modo de host falla mientras el modo de puente funciona, confirma que el nombre de host de MongoDB y la ruta de red sigan siendo válidos con el modo de red seleccionado.
No expongas directamente el controlador a Internet
Mantén la administración en la LAN o detrás de una red privada de acceso remoto. La guía de redes privadas ofrece un contexto de red más seguro.
Usa una dirección de host estable
Como los dispositivos adoptados reciben la ubicación del controlador, asigna al host de ZimaOS una IP estable en la LAN mediante una reserva DHCP en el router o una dirección estática gestionada cuidadosamente. Si la dirección del host del controlador cambia de 192.168.1.20 a otra, los dispositivos pueden seguir intentando contactar con el endpoint de información antiguo.
Entiende qué puertos sirven para cada función
La interfaz web de UniFi en 8443 es solo una parte. El tráfico de información de los dispositivos utiliza el puerto 8080, y otros servicios de descubrimiento/STUN usan puertos adicionales según la implementación. Por lo tanto, un controlador puede parecer saludable en el navegador mientras los dispositivos no consiguen adoptarse.
Consulta la tabla de puertos actual de LinuxServer y expón solo los que necesite tu entorno, pero conserva exactamente los puertos necesarios para la gestión de dispositivos.
Restaura desde Synology con cuidado
Si estás migrando el controlador desde Synology, restaura una copia de seguridad de UniFi solo después de que el nuevo contenedor de ZimaOS y MongoDB externo funcionen correctamente. Después, verifica el host de información y el estado de los dispositivos antes de apagar el controlador antiguo.
No ejecutes dos controladores activos reclamando los mismos sitios o dispositivos durante la migración, a menos que comprendas las consecuencias para la adopción.
Cuándo resulta útil una IP de LAN dedicada
Una dirección macvlan/ipvlan puede ser útil para una segmentación estricta del firewall, evitar conflictos de puertos o hacer que el controlador parezca un dispositivo independiente. No es necesaria simplemente porque Docker muestre una dirección interna 172.x.
Si eliges macvlan, planifica la limitación habitual de comunicación entre el host y macvlan y verifica que MongoDB siga siendo accesible desde la red del controlador.
Preguntas frecuentes
¿El contenedor de UniFi necesita una IP 192.168 en la LAN?
No. En muchas implementaciones, el modo de puente junto con los puertos publicados y un host de información accesible es suficiente.
¿Por qué los dispositivos UniFi no consiguen adoptarse en Docker?
Una causa habitual es anunciar una IP del contenedor que no es accesible. Configura el host de información con la dirección de ZimaOS en la LAN u otro nombre de host accesible.
¿Debería usar la red del host?
Solo si tienes un motivo concreto. El modo de host comparte la red del host de ZimaOS; no crea una IP de LAN dedicada.
¿Cuándo debería usar macvlan?
Úsalo solo cuando el contenedor necesite realmente su propia identidad en la LAN y comprendas la complejidad adicional del enrutamiento y del acceso desde el host.
