El dato importante de este hilo de diciembre de 2025 es que no terminó con una instalación funcional de AdGuard Home en el ZimaBoard 2. El usuario que publicó la consulta probó las sugerencias de la comunidad y luego informó que AdGuard Home funcionaba en un servidor Umbrel independiente, mientras que la implementación en ZimaOS seguía sin estar disponible. Por eso, este es un artículo de resolución de problemas, no una receta de instalación resuelta.
Las capturas de pantalla y las respuestas aún revelan varias comprobaciones útiles: la aplicación tenía asignaciones independientes para DNS y la interfaz web, se ejecutaba en una red en modo puente y la comunidad se centró en los conflictos de puertos, no en la puerta de enlace UniFi.
Lo que indica y lo que no indica «Service Unavailable»
Una página de «Service Unavailable» demuestra que alguna ruta HTTP respondió, pero no identifica si el proceso de AdGuard terminó de inicializarse, si la ruta inversa apunta al puerto interno correcto o si el puerto DNS 53 se pudo enlazar correctamente.
No empieces cambiando la configuración del router cuando el servicio ni siquiera está funcionando correctamente en el host local de ZimaOS.
La configuración original publicó los puertos DNS y web por separado
La configuración inicial de AdGuard Home utiliza el puerto 3000
La documentación actual de AdGuard Home para Docker distingue el asistente de configuración inicial de la interfaz de administración normal. En un contenedor nuevo, el puerto TCP 3000 se utiliza para el proceso de configuración inicial. Después de configurar el servicio, la interfaz HTTP normal suele utilizar el puerto 80, a menos que el usuario lo cambie.
Este es un detalle importante que falta en la breve respuesta de la comunidad. Una asignación del tipo 8080:80 puede ser correcta para la interfaz después de la configuración y, aun así, no exponer el endpoint de configuración inicial que espera un contenedor nuevo.
Compara la aplicación con los requisitos actuales de puertos y volúmenes de AdGuard Home para Docker antes de cambiar el router.
El DNS requiere el puerto 53 tanto por TCP como por UDP
El miembro de la comunidad señaló correctamente que AdGuard Home necesita el puerto 53 para ofrecer el servicio DNS normal. Tanto TCP como UDP deben estar disponibles cuando se espera que el contenedor proporcione DNS a la LAN.
Si otro Pi-hole, AdGuard, resolvedor del sistema o contenedor DNS ya ocupa el puerto 53, el nuevo servicio no podrá enlazarse correctamente. Comprobar si ya existe un proceso escuchando en el host es más útil que cambiar repetidamente el puerto de la interfaz web.
El puerto de la interfaz web y el puerto DNS son problemas diferentes
Un conflicto en el puerto 80 o 3000 puede impedirte abrir la interfaz de administración aunque el DNS siga funcionando correctamente. Un conflicto en el puerto 53 puede impedir que se inicie el servicio DNS incluso cuando el panel se abre. Mantén estas dos líneas de diagnóstico separadas.
Se sugirió el modo de red del host, pero no se demostró que fuera necesario
El miembro de la comunidad recomendó probar el modo de red del host, argumentando que el modo puente a veces complica el uso de puertos DNS. El autor original de la consulta nunca volvió con un resultado exitoso en ZimaOS después de ese cambio.
Por lo tanto, no presentes la red del host como un requisito obligatorio. La implementación mantenida de AdGuard Home para Docker admite asignaciones de puertos explícitas. El modo puente puede funcionar cuando los puertos necesarios están libres y se han asignado correctamente.
No se identificó la puerta de enlace UniFi Cloud Gateway como la causa
El usuario preguntó específicamente si era necesario realizar cambios en la UniFi Cloud Gateway Max. La respuesta de la comunidad fue que no debería ser necesario cambiar el router simplemente para abrir y configurar AdGuard Home localmente.
Los cambios en el router vienen después, cuando decidas que los clientes de la LAN utilicen AdGuard Home para DNS o DHCP. No reparan un contenedor que no puede completar la inicialización local.
Mantén persistentes /opt/adguardhome/work y /opt/adguardhome/conf
AdGuard Home almacena los datos de ejecución y la configuración en directorios persistentes. Si esas rutas se vuelven a crear, se montan como de solo lectura o apuntan a una ubicación inesperada, el contenedor puede comportarse como una instalación nueva o perder la configuración al volver a crearse.
Las capturas de pantalla originales ya mostraban volúmenes persistentes, por lo que una reinstalación completa debería comprobar si se están reutilizando esas carpetas existentes, en lugar de suponer que la aplicación se inicia desde cero.
Un orden de diagnóstico mejor
- Comprueba el registro del contenedor en busca de errores de inicio o de enlace.
- Confirma si se necesita el puerto 3000 para la configuración inicial.
- Confirma por separado la asignación normal de la interfaz web.
- Comprueba que los puertos 53 TCP y UDP estén libres en el host.
- Verifica que los volúmenes persistentes de configuración y trabajo tengan permisos de escritura.
- Solo después prueba la red en modo puente frente a la red del host.
- Deja los cambios de DNS del router para cuando el servicio local funcione correctamente.
El caso original siguió sin resolverse en ZimaOS
El 24 de diciembre, el usuario informó que había conseguido que AdGuard Home funcionara en un servidor Umbrel, pero que todavía no podía hacer funcionar la implementación en el ZimaBoard 2. Cerró la solicitud de ayuda porque el servicio estaba disponible en otro lugar, no porque se hubiera solucionado la instalación en ZimaOS.
Preguntas frecuentes sobre «Service Unavailable» de AdGuard Home
¿Qué puerto se utiliza para la configuración inicial?
Las instrucciones actuales de AdGuard Home para Docker utilizan el puerto TCP 3000 para el asistente de configuración inicial.
¿Qué puertos se utilizan para el DNS normal?
El puerto 53 tanto por TCP como por UDP.
¿AdGuard Home requiere la red del host en ZimaOS?
El hilo original no lo demostró. Fue una sugerencia de resolución de problemas de la comunidad.
¿Se solucionó el caso original en ZimaOS?
No. El usuario trasladó el servicio a otro servidor y terminó el hilo sin una configuración funcional en ZimaOS.
