Det viktiga i den här tråden från december 2025 är att den inte slutade med en fungerande installation av AdGuard Home på ZimaBoard 2. Källanvändaren provade communityns förslag och rapporterade sedan att AdGuard Home fungerade på en separat Umbrel-server, medan ZimaOS-distributionen fortfarande inte var tillgänglig. Det här är alltså en felsökningsartikel, inte en färdig installationsguide.
Skärmbilderna och svaren visar ändå flera användbara kontroller: applikationen hade separata mappningar för DNS och webbgränssnittet, kördes med bryggad nätverkstrafik och communityn fokuserade på portkonflikter snarare än på UniFi-gatewayen.
Vad ”Service Unavailable” säger – och inte säger
En sida med meddelandet Service Unavailable bevisar att någon HTTP-sökväg svarade, men den visar inte om AdGuard-processen slutförde initieringen, om den omvända sökvägen pekar på rätt intern port eller om DNS-port 53 kunde bindas korrekt.
Börja inte med att ändra routerinställningarna när tjänsten inte ens är felfri på den lokala ZimaOS-värden.
Källkonfigurationen publicerade DNS- och webbportar separat
Förstagångsinstallationen av AdGuard Home använder port 3000
Aktuell Docker-dokumentation för AdGuard Home skiljer mellan den inledande installationsguiden och det vanliga administratörsgränssnittet. I en ny container används TCP-port 3000 för den första installationsprocessen. Efter konfiguration använder det vanliga HTTP-gränssnittet vanligtvis port 80, om användaren inte ändrar den.
Det här är en viktig detalj som saknades i det korta communitysvaret. En värdmappning som 8080:80 kan vara korrekt för gränssnittet efter installationen, men ändå inte exponera den första installationsslutpunkt som en ny container förväntar sig.
Jämför applikationen med AdGuard Homes aktuella krav på Docker-portar och volymer innan du ändrar routern.
DNS kräver port 53 över både TCP och UDP
Communitymedlemmen påpekade korrekt att AdGuard Home behöver port 53 för vanlig DNS-tjänst. Både TCP och UDP bör vara tillgängliga när containern förväntas tillhandahålla DNS till det lokala nätverket.
Om en annan Pi-hole-, AdGuard-, systemresolver- eller DNS-container redan använder port 53 kan den nya tjänsten inte binda porten normalt. Att kontrollera om värden redan har en lyssnande tjänst är mer användbart än att upprepade gånger ändra webbgränssnittets port.
Webbgränssnittets port och DNS-porten är olika problem
En konflikt på port 80 eller 3000 kan hindra dig från att öppna administrationsgränssnittet, även om själva DNS-tjänsten fortfarande fungerar. En konflikt på port 53 kan förhindra att DNS-tjänsten startar, även när kontrollpanelen öppnas. Håll dessa felsökningsspår åtskilda.
Värdläge föreslogs, men det bevisades inte vara nödvändigt
Communitymedlemmen rekommenderade att prova nätverksläge för värd och hävdade att bryggat läge ibland komplicerar DNS-portar. Den ursprungliga skribenten återkom aldrig med ett lyckat ZimaOS-resultat efter den ändringen.
Presentera därför inte värdnätverk som ett krav. AdGuard Homes underhållna Docker-distribution stöder explicita portmappningar. Bryggat läge kan fungera när de nödvändiga portarna är lediga och korrekt mappade.
UniFi Cloud Gateway identifierades inte som orsaken
Användaren frågade specifikt om UniFi Cloud Gateway Max behövde ändras. Communitysvaret var att ingen routerändring borde behövas enbart för att öppna och konfigurera AdGuard Home lokalt.
Routerändringar kommer senare, när du bestämmer dig för att låta klienterna i det lokala nätverket använda AdGuard Home för DNS eller DHCP. De reparerar inte en container som inte kan slutföra den lokala initieringen.
Se till att /opt/adguardhome/work och /opt/adguardhome/conf är beständiga
AdGuard Home lagrar kördata och konfiguration i beständiga kataloger. Om dessa sökvägar återskapas, monteras skrivskyddade eller pekar någon annanstans än väntat kan en container bete sig som en ny installation eller förlora inställningar när den återskapas.
Källskärmbilderna visade redan beständiga volymer, så en fullständig ominstallation bör kontrollera om de befintliga mapparna återanvänds i stället för att anta att applikationen startar från början.
En bättre felsökningsordning
- Kontrollera containerloggen efter start- eller bindningsfel.
- Bekräfta om installationsporten 3000 behövs.
- Bekräfta mappningen för det vanliga webbgränssnittet separat.
- Kontrollera att TCP- och UDP-port 53 är lediga på värden.
- Verifiera att de beständiga konfigurations- och arbetsvolymerna är skrivbara.
- Experimentera först därefter med bryggat nätverk kontra värdnätverk.
- Vänta med DNS-ändringar i routern tills den lokala tjänsten fungerar korrekt.
Fallet i källan förblev olöst på ZimaOS
Den 24 december rapporterade användaren att AdGuard Home fungerade på en Umbrel-server, men att de fortfarande inte kunde få distributionen på ZimaBoard 2 att fungera. De avslutade hjälpförfrågan eftersom tjänsten var tillgänglig någon annanstans, inte för att ZimaOS-installationen hade åtgärdats.
Vanliga frågor om AdGuard Home och ”Service Unavailable”
Vilken port används för förstagångsinstallationen?
Aktuella Docker-anvisningar för AdGuard Home använder TCP-port 3000 för den inledande konfigurationsguiden.
Vilka portar används för vanlig DNS?
Port 53 över både TCP och UDP.
Kräver AdGuard Home värdnätverk på ZimaOS?
Det bevisades inte i källtråden. Det var ett förslag från communityn för felsökning.
Löstes det ursprungliga ZimaOS-fallet?
Nej. Användaren flyttade tjänsten till en annan server och avslutade tråden utan en fungerande ZimaOS-konfiguration.
