Ativar o HTTPS para o painel do ZimaOS não atribui automaticamente um endereço HTTPS ao Jellyfin, ao Vaultwarden, ao Nginx Proxy Manager ou a qualquer outra aplicação Docker. Esse equívoco deu origem precisamente a este tópico de fevereiro de 2026. O utilizador tinha ativado o HTTPS nas Definições do ZimaOS, guardado o certificado gerado para a interface do ZimaOS e tentado importá-lo para o Nginx Proxy Manager, mas o Jellyfin e o NPM continuavam a não funcionar como esperado.
O tópico acabou por chegar a uma configuração comunitária funcional: utilizar o Nginx Proxy Manager como ponto de terminação TLS para aplicações individuais, afastar o gateway do ZimaOS das portas 80 e 443 se essas portas forem necessárias para o proxy inverso, configurar um nome de anfitrião através do DuckDNS e emitir um certificado para esse nome. Mais tarde, o utilizador publicou uma captura de ecrã que mostrava os anfitriões proxy online e resumiu o resultado como funcional.
Compreender as três camadas HTTPS distintas
Há três coisas diferentes que é fácil confundir:
- HTTPS do painel do ZimaOS protege a própria interface de gestão do ZimaOS.
- HTTP da aplicação é a porta interna normal utilizada por uma aplicação como o Jellyfin.
- HTTPS do proxy inverso é um nome de anfitrião público ou local que termina o TLS e encaminha o tráfego para a porta HTTP interna da aplicação.
Por isso, o certificado gerado para a interface de gestão do ZimaOS não é um certificado universal para todas as aplicações. Um proxy inverso precisa de um certificado cujo nome de anfitrião corresponda ao endereço que os utilizadores abrem efetivamente no navegador.
Utilizar o Nginx Proxy Manager como porta de entrada HTTPS
A parte mais reutilizável da solução comunitária é a arquitetura, e não os números exatos das portas de 2026. O Nginx Proxy Manager recebe pedidos HTTPS para nomes de anfitrião como jellyfin.example.net e encaminha-os para o serviço HTTP local do Jellyfin. O Jellyfin pode continuar a escutar na sua porta interna normal; não precisa de gerir o certificado público.
O Nginx Proxy Manager atual mantém este modelo: criar um Proxy Host, especificar o anfitrião e a porta de destino, e associar um certificado SSL, forçando opcionalmente o SSL. Numa configuração nova, siga o fluxo atual do Nginx Proxy Manager para anfitriões proxy e certificados, em vez de tratar uma captura de ecrã antiga como uma descrição fixa da interface.
Resolver os conflitos das portas 80 e 443 antes de emitir certificados
O utilizador descobriu que o gateway do ZimaOS já estava a utilizar as portas 80 e 443. Isto é importante porque um proxy inverso normalmente precisa de escutar nessas portas padrão. A solução aplicada foi alterar as portas do gateway do ZimaOS no ficheiro /etc/casaos/gateway.ini, mudando a porta 80 para 85 e a 443 para 444, e depois reiniciar o serviço do gateway.
Essas alterações específicas foram indicadas pelo utilizador, não por uma resposta do suporte da IceWhale neste tópico. Devem ser consideradas uma solução alternativa histórica da comunidade, e não uma sequência universal de comandos. Antes de alterar as portas do painel, registe o URL atual, certifique-se de que sabe como voltar a aceder ao ZimaOS e prefira a interface atual do ZimaOS quando esta disponibilizar uma forma suportada de alterar a porta de gestão.
Por que motivo o DuckDNS ajudou o utilizador
Uma autoridade de certificação precisa de um nome de anfitrião que possa validar. O utilizador configurou o DuckDNS e utilizou esse nome de anfitrião para solicitar um certificado através do Nginx Proxy Manager. Isso resolveu um problema diferente de “como acedo à aplicação?”: o DNS forneceu o nome, enquanto o NPM forneceu a terminação HTTPS e o encaminhamento.
O HTTPS apenas local continua a precisar de DNS com resolução local
A pergunta original referia-se especificamente ao HTTPS dentro da rede local, e não ao acesso remoto. Um nome de domínio não obriga o tráfego a sair de casa. Pode fazer com que um nome de anfitrião seja resolvido para o endereço LAN do ZimaOS dentro da sua rede através de DNS local ou DNS dividido e, em seguida, permitir que o Nginx Proxy Manager disponibilize um certificado válido para esse nome de anfitrião.
Normalmente, isto é mais simples do que navegar para um endereço IP privado bruto e tentar fazer corresponder-lhe um certificado público. O certificado é validado para o nome de anfitrião; o DNS local determina que esse nome deve ser resolvido para um endereço privado.
Um certificado autoassinado é outra opção, mas é necessário gerir a confiança
Uma resposta da comunidade sugeriu gerar um certificado com o OpenSSL e importá-lo para o Nginx Proxy Manager. Isto pode funcionar para utilização exclusivamente local, mas os navegadores e dispositivos não confiarão automaticamente num certificado autoassinado. Todos os clientes que devam apresentar uma ligação HTTPS válida precisam de confiar no certificado emissor ou na autoridade de certificação local.
Numa casa com vários telemóveis, televisores, tablets e aplicações, utilizar um certificado publicamente confiável para um nome de anfitrião é frequentemente mais simples do que instalar manualmente uma autoridade de certificação local em todo o lado.
O Cloudflare é uma arquitetura alternativa, não um requisito
Outro participante afirmou que utilizava o Cloudflare tanto dentro como fora da rede doméstica. O Cloudflare pode ser útil se o mesmo nome de anfitrião tiver de funcionar remotamente, mas a pergunta original não exigia acesso público. Não adicione um túnel simplesmente porque pretende HTTPS na LAN.
Verificar cada camada separadamente
- Confirme que a aplicação abre através do seu endereço HTTP local direto.
- Confirme que o nome de anfitrião é resolvido para o proxy inverso pretendido.
- Confirme que o Nginx Proxy Manager consegue alcançar o anfitrião e a porta internos da aplicação.
- Associe o certificado apenas depois de o encaminhamento simples do proxy funcionar.
- Em seguida, force o HTTPS e teste a partir de mais do que um cliente local.
Esta ordem evita confundir um problema do certificado com um problema de encaminhamento do Docker ou um conflito de portas.
Perguntas frequentes sobre HTTPS local no ZimaOS
O botão de HTTPS do ZimaOS protege automaticamente o Jellyfin?
Não. Protege a interface de gestão do ZimaOS, não todas as aplicações Docker.
Preciso de um domínio público para utilizar HTTPS apenas na LAN?
Precisa de um nome de anfitrião correspondente ao certificado. Esse nome pode ser resolvido para um endereço LAN privado dentro da sua rede.
Por que motivo o utilizador afastou o ZimaOS das portas 80 e 443?
O Nginx Proxy Manager precisava das portas HTTP e HTTPS padrão. Essa alteração foi uma solução alternativa da comunidade para essa instalação.
A configuração do utilizador foi confirmada como funcional?
Sim. O autor original mostrou os anfitriões do NPM online com certificados e afirmou que a configuração funcionava.
