Le fait important de cette discussion de décembre 2025 est qu’elle ne s’est pas terminée par une installation fonctionnelle d’AdGuard Home sur le ZimaBoard 2. L’utilisateur à l’origine de la discussion a essayé les suggestions de la communauté, puis a signalé qu’AdGuard Home fonctionnait sur un serveur Umbrel distinct, tandis que le déploiement sur ZimaOS restait indisponible. Il s’agit donc d’un article de dépannage, et non d’une procédure d’installation résolue.
Les captures d’écran et les réponses révèlent néanmoins plusieurs vérifications utiles : l’application disposait de mappages distincts pour le DNS et l’interface web, elle fonctionnait en réseau bridge, et la communauté s’est concentrée sur les conflits de ports plutôt que sur la passerelle UniFi.
Ce que « Service Unavailable » indique — et n’indique pas
Une page Service Unavailable prouve qu’un chemin HTTP a répondu, mais elle ne permet pas de déterminer si le processus AdGuard a terminé son initialisation, si le chemin inverse pointe vers le bon port interne, ou si le port DNS 53 a pu être associé correctement.
Ne commencez pas par modifier les paramètres du routeur lorsque le service n’est même pas opérationnel sur l’hôte ZimaOS local.
La configuration d’origine publiait séparément les ports DNS et web
La première configuration d’AdGuard Home utilise le port 3000
Les instructions Docker actuelles d’AdGuard Home distinguent l’assistant de configuration initiale de l’interface d’administration normale. Dans un conteneur fraîchement créé, le port TCP 3000 est utilisé pour la première configuration. Après la configuration, l’interface HTTP normale utilise généralement le port 80, sauf si l’utilisateur le modifie.
Il s’agit d’un détail important absent de la brève réponse de la communauté. Un mappage d’hôte tel que 8080:80 peut être correct pour l’interface post-configuration tout en n’exposant pas le point de terminaison de configuration initiale attendu par un conteneur vierge.
Comparez l’application avec les exigences actuelles d’AdGuard Home concernant les ports Docker et les volumes avant de modifier le routeur.
Le DNS nécessite le port 53 en TCP et en UDP
Le membre de la communauté a correctement souligné qu’AdGuard Home a besoin du port 53 pour assurer le service DNS standard. Les protocoles TCP et UDP doivent tous deux être disponibles lorsque le conteneur est destiné à fournir le DNS au réseau local.
Si un autre Pi-hole, AdGuard, résolveur système ou conteneur DNS utilise déjà le port 53, le nouveau service ne peut pas s’y associer normalement. Vérifier la présence d’un processus à l’écoute sur l’hôte est plus utile que de modifier sans cesse le port de l’interface web.
Le port de l’interface web et le port DNS sont deux problèmes différents
Un conflit sur le port 80 ou 3000 peut vous empêcher d’ouvrir l’interface d’administration alors que le DNS fonctionne encore correctement. Un conflit sur le port 53 peut empêcher le service DNS de démarrer même si le tableau de bord s’ouvre. Gardez ces deux pistes séparées pendant le diagnostic.
Le mode hôte a été suggéré, mais sa nécessité n’a pas été démontrée
Le membre de la communauté a recommandé d’essayer le mode réseau hôte, en faisant valoir que le mode bridge complique parfois la gestion des ports DNS. L’auteur de la discussion n’est jamais revenu avec un résultat ZimaOS fonctionnel après cette modification.
Ne présentez donc pas le réseau hôte comme obligatoire. Le déploiement Docker maintenu d’AdGuard Home prend en charge les mappages de ports explicites. Le mode bridge peut fonctionner lorsque les ports requis sont libres et correctement mappés.
La passerelle Cloud UniFi n’a pas été identifiée comme étant à l’origine du problème
L’utilisateur demandait précisément si la UniFi Cloud Gateway Max nécessitait des modifications. La réponse de la communauté indiquait qu’aucune modification du routeur ne devrait être nécessaire pour ouvrir et configurer AdGuard Home localement.
Les modifications du routeur interviennent plus tard, lorsque vous décidez de faire utiliser AdGuard Home comme serveur DNS ou DHCP par les clients du réseau local. Elles ne réparent pas un conteneur incapable de terminer son initialisation locale.
Conservez /opt/adguardhome/work et /opt/adguardhome/conf dans des volumes persistants
AdGuard Home stocke ses données d’exécution et sa configuration dans des répertoires persistants. Si ces chemins sont recréés, montés en lecture seule ou associés à un emplacement inattendu, le conteneur peut se comporter comme une nouvelle installation ou perdre ses paramètres après sa recréation.
Les captures d’écran d’origine montraient déjà des volumes persistants. Une réinstallation complète doit donc vérifier si ces dossiers existants sont réutilisés, plutôt que de supposer que l’application démarre avec une configuration vierge.
Un meilleur ordre de diagnostic
- Vérifiez le journal du conteneur pour repérer les erreurs de démarrage ou d’association de ports.
- Confirmez si le port 3000 de la configuration initiale est nécessaire.
- Vérifiez séparément le mappage normal de l’interface web.
- Assurez-vous que les ports 53 TCP et UDP sont libres sur l’hôte.
- Vérifiez que les volumes persistants de configuration et de travail sont accessibles en écriture.
- Ce n’est qu’ensuite que vous pourrez essayer le réseau bridge ou le réseau hôte.
- Attendez que le service local soit opérationnel avant de modifier le DNS du routeur.
Le cas d’origine est resté non résolu sur ZimaOS
Le 24 décembre, l’utilisateur a indiqué qu’AdGuard Home fonctionnait sur un serveur Umbrel, mais qu’il ne parvenait toujours pas à faire fonctionner le déploiement sur le ZimaBoard 2. Il a clôturé la demande d’aide parce que le service était disponible ailleurs, et non parce que l’installation ZimaOS avait été réparée.
FAQ : Service Unavailable avec AdGuard Home
Quel port est utilisé pour la première configuration ?
Les instructions Docker actuelles d’AdGuard Home utilisent le port TCP 3000 pour l’assistant de configuration initiale.
Quels ports sont utilisés pour le DNS standard ?
Le port 53 en TCP et en UDP.
AdGuard Home nécessite-t-il le réseau hôte sur ZimaOS ?
La discussion d’origine ne l’a pas démontré. Il s’agissait d’une suggestion de dépannage de la communauté.
Le cas ZimaOS d’origine a-t-il été résolu ?
Non. L’utilisateur a déplacé le service vers un autre serveur et a mis fin à la discussion sans configuration ZimaOS fonctionnelle.
