Questa discussione del dicembre 2025 riuniva diversi problemi distinti di Pi-hole: la porta 67 era già in uso, gli aggiornamenti di Gravity segnalavano che la risoluzione DNS non era disponibile, la porta 80 era in conflitto con il pannello di ZimaOS e, in seguito, un'interruzione di corrente ha fatto nuovamente fallire una configurazione che prima funzionava.
La discussione non offriva una soluzione semplice in un solo passaggio. Alcune ipotesi iniziali della community non spiegavano i sintomi comparsi in seguito, quindi l'insegnamento utile è separare DHCP, DNS, mappatura dell'interfaccia web, risoluzione upstream e stato persistente del container, invece di considerarli un unico problema di porte.
La porta 67 riguarda il DHCP, non il normale filtraggio DNS
L'utente ha scoperto che un processo dnsmasq era già associato alla porta 67 e non riusciva a terminarlo. Le risposte della community hanno spiegato che Pi-hole necessita della porta 67 solo quando agisce come server DHCP. Il router dell'utente forniva già il DHCP, quindi Pi-hole non doveva assumere quel ruolo.
Se Pi-hole viene utilizzato solo per il filtraggio DNS, lascia il DHCP sul router, a meno che tu non disponga di una progettazione di rete deliberata che richieda il DHCP di Pi-hole.
Il DNS utilizza la porta 53
Il servizio DNS di Pi-hole utilizza la porta 53 su TCP e UDP. La configurazione della community in questa discussione si concentrava sull'esposizione del DNS sulla porta 53, lasciando disabilitato il DHCP.
Per i requisiti aggiornati relativi a servizi e porte, consulta la documentazione ufficiale di Pi-hole, invece di presumere che ogni modello di container ZimaOS del 2025 sia ancora identico.
requisiti aggiornati di Pi-hole per servizi e porte
La porta 80 era un conflitto separato con il pannello di ZimaOS
Quando l'utente ha tentato un'installazione pulita di Pi-hole, ZimaOS ha segnalato che la porta 80 era già in uso. Zima-Jerry ha confermato che è possibile modificare la porta della WebUI di ZimaOS.
Un'alternativa più semplice discussa nella discussione consisteva nel lasciare il pannello di ZimaOS sulla porta esistente e mappare una porta host diversa sulla porta web interna di Pi-hole. Questo modifica solo il modo in cui si accede alla pagina di amministrazione di Pi-hole; non modifica il traffico DNS sulla porta 53.
Una mappatura corretta delle porte non ha risolto automaticamente Gravity
Dopo aver sistemato le mappature delle porte, l'utente originale continuava a visualizzare “La risoluzione DNS non è disponibile”. A quel punto la discussione è passata dai conflitti tra porte alla raggiungibilità del DNS upstream. La distinzione diagnostica importante è:
- la mappatura delle porte determina se i client possono raggiungere il servizio Pi-hole;
- il DNS upstream determina se Pi-hole può risolvere autonomamente i nomi e aggiornare i dati di Gravity.
La discussione non ha indicato una causa principale confermata da IceWhale per ogni errore DNS, quindi evita di sostenere che la sola porta 67 spieghi un aggiornamento di Gravity non riuscito.
La configurazione si è guastata nuovamente dopo un'interruzione di corrente
In seguito, l'utente ha riferito che Pi-hole funzionava correttamente prima di un'interruzione di corrente, ma ha ricominciato a non funzionare dopo il ripristino. I consigli della community suggerivano che i dati persistenti di AppData possano sopravvivere a una normale disinstallazione e trasferire uno stato danneggiato a una nuova installazione.
L'eliminazione di una directory AppData è distruttiva perché rimuove lo stato persistente dell'applicazione. La raccomandazione originale era un suggerimento di troubleshooting della community, non una procedura ufficiale di ripristino di IceWhale. Esegui un backup della configurazione e verifica il percorso esatto dell'applicazione prima di rimuovere i dati persistenti.
Controlla lo stato di ZimaOS prima di ricreare Pi-hole
La stessa interruzione di corrente ha influito anche sul comportamento di avvio del computer. Quando il sistema operativo stesso è diventato instabile, la discussione ha correttamente distinto questo problema da quello del container Pi-hole. Non ci si può aspettare che un container funzioni normalmente mentre l'host non riesce ad avviarsi o i servizi Docker non sono integri.
Domande frequenti su Pi-hole in ZimaOS
Pi-hole ha bisogno della porta 67 se il router fornisce già il DHCP?
No, non per la configurazione di solo filtraggio DNS discussa in questa discussione. La porta 67 è relativa al servizio DHCP, mentre il filtraggio DNS utilizza la porta 53.
Cosa succede se ZimaOS utilizza già la porta 80?
Zima-Jerry ha confermato che è possibile modificare la porta della WebUI di ZimaOS. Un'altra soluzione consiste nel mappare la porta web interna di Pi-hole su una porta host diversa.
Le blocklist possono causare il messaggio “La risoluzione DNS non è disponibile”?
Il troubleshooting della discussione si è concentrato sulla capacità di Pi-hole di raggiungere un resolver upstream, non sul contenuto delle blocklist.
La disinstallazione di Pi-hole garantisce una reinstallazione pulita?
Non se i dati persistenti di AppData rimangono. In seguito, la discussione ha analizzato uno stato persistente obsoleto o danneggiato dopo una perdita improvvisa di alimentazione, ma l'eliminazione di tale stato deve essere considerata una procedura di ripristino distruttiva.
