Este longo tópico de suporte aborda muitos temas para principiantes, mas o resultado mais útil e pesquisável parece estar na página 3: um servidor Jellyfin funcionava localmente, o DuckDNS era resolvido e existia um certificado SSL, mas o domínio público devolvia 502 Bad Gateway. A comunidade acabou por separar o problema em três camadas: o Nginx Proxy Manager conseguir chegar ao Jellyfin, a configuração TLS e a utilização da porta 443 pelo router.
A descoberta decisiva ocorreu quando o utilizador desativou o serviço NAS do próprio router na porta 443. Depois disso, tanto o HTTP como o HTTPS passaram a chegar ao Jellyfin.
Um erro 502 significava que o proxy não conseguia chegar ao Jellyfin
A resolução de problemas da comunidade começou por se centrar no destino upstream do Nginx Proxy Manager. O serviço HTTP normal do Jellyfin estava na porta 8096; o proxy precisava de encaminhar para o contentor Jellyfin através de HTTP, em vez de tratar a porta HTTPS opcional do Jellyfin como upstream.
As orientações atuais do Jellyfin seguem o mesmo modelo: os exemplos de proxy inverso Nginx encaminham o tráfego normal e os WebSockets para o Jellyfin na porta 8096.
O proxy e o Jellyfin precisam de um caminho Docker acessível
Numa fase, utilizar o nome do contentor não funcionava, pelo que o membro da comunidade que prestava ajuda alterou o proxy para o endereço Docker interno do Jellyfin. Isso fez com que o acesso por HTTP começasse a funcionar.
Utilizar o endereço IP interno variável de um contentor é menos robusto do que colocar ambos os serviços numa rede Docker partilhada e controlada, com resolução estável dos nomes dos serviços. O tópico original documenta o que funcionou naquela instalação, não um modelo Compose ideal para todos os servidores.
Corrija o encaminhamento HTTP antes de adicionar SSL
Uma das principais fontes de confusão foi alterar as opções TLS quando o proxy ainda não conseguia chegar ao Jellyfin. A sequência seguida pela comunidade removeu temporariamente o SSL do anfitrião proxy, verificou primeiro o encaminhamento HTTP simples e só depois voltou a ativar o certificado e a forçar HTTPS.
Esta ordem de resolução de problemas é mais valiosa do que copiar um determinado endereço IP: confirme primeiro o encaminhamento para o upstream e só depois diagnostique o TLS.
O router estava a utilizar a porta 443
Depois de o HTTP finalmente abrir o Jellyfin, voltar a ativar o HTTPS encaminhava o utilizador para a página de início de sessão do router. Essa foi a pista mais forte do tópico: as ligações recebidas na porta 443 estavam a ser tratadas pela funcionalidade NAS/gestão do próprio router, em vez de serem encaminhadas para o Nginx Proxy Manager.
O utilizador desativou o serviço NAS interno do router na porta 443 e confirmou então que o HTTPS funcionava.
O HTTPS remoto funcionar não garantia a deteção local pela aplicação
Mais tarde, o tópico abordou clientes Roku e móveis. O acesso através do navegador pelo domínio público funcionava, mas a deteção automática local e o comportamento de hairpin/NAT loopback continuavam inconsistentes. A comunidade acabou por utilizar DLNA como solução prática para o Roku.
Esse acompanhamento não deve ser misturado com o problema 502/HTTPS já resolvido. O encaminhamento remoto através de proxy inverso e a deteção de dispositivos locais são comportamentos de rede distintos.
Isto foi ajuda da comunidade sobre redes, não uma receita de segurança da IceWhale
Os passos detalhados do proxy inverso foram fornecidos por membros da comunidade. Expor o Jellyfin através de um domínio exige cuidados com o router, o TLS, a autenticação e as atualizações. Não publique serviços administrativos não relacionados do ZimaOS apenas porque a porta 443 está encaminhada para um proxy inverso.
Perguntas frequentes sobre Jellyfin e NPM
O que causou o erro 502 Bad Gateway?
Inicialmente, o Nginx Proxy Manager não conseguia chegar corretamente ao upstream do Jellyfin. Depois de corrigido o encaminhamento, o Jellyfin carregou através de HTTP.
Porque é que o HTTPS abriu a página de início de sessão do router?
O próprio router estava a utilizar a porta 443. Desativar ou mover esse serviço do router permitiu que a porta 443 chegasse ao Nginx Proxy Manager.
O NPM deve encaminhar o Jellyfin internamente através de HTTP ou HTTPS?
A configuração bem-sucedida do tópico e os exemplos atuais de Nginx do Jellyfin utilizam HTTP para o serviço Jellyfin na porta 8096, com o TLS a ser terminado no proxy inverso.
O HTTPS remoto faz com que o Jellyfin seja detetado automaticamente no Roku?
Não. A deteção do cliente, o isolamento Wi-Fi, a rede Docker e o NAT loopback são problemas distintos.
