Najważniejszym faktem w tym wątku z grudnia 2025 roku jest to, że nie zakończył się on działającą instalacją AdGuard Home na ZimaBoard 2. Użytkownik źródłowy wypróbował sugestie społeczności, a następnie poinformował, że AdGuard Home działał na osobnym serwerze Umbrel, podczas gdy wdrożenie w ZimaOS nadal było niedostępne. To sprawia, że jest to artykuł dotyczący rozwiązywania problemów, a nie sprawdzona instrukcja instalacji.
Zrzuty ekranu i odpowiedzi ujawniają jednak kilka przydatnych informacji: aplikacja miała oddzielne mapowania portów DNS i interfejsu WWW, działała w trybie sieciowym bridge, a społeczność koncentrowała się na konfliktach portów, a nie na bramie UniFi.
Co oznacza komunikat „Service Unavailable”, a czego nie oznacza
Strona „Service Unavailable” dowodzi, że jakaś ścieżka HTTP udzieliła odpowiedzi, ale nie wskazuje, czy proces AdGuard zakończył inicjalizację, czy ścieżka zwrotna prowadzi do właściwego portu wewnętrznego ani czy port DNS 53 został pomyślnie przypisany.
Nie zaczynaj od zmiany ustawień routera, gdy usługa nie działa poprawnie nawet na lokalnym hoście ZimaOS.
W konfiguracji źródłowej porty DNS i WWW były publikowane oddzielnie
Pierwsza konfiguracja AdGuard Home korzysta z portu 3000
Aktualne wytyczne dotyczące Dockera dla AdGuard Home rozróżniają kreator pierwszej konfiguracji od zwykłego interfejsu administracyjnego. W świeżo utworzonym kontenerze port TCP 3000 służy do pierwszego uruchomienia kreatora konfiguracji. Po zakończeniu konfiguracji standardowy interfejs HTTP zwykle korzysta z portu 80, chyba że użytkownik go zmieni.
To ważny szczegół, którego zabrakło w krótkiej odpowiedzi społeczności. Mapowanie hosta, takie jak 8080:80, może być poprawne dla interfejsu po konfiguracji, a jednocześnie nie udostępniać początkowego punktu konfiguracji oczekiwanego przez świeży kontener.
Przed zmianą ustawień routera porównaj aplikację z aktualnymi wymaganiami AdGuard Home dotyczącymi portów i wolumenów w Dockerze.
DNS wymaga portu 53 zarówno przez TCP, jak i UDP
Osoba odpowiadająca w społeczności słusznie zwróciła uwagę, że AdGuard Home potrzebuje portu 53 do standardowej obsługi DNS. Gdy kontener ma udostępniać DNS urządzeniom w sieci LAN, należy zapewnić dostęp zarówno przez TCP, jak i UDP.
Jeśli inny Pi-hole, AdGuard, systemowy resolver lub kontener DNS już zajmuje port 53, nowa usługa nie będzie mogła prawidłowo go przypisać. Sprawdzenie, czy na hoście działa już nasłuchująca usługa, jest bardziej przydatne niż wielokrotne zmienianie portu interfejsu WWW.
Port interfejsu WWW i port DNS to dwa różne problemy
Konflikt na porcie 80 lub 3000 może uniemożliwić otwarcie interfejsu administracyjnego, podczas gdy sam DNS nadal działa poprawnie. Konflikt na porcie 53 może uniemożliwić uruchomienie usługi DNS, nawet jeśli panel się otwiera. Podczas diagnozowania rozpatruj te ścieżki oddzielnie.
Zasugerowano tryb hosta, ale nie udowodniono, że jest konieczny
Osoba odpowiadająca w społeczności zaleciła wypróbowanie trybu sieci hosta, twierdząc, że tryb bridge czasami komplikuje obsługę portów DNS. Autor oryginalnego wpisu nie wrócił jednak z informacją o pomyślnym uruchomieniu w ZimaOS po tej zmianie.
Dlatego nie przedstawiaj sieci hosta jako rozwiązania obowiązkowego. Utrzymywane wdrożenie AdGuard Home w Dockerze obsługuje jawne mapowania portów. Tryb bridge może działać, jeśli wymagane porty są wolne i prawidłowo zmapowane.
Nie wskazano bramy UniFi Cloud Gateway jako przyczyny problemu
Użytkownik zapytał konkretnie, czy UniFi Cloud Gateway Max wymaga zmian. Odpowiedź społeczności była taka, że sama lokalna konfiguracja i otwarcie AdGuard Home nie powinny wymagać żadnych zmian w routerze.
Zmiany w routerze wprowadza się później, gdy zdecydujesz, że urządzenia w sieci LAN mają korzystać z AdGuard Home jako serwera DNS lub DHCP. Nie naprawią one kontenera, który nie może zakończyć lokalnej inicjalizacji.
Zachowaj trwałość katalogów /opt/adguardhome/work i /opt/adguardhome/conf
AdGuard Home przechowuje dane robocze i konfigurację w trwałych katalogach. Jeśli te ścieżki są odtwarzane, montowane tylko do odczytu lub wskazują nieoczekiwane lokalizacje, kontener może zachowywać się jak nowa instalacja albo utracić ustawienia po ponownym utworzeniu.
Zrzuty ekranu źródłowej konfiguracji już pokazywały trwałe wolumeny, dlatego podczas pełnej reinstalacji należy sprawdzić, czy wykorzystywane są istniejące foldery, zamiast zakładać, że aplikacja uruchamia się z całkowicie czystą konfiguracją.
Lepsza kolejność diagnozowania
- Sprawdź dziennik kontenera pod kątem błędów uruchamiania lub przypisywania portów.
- Potwierdź, czy potrzebny jest port pierwszej konfiguracji 3000.
- Osobno potwierdź mapowanie standardowego interfejsu WWW.
- Sprawdź, czy port 53 dla TCP i UDP jest wolny na hoście.
- Zweryfikuj, czy trwałe wolumeny konfiguracji i danych roboczych są zapisywalne.
- Dopiero potem eksperymentuj z trybem bridge i trybem hosta.
- Odłóż zmiany DNS w routerze do momentu, gdy usługa lokalna będzie działać poprawnie.
Przypadek źródłowy pozostał nierozwiązany w ZimaOS
24 grudnia użytkownik poinformował, że udało mu się uruchomić AdGuard Home na serwerze Umbrel, ale nadal nie mógł uruchomić wdrożenia na ZimaBoard 2. Zakończył prośbę o pomoc, ponieważ usługa była dostępna gdzie indziej, a nie dlatego, że instalacja w ZimaOS została naprawiona.
Najczęstsze pytania dotyczące komunikatu „Service Unavailable” w AdGuard Home
Z którego portu korzysta pierwsza konfiguracja?
Aktualne instrukcje dotyczące Dockera dla AdGuard Home wykorzystują port TCP 3000 dla początkowego kreatora konfiguracji.
Jakie porty są używane do standardowej obsługi DNS?
Port 53 zarówno przez TCP, jak i UDP.
Czy AdGuard Home wymaga trybu sieci hosta w ZimaOS?
Wątek źródłowy tego nie udowodnił. Była to sugestia społeczności dotycząca rozwiązywania problemów.
Czy pierwotny przypadek w ZimaOS został rozwiązany?
Nie. Użytkownik przeniósł usługę na inny serwer i zakończył wątek bez działającej konfiguracji ZimaOS.
