Den här tråden från december 2025 kombinerade flera olika Pi-hole-problem: port 67 var redan upptagen, Gravity-uppdateringar rapporterade att DNS-upplösning inte var tillgänglig, port 80 krockade med ZimaOS-instrumentpanelen och ett senare strömavbrott gjorde att användarens tidigare fungerande installation slutade fungera igen.
Tråden var inte en ren lösning i ett enda steg. Vissa tidiga antaganden från communityn förklarade inte användarens senare symtom, så den viktigaste lärdomen är att skilja på DHCP, DNS, mappning av webbgränssnittet, uppströmsupplösning och beständigt containertillstånd i stället för att behandla allt som ett enda portproblem.
Port 67 gäller DHCP, inte vanlig DNS-filtrering
Användaren upptäckte att en dnsmasq-process redan var bunden till port 67 och kunde inte avsluta den. Svar från communityn förklarade att Pi-hole bara behöver port 67 när det fungerar som DHCP-server. Användarens router tillhandahöll redan DHCP, så Pi-hole behövde inte ta över den rollen.
Om Pi-hole endast används för DNS-filtrering bör DHCP ligga kvar på routern, såvida du inte har en genomtänkt nätverksdesign som kräver Pi-hole som DHCP-server.
DNS använder port 53
Pi-holes DNS-tjänst använder port 53 över TCP och UDP. Community-konfigurationen i den här tråden fokuserade på att exponera DNS på port 53 samtidigt som DHCP lämnades inaktiverat.
Pi-holes egen dokumentation bör användas för aktuella krav på tjänster och portar, i stället för att anta att alla ZimaOS-containermallar från 2025 fortfarande är identiska.
aktuella krav på Pi-hole-tjänster och portar
Port 80 var en separat konflikt med ZimaOS-instrumentpanelen
När användaren försökte installera Pi-hole på nytt från grunden rapporterade ZimaOS att port 80 redan användes. Zima-Jerry bekräftade att porten för ZimaOS webbgränssnitt kan ändras.
Ett enklare alternativ på containersidan som diskuterades i tråden var att låta ZimaOS-instrumentpanelen ligga kvar på sin befintliga port och mappa en annan värdport till Pi-holes interna webbport. Detta ändrar endast hur Pi-holes administrationssida nås; det ändrar inte DNS-trafiken på port 53.
En korrekt portmappning löste inte automatiskt Gravity
Efter att portmappningarna hade rensats upp såg den ursprungliga användaren fortfarande meddelandet ”DNS resolution is unavailable”. Därefter skiftade tråden från portkonflikter till åtkomst till uppströms-DNS. Den viktiga diagnostiska skillnaden är:
- portmappning styr om klienter kan nå Pi-hole-tjänsten;
- uppströms-DNS styr om Pi-hole själv kan slå upp namn och uppdatera Gravity-data.
Tråden publicerade ingen IceWhale-bekräftad grundorsak till alla DNS-fel, så undvik att hävda att enbart port 67 förklarar en misslyckad Gravity-uppdatering.
Installationen gick sönder igen efter ett strömavbrott
Användaren rapporterade senare att Pi-hole hade fungerat korrekt före ett strömavbrott, men sedan slutade fungera igen. Råd från communityn antydde att beständiga AppData kan överleva en vanlig avinstallation och föra med sig ett trasigt tillstånd till en ominstallation.
Att ta bort en AppData-katalog är destruktivt eftersom det raderar beständigt programtillstånd. Rekommendationen i källan var felsökning från communityn, inte en officiell återställningsprocedur från IceWhale. Säkerhetskopiera konfigurationen och kontrollera den exakta programsökvägen innan du tar bort beständiga data.
Kontrollera ZimaOS hälsa innan du bygger om Pi-hole
Samma strömavbrott påverkade även datorns uppstartsprocess. När själva operativsystemet blev instabilt skiljde tråden korrekt detta från problemet med Pi-hole-containern. En container kan inte förväntas fungera normalt när värdsystemet inte startar korrekt eller Docker-tjänsterna inte är friska.
Vanliga frågor om Pi-hole på ZimaOS
Behöver Pi-hole port 67 om min router redan tillhandahåller DHCP?
Nej, inte för den DNS-filterbaserade installation som diskuteras i den här tråden. Port 67 är relevant för DHCP-tjänsten, medan DNS-filtrering använder port 53.
Vad gör jag om ZimaOS redan använder port 80?
Zima-Jerry bekräftade att porten för ZimaOS webbgränssnitt kan ändras. Ett annat alternativ är att mappa Pi-holes interna webbport till en annan värdport.
Kan blockeringslistor orsaka meddelandet ”DNS resolution is unavailable”?
Felsökningen i tråden fokuserade på Pi-holes möjlighet att nå en uppströmsresolver, inte på innehållet i blockeringslistorna.
Garanterar en avinstallation av Pi-hole en ren ominstallation?
Nej, inte om beständiga AppData finns kvar. Tråden undersökte senare gammalt eller skadat beständigt tillstånd efter ett hårt strömavbrott, men att ta bort detta tillstånd bör betraktas som ett destruktivt återställningssteg.
