Die wichtige Tatsache in diesem Thread vom Dezember 2025 ist, dass er nicht mit einer funktionierenden AdGuard-Home-Installation auf dem ZimaBoard 2 endete. Der ursprüngliche Nutzer probierte die Vorschläge der Community aus und berichtete anschließend, dass AdGuard Home auf einem separaten Umbrel-Server funktionierte, während die Bereitstellung auf ZimaOS weiterhin nicht verfügbar war. Daher handelt es sich um einen Troubleshooting-Artikel und nicht um eine bewährte Installationsanleitung.
Die Screenshots und Antworten zeigen dennoch mehrere nützliche Prüfungen: Die Anwendung hatte separate Zuordnungen für DNS und Weboberfläche, lief im Bridge-Netzwerkmodus, und die Community konzentrierte sich auf Portkonflikte statt auf das UniFi-Gateway.
Was „Service Unavailable“ aussagt – und was nicht
Eine „Service Unavailable“-Seite beweist, dass irgendein HTTP-Pfad geantwortet hat. Sie zeigt jedoch nicht, ob der AdGuard-Prozess die Initialisierung abgeschlossen hat, ob der Reverse-Pfad auf den richtigen internen Port verweist oder ob DNS erfolgreich an Port 53 gebunden wurde.
Beginnen Sie nicht mit Änderungen an den Router-Einstellungen, wenn der Dienst auf dem lokalen ZimaOS-Host noch nicht einmal fehlerfrei läuft.
Die ursprüngliche Konfiguration veröffentlichte DNS- und Webports getrennt
Die erstmalige Einrichtung von AdGuard Home verwendet Port 3000
Die aktuelle Docker-Dokumentation von AdGuard Home unterscheidet zwischen dem erstmaligen Einrichtungsassistenten und der normalen Administrationsoberfläche. Bei einem neuen Container wird TCP-Port 3000 für den Einrichtungsablauf verwendet. Nach der Konfiguration läuft die normale HTTP-Oberfläche üblicherweise über Port 80, sofern der Nutzer dies nicht ändert.
Dieses wichtige Detail fehlte in der kurzen Antwort der Community. Eine Zuordnung wie 8080:80 kann für die Oberfläche nach der Einrichtung korrekt sein, während sie den bei einem neuen Container erwarteten initialen Einrichtungsendpunkt nicht bereitstellt.
Vergleichen Sie die Anwendung mit den aktuellen Docker-Port- und Volume-Anforderungen von AdGuard Home, bevor Sie den Router ändern.
DNS benötigt Port 53 über TCP und UDP
Der Hinweis des Community-Mitglieds auf Port 53 war korrekt: AdGuard Home benötigt diesen Port für den normalen DNS-Betrieb. Sowohl TCP als auch UDP sollten verfügbar sein, wenn der Container das LAN mit DNS versorgen soll.
Wenn ein anderer Pi-hole-, AdGuard-, Systemresolver- oder DNS-Container Port 53 bereits verwendet, kann der neue Dienst nicht normal daran gebunden werden. Den Host auf einen bestehenden Listener zu prüfen, ist sinnvoller, als die WebUI-Portnummer wiederholt zu ändern.
WebUI-Port und DNS-Port sind zwei verschiedene Probleme
Ein Konflikt auf Port 80 oder 3000 kann verhindern, dass Sie die Administrationsoberfläche öffnen, während DNS selbst weiterhin funktioniert. Ein Konflikt auf Port 53 kann den Start des DNS-Dienstes verhindern, selbst wenn das Dashboard geöffnet werden kann. Halten Sie diese beiden Fehlerzweige während der Diagnose getrennt.
Der Host-Modus wurde vorgeschlagen, aber seine Notwendigkeit wurde nicht nachgewiesen
Das Community-Mitglied empfahl, den Host-Netzwerkmodus auszuprobieren, da der Bridge-Modus DNS-Ports gelegentlich komplizierter machen könne. Der ursprüngliche Nutzer meldete nach dieser Änderung jedoch kein erfolgreiches Ergebnis auf ZimaOS zurück.
Stellen Sie den Host-Netzwerkmodus daher nicht als zwingend erforderlich dar. Die gepflegte Docker-Bereitstellung von AdGuard Home unterstützt explizite Portzuordnungen. Der Bridge-Modus kann funktionieren, wenn die benötigten Ports frei und korrekt zugeordnet sind.
Das UniFi Cloud Gateway wurde nicht als Ursache identifiziert
Der Nutzer fragte ausdrücklich, ob Änderungen am UniFi Cloud Gateway Max erforderlich seien. Die Antwort der Community lautete, dass für das lokale Öffnen und Konfigurieren von AdGuard Home allein keine Routeränderung notwendig sein sollte.
Routeränderungen kommen später ins Spiel, wenn Sie festlegen, dass LAN-Clients AdGuard Home für DNS oder DHCP verwenden sollen. Sie beheben keinen Container, der die lokale Initialisierung nicht abschließen kann.
/opt/adguardhome/work und /opt/adguardhome/conf persistent halten
AdGuard Home speichert Laufzeitdaten und Konfiguration in persistenten Verzeichnissen. Wenn diese Pfade neu erstellt, schreibgeschützt eingebunden oder auf einen unerwarteten Speicherort verwiesen werden, kann sich ein Container wie eine neue Installation verhalten oder seine Einstellungen nach einer Neuerstellung verlieren.
Die ursprünglichen Screenshots zeigten bereits persistente Volumes. Bei einer vollständigen Neuinstallation sollte daher geprüft werden, ob diese vorhandenen Ordner wiederverwendet werden, anstatt automatisch davon auszugehen, dass die Anwendung sauber neu startet.
Eine bessere Reihenfolge für die Diagnose
- Prüfen Sie das Containerprotokoll auf Start- oder Bindungsfehler.
- Bestätigen Sie, ob der erstmalige Einrichtungsport 3000 benötigt wird.
- Bestätigen Sie die Zuordnung der normalen WebUI separat.
- Prüfen Sie, ob TCP- und UDP-Port 53 auf dem Host frei sind.
- Stellen Sie sicher, dass die persistenten Konfigurations- und Arbeits-Volumes beschreibbar sind.
- Erst danach sollten Sie Bridge- und Host-Netzwerkmodus miteinander vergleichen.
- Warten Sie mit Änderungen am Router-DNS, bis der lokale Dienst fehlerfrei läuft.
Der ursprüngliche Fall blieb auf ZimaOS ungelöst
Am 24. Dezember berichtete der Nutzer, dass AdGuard Home auf einem Umbrel-Server funktionierte, die Bereitstellung auf dem ZimaBoard 2 jedoch weiterhin nicht lief. Er schloss die Anfrage, weil der Dienst an anderer Stelle verfügbar war – nicht, weil die ZimaOS-Installation repariert worden wäre.
FAQ zu „AdGuard Home Service Unavailable“
Welcher Port wird für die erstmalige Einrichtung verwendet?
Die aktuellen Docker-Anweisungen von AdGuard Home verwenden TCP-Port 3000 für den anfänglichen Konfigurationsassistenten.
Welche Ports werden für den normalen DNS-Betrieb verwendet?
Port 53 über TCP und UDP.
Benötigt AdGuard Home auf ZimaOS zwingend den Host-Netzwerkmodus?
Das wurde im ursprünglichen Thread nicht nachgewiesen. Es handelte sich um einen Vorschlag zur Fehlerbehebung aus der Community.
Wurde der ursprüngliche ZimaOS-Fall gelöst?
Nein. Der Nutzer verlagerte den Dienst auf einen anderen Server und beendete den Thread ohne funktionierende ZimaOS-Konfiguration.
