Het belangrijkste feit in deze thread uit december 2025 is dat deze niet eindigde met een werkende installatie van AdGuard Home op de ZimaBoard 2. De oorspronkelijke gebruiker probeerde de suggesties van de community uit en meldde vervolgens dat AdGuard Home op een afzonderlijke Umbrel-server werkte, terwijl de implementatie op ZimaOS onbeschikbaar bleef. Dit is dus een artikel over probleemoplossing en geen installatiehandleiding met een gegarandeerd werkend resultaat.
De schermafbeeldingen en reacties laten nog steeds verschillende nuttige controles zien: de toepassing had afzonderlijke toewijzingen voor DNS en de webinterface, draaide met bridgenetwerken en de community richtte zich op poortconflicten in plaats van op de UniFi-gateway.
Wat “Service Unavailable” wel en niet vertelt
Een pagina met de melding Service Unavailable bewijst dat een bepaald HTTP-pad antwoordde, maar laat niet zien of het AdGuard-proces de initialisatie heeft voltooid, of het omgekeerde pad naar de juiste interne poort verwijst en of DNS-poort 53 succesvol kon worden gebonden.
Begin niet met het wijzigen van routerinstellingen wanneer de service op de lokale ZimaOS-host zelf nog niet gezond is.
De bronconfiguratie publiceerde DNS- en webpoorten afzonderlijk
De eerste installatie van AdGuard Home gebruikt poort 3000
De huidige Docker-richtlijnen voor AdGuard Home maken onderscheid tussen de initiële installatiewizard en de normale beheerinterface. In een nieuwe container wordt TCP-poort 3000 gebruikt voor de eerste installatiestroom. Na de configuratie gebruikt de normale HTTP-interface meestal poort 80, tenzij de gebruiker deze wijzigt.
Dit belangrijke detail ontbrak in het korte antwoord van de community. Een hosttoewijzing zoals 8080:80 kan correct zijn voor de interface na de installatie, maar toch niet het initiële installatie-eindpunt beschikbaar stellen dat een nieuwe container verwacht.
Vergelijk de app met de huidige vereisten van AdGuard Home voor Docker-poorten en -volumes voordat je de router wijzigt.
DNS vereist poort 53 via zowel TCP als UDP
De beantwoorder uit de community wees er terecht op dat AdGuard Home poort 53 nodig heeft voor normale DNS-service. Zowel TCP als UDP moeten beschikbaar zijn wanneer de container DNS aan het LAN moet leveren.
Als een andere Pi-hole-, AdGuard-, systeemresolver- of DNS-container poort 53 al gebruikt, kan de nieuwe service zich niet normaal binden. De host controleren op een bestaande listener is nuttiger dan de WebUI-poort steeds opnieuw wijzigen.
De WebUI-poort en DNS-poort zijn verschillende problemen
Een conflict op poort 80 of 3000 kan ervoor zorgen dat je de beheerinterface niet kunt openen, terwijl DNS zelf nog gezond is. Een conflict op poort 53 kan verhinderen dat de DNS-service start, zelfs wanneer het dashboard wel opent. Houd deze scenario's tijdens de diagnose gescheiden.
Hostmodus werd voorgesteld, maar was niet aantoonbaar noodzakelijk
De beantwoorder uit de community adviseerde de hostnetwerkmodus te proberen, met als reden dat bridgemodus DNS-poorten soms ingewikkelder maakt. De oorspronkelijke poster kwam na die wijziging echter nooit terug met een succesvol resultaat op ZimaOS.
Presenteer hostnetwerken daarom niet als verplicht. De onderhouden Docker-implementatie van AdGuard Home ondersteunt expliciete poorttoewijzingen. Bridgemodus kan werken wanneer de vereiste poorten vrij zijn en correct zijn toegewezen.
De UniFi Cloud Gateway werd niet als oorzaak aangewezen
De gebruiker vroeg specifiek of de UniFi Cloud Gateway Max wijzigingen nodig had. Het antwoord vanuit de community was dat er geen routerwijziging nodig zou moeten zijn om AdGuard Home lokaal te openen en te configureren.
Routerwijzigingen komen later, wanneer je besluit om LAN-clients AdGuard Home voor DNS of DHCP te laten gebruiken. Ze herstellen geen container die de lokale initialisatie niet kan voltooien.
Houd /opt/adguardhome/work en /opt/adguardhome/conf permanent
AdGuard Home slaat runtimegegevens en configuratie op in permanente mappen. Als die paden opnieuw worden aangemaakt, alleen-lezen worden aangekoppeld of naar een onverwachte locatie verwijzen, kan een container zich gedragen alsof het een nieuwe installatie is of instellingen verliezen nadat de container opnieuw is aangemaakt.
De schermafbeeldingen van de bron lieten al permanente volumes zien. Controleer bij een volledige herinstallatie dus of die bestaande mappen opnieuw worden gebruikt, in plaats van ervan uit te gaan dat de toepassing schoon start.
Een betere volgorde voor de diagnose
- Controleer het containerlog op opstart- of bindingsfouten.
- Bevestig of de eerste installatiepoort 3000 nodig is.
- Bevestig afzonderlijk de normale WebUI-toewijzing.
- Controleer of TCP- en UDP-poort 53 vrij zijn op de host.
- Controleer of de permanente configuratie- en werkvolumes schrijfbaar zijn.
- Experimenteer pas daarna met bridge- versus hostnetwerken.
- Stel DNS-wijzigingen op de router uit totdat de lokale service gezond is.
De broncasus bleef op ZimaOS onopgelost
Op 24 december meldde de gebruiker dat AdGuard Home op een Umbrel-server werkte, maar dat het nog steeds niet lukte om de implementatie op de ZimaBoard 2 te laten werken. De gebruiker sloot het hulpverzoek omdat de service elders beschikbaar was, niet omdat de installatie op ZimaOS was opgelost.
Veelgestelde vragen over de melding Service Unavailable in AdGuard Home
Welke poort wordt gebruikt voor de eerste installatie?
De huidige Docker-instructies voor AdGuard Home gebruiken TCP-poort 3000 voor de initiële configuratiewizard.
Welke poorten worden gebruikt voor normale DNS?
Poort 53 via zowel TCP als UDP.
Vereist AdGuard Home hostnetwerken op ZimaOS?
Dat werd in de brondiscussie niet bewezen. Het was een suggestie van de community voor probleemoplossing.
Is de oorspronkelijke ZimaOS-casus opgelost?
Nee. De gebruiker verplaatste de service naar een andere server en beëindigde de thread zonder werkende ZimaOS-configuratie.
