O facto importante deste tópico de dezembro de 2025 é que não terminou com uma instalação funcional do AdGuard Home no ZimaBoard 2. O utilizador original experimentou as sugestões da comunidade e informou posteriormente que o AdGuard Home funcionava num servidor Umbrel separado, enquanto a implementação no ZimaOS continuava indisponível. Isto faz deste artigo um guia de resolução de problemas, não uma receita de instalação comprovada.
As capturas de ecrã e as respostas ainda revelam várias verificações úteis: a aplicação tinha mapeamentos separados para DNS e para a interface Web, estava a utilizar rede em modo bridge e a comunidade concentrou-se em conflitos de portas, não no gateway UniFi.
O que “Service Unavailable” indica — e o que não indica
Uma página Service Unavailable prova que algum percurso HTTP respondeu, mas não identifica se o processo do AdGuard terminou a inicialização, se o percurso inverso aponta para a porta interna correta ou se a porta DNS 53 foi associada com êxito.
Não comece por alterar as definições do router quando o serviço nem sequer está saudável no anfitrião ZimaOS local.
A configuração de origem publicou as portas DNS e Web separadamente
A configuração inicial do AdGuard Home utiliza a porta 3000
As orientações atuais do AdGuard Home para Docker distinguem o assistente de configuração inicial da interface de administração normal. Num contentor novo, a porta TCP 3000 é utilizada pelo fluxo de configuração inicial. Após a configuração, a interface HTTP normal utiliza habitualmente a porta 80, salvo se o utilizador a alterar.
Este é um detalhe importante que faltava na breve resposta da comunidade. Um mapeamento de anfitrião como 8080:80 pode estar correto para a interface após a configuração e, ainda assim, não expor o endpoint de configuração inicial esperado por um contentor novo.
Compare a aplicação com os requisitos atuais de portas e volumes Docker do AdGuard Home antes de alterar o router.
O DNS requer a porta 53 através de TCP e UDP
O membro da comunidade salientou corretamente que o AdGuard Home necessita da porta 53 para o serviço DNS normal. Tanto TCP como UDP devem estar disponíveis quando se espera que o contentor forneça DNS à rede local.
Se outro Pi-hole, AdGuard, resolvedor do sistema ou contentor DNS já ocupar a porta 53, o novo serviço não poderá associá-la normalmente. Verificar se existe um processo a escutar no anfitrião é mais útil do que alterar repetidamente a porta da interface Web.
A porta da interface Web e a porta DNS são problemas diferentes
Um conflito na porta 80 ou 3000 pode impedir a abertura da interface administrativa, enquanto o DNS continua saudável. Um conflito na porta 53 pode impedir o arranque do serviço DNS, mesmo quando o painel abre. Mantenha estes ramos separados durante o diagnóstico.
Foi sugerido o modo anfitrião, mas não foi provado que fosse necessário
O membro da comunidade recomendou experimentar o modo de rede anfitrião, alegando que o modo bridge por vezes complica as portas DNS. O autor original nunca voltou a apresentar um resultado bem-sucedido no ZimaOS depois dessa alteração.
Por isso, não apresente a rede em modo anfitrião como obrigatória. A implementação Docker mantida do AdGuard Home suporta mapeamentos de portas explícitos. O modo bridge pode funcionar quando as portas necessárias estão livres e corretamente mapeadas.
O UniFi Cloud Gateway não foi identificado como a causa
O utilizador perguntou especificamente se o UniFi Cloud Gateway Max precisava de alterações. A resposta da comunidade foi que não deveria ser necessária qualquer alteração no router apenas para abrir e configurar localmente o AdGuard Home.
As alterações no router surgem mais tarde, quando decidir que os clientes da LAN devem utilizar o AdGuard Home para DNS ou DHCP. Não corrigem um contentor que não consegue concluir a inicialização local.
Mantenha /opt/adguardhome/work e /opt/adguardhome/conf persistentes
O AdGuard Home armazena dados de execução e configuração em diretórios persistentes. Se esses caminhos forem recriados, montados como só de leitura ou apontarem para um local inesperado, o contentor pode comportar-se como uma instalação nova ou perder as definições após ser recriado.
As capturas de ecrã de origem já mostravam volumes persistentes, pelo que uma reinstalação completa deve verificar se essas pastas existentes estão a ser reutilizadas, em vez de presumir que a aplicação está a iniciar de forma limpa.
Uma ordem de diagnóstico melhor
- Verifique o registo do contentor quanto a erros de arranque ou de associação de portas.
- Confirme se é necessária a porta 3000 da configuração inicial.
- Confirme separadamente o mapeamento normal da interface Web.
- Verifique se as portas TCP e UDP 53 estão livres no anfitrião.
- Confirme que os volumes persistentes de configuração e trabalho permitem escrita.
- Só depois experimente alternar entre rede bridge e rede anfitrião.
- Adie as alterações ao DNS do router até o serviço local estar saudável.
O caso de origem permaneceu sem solução no ZimaOS
Em 24 de dezembro, o utilizador informou que tinha conseguido pôr o AdGuard Home a funcionar num servidor Umbrel, mas continuava sem conseguir executar a implementação no ZimaBoard 2. Encerrou o pedido de ajuda porque o serviço estava disponível noutro local, não porque a instalação no ZimaOS tivesse sido corrigida.
Perguntas frequentes sobre o erro Service Unavailable do AdGuard Home
Que porta é utilizada para a configuração inicial?
As instruções Docker atuais do AdGuard Home utilizam a porta TCP 3000 para o assistente de configuração inicial.
Que portas são utilizadas pelo DNS normal?
A porta 53 através de TCP e UDP.
O AdGuard Home necessita de rede em modo anfitrião no ZimaOS?
O tópico de origem não o provou. Foi uma sugestão da comunidade para resolver o problema.
O caso original no ZimaOS foi resolvido?
Não. O utilizador transferiu o serviço para outro servidor e encerrou o tópico sem uma configuração funcional no ZimaOS.
