Soluzione della community

Risolvi l’errore «Servizio non disponibile» di AdGuard Home su ZimaOS

A December 2025 ZimaBoard 2 case where BigBear AdGuard Home stayed unavailable. Community troubleshooting focused on web-port and DNS-port conflicts, but the original user never got the app working on ZimaOS and moved the service to another server.

Il fatto importante di questa discussione del dicembre 2025 è che non si è conclusa con un'installazione funzionante di AdGuard Home su ZimaBoard 2. L'utente della discussione ha provato i suggerimenti della community, poi ha riferito che AdGuard Home funzionava su un server Umbrel separato, mentre la distribuzione su ZimaOS rimaneva non disponibile. Questo la rende un articolo di risoluzione dei problemi, non una procedura di installazione già risolta.

Le schermate e le risposte rivelano comunque diversi controlli utili: l'applicazione aveva mappature separate per DNS e interfaccia web, funzionava in modalità di rete bridge e la community si è concentrata sui conflitti di porta, non sul gateway UniFi.

Cosa indica e cosa non indica “Service Unavailable”

Una pagina Service Unavailable dimostra che un percorso HTTP ha risposto, ma non indica se il processo AdGuard ha completato l'inizializzazione, se il percorso inverso punta alla porta interna corretta o se la porta DNS 53 è stata associata correttamente.

Non iniziare modificando le impostazioni del router quando il servizio non è nemmeno funzionante sull'host ZimaOS locale.

La configurazione originale pubblicava separatamente le porte DNS e web

Impostazioni dell'applicazione AdGuard Home in ZimaOS con rete bridge e mappature delle porte 53 TCP e UDP
L'applicazione esponeva sia la porta TCP sia la porta UDP 53 per il DNS, utilizzando la rete bridge.
Impostazioni di AdGuard Home in ZimaOS con la porta host 8080 mappata sulla porta 80 del container e volumi persistenti work e conf
L'interfaccia web era mappata indipendentemente dal DNS e includeva anche directory persistenti per i dati di lavoro e la configurazione.

La configurazione iniziale di AdGuard Home utilizza la porta 3000

Le attuali indicazioni Docker di AdGuard Home distinguono la procedura guidata di configurazione iniziale dalla normale interfaccia amministrativa. In un container appena creato, la porta TCP 3000 viene utilizzata per la configurazione iniziale. Dopo la configurazione, la normale interfaccia HTTP usa comunemente la porta 80, a meno che l'utente non la modifichi.

Si tratta di un dettaglio importante omesso dalla breve risposta della community. Una mappatura dell'host come 8080:80 può essere corretta per l'interfaccia successiva alla configurazione, ma non esporre comunque l'endpoint di configurazione iniziale previsto da un container appena creato.

Confronta l'applicazione con i requisiti attuali di AdGuard Home per porte Docker e volumi prima di modificare il router.

Il DNS richiede la porta 53 sia su TCP sia su UDP

Il membro della community ha correttamente sottolineato che AdGuard Home necessita della porta 53 per il normale servizio DNS. Quando il container deve fornire il DNS alla LAN, devono essere disponibili sia TCP sia UDP.

Se un altro Pi-hole, AdGuard, resolver di sistema o container DNS possiede già la porta 53, il nuovo servizio non può associarla normalmente. Verificare la presenza di un listener esistente sull'host è più utile che continuare a modificare la porta della WebUI.

La porta della WebUI e la porta DNS sono problemi distinti

Un conflitto sulla porta 80 o 3000 può impedirti di aprire l'interfaccia amministrativa mentre il DNS continua a funzionare correttamente. Un conflitto sulla porta 53 può impedire l'avvio del servizio DNS anche quando la dashboard si apre. Mantieni distinti questi due percorsi durante la diagnosi.

È stata suggerita la modalità host, ma non è stato dimostrato che fosse necessaria

Il membro della community ha consigliato di provare la modalità di rete host, sostenendo che la modalità bridge a volte complica la gestione delle porte DNS. L'autore originale non è però mai tornato con un risultato ZimaOS funzionante dopo questa modifica.

Pertanto, non presentare la rete host come obbligatoria. La distribuzione Docker mantenuta di AdGuard Home supporta mappature esplicite delle porte. La modalità bridge può funzionare quando le porte necessarie sono libere e mappate correttamente.

Il Cloud Gateway UniFi non è stato identificato come causa

L'utente ha chiesto esplicitamente se fosse necessario modificare il Cloud Gateway Max di UniFi. La risposta della community è stata che non dovrebbe essere necessaria alcuna modifica al router solo per aprire e configurare localmente AdGuard Home.

Le modifiche al router vengono in seguito, quando decidi di fare utilizzare AdGuard Home ai client della LAN per il DNS o il DHCP. Non risolvono un container che non riesce a completare l'inizializzazione locale.

Mantieni persistenti /opt/adguardhome/work e /opt/adguardhome/conf

AdGuard Home archivia i dati di runtime e la configurazione in directory persistenti. Se questi percorsi vengono ricreati, montati in sola lettura o puntano a una posizione imprevista, il container può comportarsi come una nuova installazione o perdere le impostazioni dopo una ricreazione.

Le schermate originali mostravano già volumi persistenti, quindi una reinstallazione completa dovrebbe verificare se le cartelle esistenti vengono riutilizzate, invece di presumere che l'applicazione parta da zero.

Un ordine diagnostico migliore

  1. Controlla il log del container per individuare errori di avvio o di associazione delle porte.
  2. Verifica se è necessaria la porta 3000 per la configurazione iniziale.
  3. Verifica separatamente la mappatura normale della WebUI.
  4. Controlla che le porte TCP e UDP 53 siano libere sull'host.
  5. Verifica che i volumi persistenti di configurazione e dati di lavoro siano scrivibili.
  6. Solo a quel punto prova a cambiare tra rete bridge e rete host.
  7. Rimanda le modifiche al DNS del router finché il servizio locale non è funzionante.

Il caso originale è rimasto irrisolto su ZimaOS

Il 24 dicembre, l'utente ha riferito di essere riuscito a far funzionare AdGuard Home su un server Umbrel, ma di non essere ancora riuscito ad avviare la distribuzione su ZimaBoard 2. Ha chiuso la richiesta di assistenza perché il servizio era disponibile altrove, non perché l'installazione su ZimaOS fosse stata risolta.

Domande frequenti su “Service Unavailable” di AdGuard Home

Quale porta viene utilizzata per la configurazione iniziale?

Le attuali istruzioni Docker di AdGuard Home utilizzano la porta TCP 3000 per la procedura guidata di configurazione iniziale.

Quali porte vengono utilizzate per il DNS normale?

La porta 53 sia su TCP sia su UDP.

AdGuard Home richiede la rete host su ZimaOS?

La discussione originale non lo ha dimostrato. Era un suggerimento della community per la risoluzione dei problemi.

Il caso originale su ZimaOS è stato risolto?

No. L'utente ha spostato il servizio su un altro server e ha chiuso la discussione senza una configurazione ZimaOS funzionante.