Solução da comunidade

Pi-hole no ZimaOS: Porta 67, erros de DNS, conflitos de portas Web e limites da reinstalação limpa

A Pi-hole troubleshooting thread covering a system-owned port 67, DNS resolution failures during Gravity updates, a port 80 conflict with the ZimaOS dashboard, and persistent Pi-hole state after an unexpected power outage.

Este tópico de dezembro de 2025 combinou vários problemas diferentes do Pi-hole: a porta 67 já estava a ser utilizada, as atualizações do Gravity indicavam que a resolução DNS não estava disponível, a porta 80 entrava em conflito com o painel do ZimaOS e, mais tarde, uma falha de energia fez com que a configuração, que anteriormente funcionava, voltasse a falhar.

O tópico não apresentava uma solução simples de uma só etapa. Algumas suposições iniciais da comunidade não explicavam os sintomas posteriores do utilizador, pelo que a lição útil é separar DHCP, DNS, mapeamento da interface web, resolução a montante e estado persistente do contentor, em vez de tratar tudo como um único problema de portas.

A porta 67 está relacionada com DHCP, não com a filtragem DNS normal

O utilizador de origem descobriu um processo dnsmasq já associado à porta 67 e não conseguia terminá-lo. As respostas da comunidade explicaram que o Pi-hole só precisa da porta 67 quando atua como servidor DHCP. O router do utilizador já fornecia DHCP, pelo que o Pi-hole não precisava de assumir essa função.

Se o Pi-hole for utilizado apenas para filtragem DNS, mantenha o DHCP no router, salvo se tiver uma configuração de rede deliberada que exija o DHCP do Pi-hole.

O DNS utiliza a porta 53

O serviço DNS do Pi-hole utiliza a porta 53 através de TCP e UDP. A configuração da comunidade neste tópico centrou-se em expor o DNS na porta 53, mantendo o DHCP desativado.

Deve ser utilizada a documentação do próprio Pi-hole para consultar os requisitos atuais de serviços e portas, em vez de assumir que todos os modelos de contentores do ZimaOS de 2025 continuam idênticos.

requisitos atuais de serviços e portas do Pi-hole

A porta 80 era um conflito separado com o painel do ZimaOS

Quando o utilizador tentou fazer uma instalação limpa do Pi-hole, o ZimaOS comunicou que a porta 80 já estava a ser utilizada. Zima-Jerry confirmou que a porta da WebUI do ZimaOS pode ser alterada.

Definições da aplicação personalizada do Pi-hole no ZimaOS, mostrando a porta 53 aceite enquanto a porta 80 do anfitrião é assinalada como indisponível
A captura de ecrã de origem mostra a porta DNS 53 aceite, enquanto a porta 80 do anfitrião entra em conflito com outro serviço no anfitrião ZimaOS.

Uma alternativa mais simples ao nível do contentor, discutida no tópico, consistia em deixar o painel do ZimaOS na porta existente e mapear uma porta diferente do anfitrião para a porta web interna do Pi-hole. Isto altera apenas a forma como se acede à página de administração do Pi-hole; não altera o tráfego DNS na porta 53.

Mapeamentos de portas do Pi-hole no ZimaOS, com as portas TCP e UDP 53 e a porta 8081 do anfitrião mapeada para a porta 80 do contentor
Uma captura de ecrã posterior mostra a configuração da comunidade, utilizando TCP/UDP 53 para DNS e a porta 8081 do anfitrião para a porta web 80 do contentor do Pi-hole.

Um mapeamento de portas correto não corrigiu automaticamente o Gravity

Depois de corrigir os mapeamentos de portas, o utilizador original continuava a ver a mensagem “A resolução DNS não está disponível”. O tópico passou então dos conflitos de portas para a acessibilidade do DNS a montante. A distinção de diagnóstico importante é:

  • o mapeamento de portas determina se os clientes conseguem aceder ao serviço Pi-hole;
  • o DNS a montante determina se o próprio Pi-hole consegue resolver nomes e atualizar os dados do Gravity.

O tópico não apresentou uma causa-raiz confirmada pela IceWhale para todas as falhas de DNS, pelo que se deve evitar afirmar que a porta 67, por si só, explica uma atualização do Gravity que falhou.

A configuração voltou a falhar após uma falha de energia

Mais tarde, o utilizador comunicou que o Pi-hole estava a funcionar corretamente antes de uma falha de energia, mas voltou a falhar depois. Os conselhos da comunidade sugeriam que os dados persistentes da aplicação podem sobreviver a uma desinstalação normal e transportar um estado danificado para uma reinstalação.

A eliminação de um diretório AppData é destrutiva, pois remove o estado persistente da aplicação. A recomendação de origem era uma sugestão de diagnóstico da comunidade, não um procedimento oficial de recuperação da IceWhale. Faça uma cópia de segurança da configuração e confirme o caminho exato da aplicação antes de remover dados persistentes.

Verifique o estado do ZimaOS antes de reconstruir o Pi-hole

A mesma falha de energia também afetou o comportamento de arranque da máquina. Quando o próprio sistema operativo se tornou instável, o tópico distinguiu corretamente esse problema do problema do contentor Pi-hole. Não se pode esperar que um contentor funcione normalmente quando o anfitrião não consegue arrancar ou quando os serviços Docker não estão saudáveis.

Perguntas frequentes sobre o Pi-hole no ZimaOS

O Pi-hole precisa da porta 67 se o meu router já fornece DHCP?

Não, para a configuração apenas de filtragem DNS discutida neste tópico. A porta 67 é relevante para o serviço DHCP, enquanto a filtragem DNS utiliza a porta 53.

E se o ZimaOS já utilizar a porta 80?

Zima-Jerry confirmou que a porta da WebUI do ZimaOS pode ser alterada. Outra abordagem consiste em mapear a porta web interna do Pi-hole para uma porta diferente do anfitrião.

As listas de bloqueio podem causar a mensagem “A resolução DNS não está disponível”?

O diagnóstico do tópico centrou-se na capacidade do Pi-hole de alcançar um resolvedor a montante, não no conteúdo das listas de bloqueio.

A desinstalação do Pi-hole garante uma reinstalação limpa?

Não, se os dados persistentes da aplicação permanecerem. Mais tarde, o tópico explorou a possibilidade de um estado persistente obsoleto ou danificado após uma falha abrupta de energia, mas a eliminação desse estado deve ser tratada como uma etapa de recuperação destrutiva.