Depois de mudar de ISP e reinstalar o ZimaOS, um membro da comunidade descobriu que o anfitrião conseguia fazer ping a sites na Internet e descarregar imagens da App Store, enquanto as aplicações dentro dos contentores não conseguiam aceder a serviços externos. O qBittorrent não conseguia fazer transferências e o Jellyfin não conseguia obter metadados.
O caso original foi resolvido ao mover os contentores afetados da rede bridge para o modo host. Respostas posteriores documentaram um segundo caso com sintomas semelhantes, mas com uma causa diferente: tinha sido introduzido um endereço WAN público como gateway e o percurso do ISP do utilizador também exigia IPv6 juntamente com IPv4 para o Jellyfin.
A conectividade do anfitrião não provava a conectividade dos contentores
O autor conseguia utilizar o terminal Web do ZimaOS e instalar aplicações, demonstrando que o próprio sistema operativo tinha um caminho de saída funcional. Isso não comprovava que cada rede Docker tivesse um encaminhamento correto. Por isso, as falhas das aplicações tinham de ser testadas a partir do contentor, em vez de serem inferidas a partir do anfitrião.
Giorgio, membro da equipa Zima, sugeriu testar a conectividade através de um contentor de navegador e experimentar outro modo de rede no painel de definições da aplicação. A publicação também refere que lojas de terceiros, a instalação através de YAML e a instalação pela CLI podem disponibilizar aplicações de diagnóstico, mas essas são opções e não um requisito confirmado.
O modo host resolveu o caso original da rede bridge
O autor mudou todos os contentores afetados para o modo host e comunicou que o acesso à Internet começou a funcionar. A discussão não determina por que motivo o modo bridge falhou após a instalação limpa; por isso, o modo host deve ser registado como a alteração bem-sucedida para esta configuração, e não como prova de um defeito universal da rede bridge.
Um participante posterior observou um efeito secundário importante: depois de mudar de modo, a ligação no painel pode continuar a apontar para a antiga porta publicada no anfitrião. No caso do Jellyfin, o participante teve de aceder diretamente à porta 8096, depois de o painel continuar a abrir a porta 8097.
Um caso posterior revelou um gateway incorreto
Os registos do Jellyfin do segundo utilizador continham No route to host ao contactar um serviço externo de metadados. Os membros da comunidade recomendaram testar sem a VPN e verificar o gateway apresentado nas definições de rede do ZimaOS.
Uma captura de ecrã revelou que o gateway configurado era o endereço WAN público do utilizador. As respostas explicaram que o gateway deveria ser o endereço do router local na mesma sub-rede LAN. O utilizador corrigiu o gateway e também ativou o IPv6 juntamente com o IPv4 no Jellyfin, porque a sua ligação AT&T dava preferência ao IPv6. Em seguida, confirmou que a obtenção de metadados e imagens funcionava.
Mantenha separados os dois resultados da comunidade
- Caso original de outubro de 2025: a rede bridge falhava nos contentores do autor; o modo host restabeleceu o acesso.
- Caso de acompanhamento de janeiro de 2026: o gateway estava configurado como um IP público e o Jellyfin também precisava que o IPv6 fosse ativado para esse percurso do ISP.
Ambos produziram o sintoma geral de que “as aplicações não conseguem aceder à Internet”, mas não partilhavam uma causa-raiz verificada. A discussão sustenta a verificação do modo de rede, do endereço utilizado após uma alteração de modo, da configuração do gateway, da influência da VPN e da disponibilidade do protocolo como ramos distintos.
FAQ
Por que motivo o ZimaOS consegue descarregar aplicações enquanto um contentor permanece offline?
O anfitrião e um contentor Docker podem utilizar configurações de encaminhamento e de rede diferentes. No caso original, a conectividade do anfitrião manteve-se funcional enquanto as aplicações ligadas à rede bridge falhavam.
Alterar o Jellyfin para o modo host mantém a antiga porta do painel?
Não necessariamente. Um participante descobriu que o painel continuava a ligar-se à porta 8097, enquanto o Jellyfin no modo host estava diretamente acessível na porta 8096.
