Uma aplicação Docker pode estar a escutar corretamente no ZimaOS e, ainda assim, não estar acessível a partir de um serviço na Internet pública. Essa foi a principal lição deste tópico de maio de 2026. Inicialmente, o utilizador pensou que a porta 9696 estava «fechada», mas a inspeção do contentor mostrou que o Prowlarr já estava publicado no anfitrião.
Depois de isso estar confirmado, o problema deixou de ser uma questão de configuração do Docker e passou a ser uma questão de acesso remoto e de limites da rede.
Estar publicada no anfitrião não significa estar acessível publicamente
A investigação da comunidade confirmou que o Prowlarr tinha um mapeamento da porta 9696 no anfitrião. Em termos do Docker, isso significa que o serviço estava exposto do contentor para a rede do anfitrião ZimaOS.
Isso é suficiente para que os dispositivos na mesma LAN se liguem ao IP e à porta publicada do ZimaOS, desde que a própria aplicação esteja a escutar corretamente. No entanto, não cria automaticamente uma rota da Internet pública através do router.
Um endereço LAN privado não pode ser utilizado por um serviço na nuvem
O utilizador esclareceu que o TorBox não estava a ser executado no servidor ZimaOS. Precisava de se ligar a partir do exterior da rede doméstica. Um endereço privado, como 192.168.x.x, não é encaminhável através da Internet, pelo que um serviço na nuvem não consegue aceder diretamente a esse endereço.
É por isso que o contentor conseguia estabelecer ligações de saída para indexadores públicos, enquanto o serviço na nuvem não conseguia criar uma nova ligação de entrada para a LAN do utilizador.
O acesso remoto requer uma camada de rede adicional
O tópico discutiu várias possibilidades, incluindo o reencaminhamento de portas no router, um IP ou domínio público, Tailscale, Cloudflare Tunnel e soluções de proxy inverso.
A exposição direta de serviços administrativos na Internet pública deve ser abordada com cuidado. A autenticação, o TLS, o controlo de acesso e a segurança da aplicação são importantes assim que um serviço fica acessível através da Internet.
A documentação atual de rede do ZimaOS também disponibiliza uma opção integrada de Acesso remoto, que estabelece um relay seguro para o painel do ZimaOS sem ser necessário configurar manualmente o reencaminhamento de portas no router.
Definições atuais de Acesso remoto e rede do ZimaOS
O CGNAT pode impedir o reencaminhamento tradicional de portas de entrada
A resposta da comunidade também levantou o Carrier-Grade NAT como possível obstáculo. Se o ISP não fornecer um endereço IPv4 público diretamente acessível, o reencaminhamento normal de portas no router poderá não criar um caminho de entrada utilizável.
O utilizador original comparou o IP público com o endereço WAN do router e considerou que o CGNAT não era a causa no seu caso. O tópico avançou então para opções baseadas em redes sobrepostas ou túneis.
Não assuma que o ZimaOS está a bloquear a porta quando o Docker mostra que ela está publicada
A discussão original não encontrou indícios de que o próprio ZimaOS estivesse a bloquear o acesso local pela LAN à porta 9696. Quando o Docker mostrava claramente que a porta estava publicada, a falha de ligação à nuvem tinha de ser investigada fora do mapeamento de portas do contentor.
Este é um padrão de diagnóstico útil para outras aplicações auto-hospedadas: confirme primeiro que a aplicação funciona localmente antes de investigar o DNS público, o NAT, os túneis ou as integrações externas.
Perguntas frequentes sobre portas remotas do ZimaOS
Se o Docker publicar a porta 9696, ela fica aberta a toda a Internet?
Não. Fica publicada no anfitrião. A possibilidade de a Internet lhe aceder depende do encaminhamento, do NAT, do comportamento do ISP, da política de firewall e de qualquer camada de túnel ou proxy inverso.
Porque é que o Prowlarr consegue aceder a indexadores públicos, mas o TorBox não consegue aceder ao Prowlarr?
As ligações de saída e de entrada são diferentes. Normalmente, o tráfego de saída sai de uma rede doméstica com NAT sem configuração especial, enquanto o novo tráfego de entrada precisa de uma rota de regresso para a LAN.
Devo expor diretamente o Prowlarr através do reencaminhamento de portas do router?
O tópico alertou contra a exposição direta e sugeriu abordagens de acesso remoto mais seguras, como Tailscale, Cloudflare Tunnel ou um proxy inverso autenticado.
A porta 9696 estava realmente mal configurada no caso original?
Não. O utilizador confirmou o mapeamento esperado entre o anfitrião e o contentor, pelo que a investigação avançou para além da publicação da porta no Docker.
