A quarta página de uma longa discussão de apoio do ZimaOS acompanha as falhas recorrentes do Jellyfin e do Nginx Proxy Manager de um utilizador após a primeira configuração bem-sucedida do acesso remoto. A lição útil não é uma única porta mágica: um erro 502 pode voltar a ocorrer sempre que o destino do proxy inverso, o mapeamento de portas do Jellyfin, a rede Docker ou o estado da aplicação se alteram.
Esta página centra-se apenas nas publicações 61–80. Não repete a configuração anterior do DuckDNS e do certificado, abordada noutro local da mesma discussão.
Separe a mensagem da API do NPM do erro 502 do Jellyfin
O utilizador viu primeiro “A comunicação com a API falhou; o NPM está a ser executado corretamente?”. A análise dos registos pela comunidade mostrou que o próprio Nginx Proxy Manager estava em execução e que a renovação do Let's Encrypt tinha sido concluída com êxito. A mensagem temporária da API podia, por isso, ser uma sessão antiga do navegador ou uma breve interrupção da comunicação entre a interface e o back-end, enquanto o erro 502 público continuava a ser um problema separado entre o proxy e o Jellyfin.
Mantenha distintos os três tipos de endereço
| Tipo de endereço | Exemplo de função | O NPM deve encaminhá-lo para aí? |
|---|---|---|
| Endereço WAN público | Endereço voltado para o ISP, atualizado pelo DuckDNS | Não |
| endereço LAN do ZimaOS | Endereço estável da rede doméstica, como o 192.168.1.50
|
Sim, quando o Jellyfin publica uma porta do anfitrião |
| Endereço ou nome do contentor Docker | Ponto final interno, como jellyfin:8096
|
Sim, mas apenas quando o NPM consegue aceder à mesma rede Docker |
A discussão alternava repetidamente entre um nome de contentor, um endereço LAN do anfitrião e um endereço Docker interno. Estes não são intercambiáveis. Escolha uma rota suportada e teste-a a partir do contentor NPM antes de alterar o TLS ou o DNS.
Leia o mapeamento de portas na direção correta
As definições do Jellyfin mostravam a porta do anfitrião 8097 mapeada para a porta do contentor 8096. Quando o NPM se liga através do endereço LAN do ZimaOS, tem de utilizar a porta do anfitrião publicada. Quando o NPM se liga diretamente através do nome do contentor numa rede Docker partilhada, normalmente utiliza a porta interna do Jellyfin.
Um reinício da ligação a partir do interior do NPM mostrou que a rota selecionada continuava sem produzir uma resposta válida do Jellyfin. Isto é uma evidência mais útil do que simplesmente reiniciar ambos os contentores.
Utilize uma ordem de diagnóstico por camadas
- Abra o Jellyfin localmente e confirme a reprodução antes de mexer no proxy.
- Confirme que o contentor do Jellyfin está em execução e consulte o mapeamento guardado entre as portas do anfitrião e do contentor.
- Escolha o endereço LAN estável do ZimaOS juntamente com a porta do anfitrião publicada, ou o nome de um contentor juntamente com a porta interna numa rede partilhada.
- Teste esse endpoint exato a partir do ambiente do NPM.
- Só depois de o encaminhamento HTTP funcionar deve reativar o TLS e testar o domínio público.
- Depois de qualquer alteração da aplicação ou reinício, repita os testes locais e do proxy antes de alterar o DNS.
Uma alteração do caminho multimédia pode desencadear uma falha diferente
Mais tarde, os utilizadores remotos conseguiam navegar no Jellyfin, mas não conseguiam reproduzir multimédia. O proprietário alterou as definições do contentor do Jellyfin e o site público deixou de responder. A análise dos registos pela comunidade mostrou então que o Jellyfin estava em execução e a analisar /Media/Movies, desviando novamente a atenção para o destino do proxy. Isto ilustra por que razão cada alteração deve ser registada e testada de forma independente.
Os caminhos Linux distinguem maiúsculas de minúsculas durante a cópia de segurança
Uma cópia de segurança da configuração falhou porque o comando fazia referência a /DATA/AppData/duckdns, enquanto o diretório real era /DATA/AppData/DuckDNS. O Linux trata-os como caminhos diferentes. O tópico de origem propôs um comando de arquivo criado pela comunidade, mas este não foi fornecido pela IceWhale, pelo que não é reproduzido aqui como procedimento oficial de cópia de segurança.
Antes de arquivar a AppData, liste os nomes exatos dos diretórios, pare as aplicações quando as respetivas bases de dados exigirem um instantâneo consistente e verifique o arquivo restaurando uma cópia numa localização temporária.
Acesso remoto atualmente suportado
Para administração e acesso a ficheiros, a documentação atual do ZimaOS recomenda o acesso encriptado ponto a ponto através do acesso remoto do ZimaClient. Um proxy inverso público do Jellyfin continua a ser um procedimento avançado de terceiros e deve expor apenas o serviço multimédia, não o painel do ZimaOS.
Perguntas frequentes sobre o erro 502 do Jellyfin
A indicação «Falha na API do NPM» prova que o NPM está parado?
Não. No tópico, os registos do NPM e a renovação do certificado estavam normais, enquanto o navegador apresentava essa mensagem.
O NPM deve usar a porta 8096 ou 8097?
Utilize a porta interna com ligação direta ao contentor ou a porta do anfitrião publicada ao encaminhar para o endereço LAN do ZimaOS.
Porque é que a cópia de segurança indicou que o DuckDNS não existia?
A pasta AppData real usava um D maiúsculo e DNS; os caminhos Linux distinguem maiúsculas de minúsculas.
