Como corrigir falhas de início de sessão no Plex após reiniciar um proxy inverso
Se o início de sessão no Plex falhar apenas depois de o proxy inverso reiniciar, confirme primeiro o acesso local direto ao Plex; uma sessão direta funcional transfere a causa provável para o proxy, o DNS ou o percurso TLS.
O erro mais comum é repor as credenciais do Plex quando o próprio servidor continua saudável. Os proxies inversos acrescentam um endereço de upstream, um nome de anfitrião, um certificado, cabeçalhos de pedido e, por vezes, uma rede Docker entre o navegador e o Plex. Teste essas camadas pela ordem indicada. O objetivo da recuperação não é apenas voltar a apresentar a página de início de sessão uma vez; é fazer com que o mesmo percurso através do proxy sobreviva a um reinício controlado do proxy sem alterar a identidade do servidor Plex.
Confirme se o próprio Plex continua acessível
Abra o Plex diretamente na LAN, utilizando o endereço e a porta do servidor que normalmente usa para a gestão local. Se a mesma conta iniciar sessão e o servidor carregar, não altere a autenticação nem os dados do Plex. Já isolou o problema ao percurso acrescentado pelo proxy.
O Plex disponibiliza URLs de acesso personalizado ao servidor para configurações de rede invulgares, como proxies inversos e VPNs. Se o URL publicado pelo Plex já não corresponder ao nome de anfitrião ou ao esquema utilizado pelo cliente, o comportamento da descoberta e da ligação segura pode tornar-se inconsistente, mesmo quando o acesso local direto continua a funcionar.
Se o acesso local direto também falhar, deixe de considerar o reinício do proxy como a causa. Verifique primeiro o estado do contentor Plex, os registos do servidor e a montagem dos dados. A regra de decisão é rigorosa: se o acesso direto funcionar, o problema está no percurso do proxy; se falhar, o problema está no servidor ou no contentor.
Verifique o upstream do proxy depois do reinício
Inspecione o destino do proxy e confirme que este resolve para o serviço Plex atual. Um proxy configurado com base num IP temporário do contentor pode deixar de funcionar depois de um contentor ou de uma rede serem recriados. Prefira um endereço de anfitrião estável ou o nome de um serviço Docker numa rede definida pelo utilizador e partilhada, em vez de copiar um IP efémero para a configuração do proxy.
O comportamento das redes bridge definidas pelo utilizador do Docker permite a comunicação entre contentores na mesma rede através de nomes e proporciona um isolamento explícito. Assim, o nome de um serviço é um upstream mais duradouro do que um endereço de contentor que pode mudar durante eventos do ciclo de vida.
Depois de corrigir o upstream, recarregue apenas o proxy e tente novamente o URL do Plex através do proxy. Se o proxy passar a alcançar o Plex, mas o início de sessão continuar num ciclo, o próximo ramo de diagnóstico é o nome de anfitrião público, o TLS ou o URL de acesso publicado, e não o percurso do contentor.
Verifique o nome de anfitrião e o percurso TLS sem enfraquecer a segurança
Confirme que o navegador está a utilizar o nome de anfitrião HTTPS pretendido e que o proxy apresenta um certificado válido para esse nome. Não resolva uma incompatibilidade de certificado ou de nome de anfitrião desativando globalmente as ligações seguras. Se alterou o domínio ou o percurso do proxy, atualize o URL de acesso personalizado do Plex para que a descoberta do servidor direcione os clientes para o percurso que realmente mantém.
Para uma conceção mais abrangente do acesso remoto, o guia da ZimaSpace para acesso remoto a uma cloud privada destaca gateways controlados, túneis e limites explícitos, em vez de abrir serviços indiscriminadamente. A mesma regra aplica-se aqui: repare o percurso de entrada pretendido em vez de o contornar com uma exposição temporária insegura.
Limpe a sessão do navegador apenas depois de as verificações de encaminhamento e TLS passarem. Um cookie antigo pode complicar os testes, mas limpar o estado antes de reparar o percurso de rede pode ocultar a falha real. Utilize uma janela privada do navegador como teste limpo, sem eliminar o estado funcional dos clientes em todo o lado.
Reinicie novamente o proxy e repita o teste de início de sessão original
Quando o início de sessão funcionar, reinicie novamente o proxy inverso de propósito. Aguarde até ficar saudável e utilize exatamente o mesmo nome de anfitrião e o mesmo cliente que falharam inicialmente. Uma correção bem-sucedida significa que o upstream é resolvido, o TLS é válido, o Plex é descoberto no URL pretendido e a conta consegue iniciar sessão sem edições manuais após o reinício.
Se o segundo reinício voltar a interromper o percurso, inspecione a ordem de arranque e a resolução de nomes entre o proxy e o Plex. O problema não está resolvido se for necessário editar um IP manualmente após cada evento do ciclo de vida. Torne a dependência explícita na rede Docker ou na configuração do proxy.
Recorra ao diagnóstico da autenticação do Plex apenas quando o encaminhamento direto e através do proxy estiver saudável, mas a falha de início de sessão persistir em vários clientes. Nessa altura, recolha os registos do Plex com marcas temporais e os dados da conta e do servidor, em vez de continuar a alterar definições do proxy que já foram verificadas.
Produtos recomendados
Suporte e Dicas
Mais para Ler
O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...
Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...
Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...
