Se o Sonarr, o Radarr, o Lidarr, o Transmission ou outros contentores no ZimaOS conseguirem contactar-se através de endereços IP, mas não puderem utilizar nomes estáveis como transmission:9091, o problema costuma estar na resolução de nomes e não na conectividade básica entre contentores. Essa distinção tornou-se a principal conclusão deste tópico da IceWhale Community, de novembro de 2025.
A predefinida do Docker bridge a rede não fornece DNS automático para nomes de contentores da mesma forma que uma bridge definida pelo utilizador. A discussão revelou então uma segunda complicação específica do ZimaOS: as redes bridge criadas manualmente podiam existir no Docker antes de aparecerem corretamente na WebUI do ZimaOS, e a interface podia rejeitar redes Docker válidas devido às expectativas relativas às etiquetas do Compose.
O principal sintoma: o IP funciona, mas o nome do contentor falha
O utilizador original queria que o Radarr contactasse o Transmission através de:
http://transmission:9091Os endereços IP dos contentores mudavam após reinícios ou atualizações, pelo que defini-los manualmente não era fiável. Os contentores conseguiam comunicar entre si através de IP, mas as chamadas baseadas no nome de anfitrião falhavam.
Porque é que a bridge predefinida do Docker não resolve este problema
A atual documentação do Docker sobre redes bridge indica que os contentores na bridge predefinida podem comunicar através de IP, enquanto as bridges definidas pelo utilizador fornecem resolução DNS automática entre contentores.
Assim, «todas as aplicações utilizam a bridge» não significa necessariamente que estejam a utilizar uma bridge definida pelo utilizador com o DNS incorporado do Docker.
Criar uma bridge definida pelo utilizador
sudo -i
docker network create media-netOs contentores ligados à mesma bridge definida pelo utilizador podem normalmente resolver-se entre si através do nome do contentor ou do alias da rede.
A documentação atual do ZimaOS utiliza o mesmo padrão
A documentação atual do ZimaSpace utiliza explicitamente uma rede personalizada no guia do Zabbix, porque a bridge predefinida não fornece o comportamento de DNS desejado entre contentores:
sudo docker network create zabbix-netConsulte o guia de instalação atual do ZimaOS para o Zabbix.
O problema específico do ZimaOS: sincronização da WebUI
No tópico original, criar uma bridge personalizada através do Docker ou do Portainer não tornava imediatamente a rede utilizável nas definições da aplicação ZimaOS. Os utilizadores viam erros como:
network internal-network was found but has incorrect label
com.docker.compose.network set to ""Depois de testar com um engenheiro, Zima-Giorgio afirmou que a rede do Docker funcionava normalmente, mas a WebUI podia estar dessincronizada do backend do Docker.
O passo confirmado pela comunidade: reiniciar após criar a rede
sudo -i
docker network create net-a
docker network create net-b
reinícioApós o reinício, as redes recém-criadas apareceram no painel de definições da aplicação. Outro participante confirmou que a ausência do reinício era o passo fundamental no seu teste e que a resolução de nomes funcionava posteriormente na bridge personalizada.
O Docker padrão normalmente não exige o reinício de todo o anfitrião depois de docker network createeste era um comportamento específico do ZimaOS observado no tópico de 2025.
Ainda permanecia um problema de compatibilidade da etiqueta do Compose
Mesmo depois de o reinício ter esclarecido o problema de sincronização, o tópico documentou outra limitação. O ZimaOS podia indicar que uma rede criada manualmente tinha uma com.docker.compose.network etiqueta.
Zima-Giorgio acabou por dizer que a impossibilidade de escolher algumas redes criadas parecia ser um problema e que seria encaminhada para a equipa. O tópico não contém uma confirmação posterior de que todos os casos extremos de seleção de redes tenham sido corrigidos.
Verificar a rede a partir do Docker, não apenas na interface
docker network inspect media-net
docker inspect CONTAINER_A
docker inspect CONTAINER_BEm seguida, teste a resolução de nomes a partir de um contentor:
docker exec CONTAINER_A ping -c 2 CONTAINER_BSe a imagem não incluir ping, utilize outra ferramenta de diagnóstico disponível ou um contentor de teste temporário na mesma rede.
Utilize nomes ou aliases em vez de alterar endereços IP
Quando o DNS do Docker funcionar numa bridge definida pelo utilizador, configure as aplicações com um endpoint estável, como:
http://transmission:9091ou um alias de rede definido no Compose.
O Cloudflared foi a causa?
O tópico de origem não identificou o Cloudflared como a causa principal. A comunicação por IP já funcionava e a falha correspondia ao comportamento do DNS/resolução de nomes do Docker.
Solução temporária: IP do anfitrião e portas publicadas
O autor original reservou temporariamente um IP estático na LAN para o anfitrião ZimaOS e configurou as aplicações para utilizarem esse IP e as portas publicadas. Isto pode funcionar, mas encaminha o tráfego através do caminho das portas publicadas no anfitrião, em vez do encaminhamento interno estável do Docker baseado no nome do serviço.
Lista de verificação da resolução de nomes de contentores no ZimaOS
- Confirme se a comunicação de IP para IP funciona.
- Verifique se os contentores estão na bridge predefinida ou numa bridge definida pelo utilizador com nome.
- Crie uma bridge personalizada quando for necessário um DNS estável.
- Ligue todos os serviços necessários à mesma rede personalizada.
- Nas versões do ZimaOS correspondentes ao tópico de origem, reinicie para que a WebUI atualize o estado da rede Docker.
- Verifique com
docker inspectedocker network inspect. - Teste a resolução do nome do contentor a partir de dentro de outro contentor.
- Se o ZimaOS indicar uma incompatibilidade de etiquetas do Compose, trate-a como um problema da interface/integração, e não como prova de que a rede do Docker é inválida.
FAQ sobre a Bridge de Contentores do ZimaOS
Porque é que os contentores na bridge não conseguem resolver-se pelo nome?
A bridge predefinida do Docker permite comunicação por IP, mas não fornece DNS automático baseado no nome do contentor, como acontece numa bridge definida pelo utilizador.
É necessário reiniciar depois de executar docker network create?
Normalmente, o Docker padrão não o faz. Neste tópico do ZimaOS de 2025, foi necessário reiniciar para que a WebUI do ZimaOS obtivesse o novo estado da rede.
O Cloudflared interrompe o DNS da bridge do Docker?
O tópico de origem não estabeleceu isso.
Devo atribuir IPs estáticos ao Docker?
Normalmente, não. Os DNS e aliases do Docker definidos pelo utilizador são mais portáteis do que IPs de contentores codificados.
