Como testar se o DNS está a causar falhas de ligação ao Plex
Comprove primeiro a conectividade direta por IP; só investigue o DNS quando o Plex funcionar através do endereço, mas falhar através do nome de anfitrião habitual, da descoberta da aplicação ou do percurso de ligação segura.
O DNS pode fazer o Plex falhar devido a um resolvedor fornecido pelo router, a filtragem do Pi-hole ou do Unbound, a respostas antigas em cache no cliente, a regras de DNS dividido ou à proteção contra reatribuição em torno de `plex.direct`. Estas falhas podem parecer uma indisponibilidade do servidor, embora o serviço esteja acessível por IP. Use um cliente com falhas, um endereço de servidor conhecido e um resolvedor alternativo para isolar a resolução de nomes antes de alterar redirecionamentos de portas, bibliotecas ou definições de contentores.
Comprove a Conectividade por IP Antes de Testar o DNS
Use o endereço privado conhecido do servidor Plex na LAN e confirme que o anfitrião está acessível e que a porta do Plex responde. Se o percurso por IP falhar, o DNS não é a primeira causa. Corrija o encaminhamento, a firewall, o endereçamento do anfitrião ou a disponibilidade do serviço antes de alterar as definições do resolvedor.
Um diagnóstico de DNS só se torna credível depois de o acesso direto por IP funcionar. Se o mesmo cliente conseguir aceder ao Plex através do endereço, mas não através do nome habitual ou do percurso seguro, o comportamento do resolvedor torna-se uma linha de investigação clara.
Registe o IP funcional e o nome de anfitrião com falhas ou o comportamento da aplicação. Se ambos falharem, pare o teste de DNS. Se o IP funcionar e o percurso normal do Plex falhar, terá uma linha de investigação clara para verificar o resolvedor, o nome seguro ou a reatribuição.
Compare as Respostas do Resolvedor e o Comportamento de Reatribuição
Consulte o nome de anfitrião com falhas através do resolvedor que o cliente utiliza efetivamente e compare a resposta com a de um cliente conhecido por funcionar ou com um resolvedor fiável temporário. Se as respostas forem diferentes, inspecione o DNS atribuído por DHCP, as reescritas locais e a filtragem antes de alterar o Plex ou o NAT.
`plex.direct` pode resolver para o endereço privado de um servidor, pelo que a proteção contra reatribuição de DNS pode bloquear a resposta, mesmo que o próprio anfitrião Plex esteja saudável. Consulte os registos do resolvedor para encontrar consultas relacionadas com o Plex bloqueadas ou reescritas, em vez de desativar globalmente a proteção contra reatribuição.
Contorne temporariamente um resolvedor num cliente, repita o mesmo pedido do Plex e mantenha apenas a alteração mais limitada que corrige o percurso com falhas. Se o resolvedor alternativo não fizer qualquer diferença, reverta o teste e avance para os certificados, a descoberta da aplicação, a firewall ou o encaminhamento remoto.
Se ambos os resolvedores devolverem a mesma resposta e o controlo por IP direto continuar a funcionar, é menos provável que o DNS seja a falha ativa. Preserve esse resultado e avance para a validação de certificados, a descoberta da aplicação, a política da firewall ou o percurso remoto, em vez de adicionar mais exceções ao resolvedor.
Separe uma Falha de DNS Local de uma Falha de Acesso Remoto
Um problema de DNS na LAN pode fazer com que os clientes locais tratem o servidor como indireto ou indisponível, enquanto o acesso remoto externo continua a funcionar. Também pode acontecer o inverso: os nomes locais resolvem corretamente, mas a porta pública ou o percurso CGNAT está bloqueado. Testar ambos os sentidos impede que um sintoma esconda o outro.
Uma exceção de domínio privado pode corrigir o comportamento do resolvedor local, mas não cria um percurso de entrada pela Internet; uma falha apenas remota continua a pertencer à topologia do NAT, da firewall ou do ISP.
Teste um cliente da LAN com o DNS normal, o mesmo cliente com um resolvedor alternativo temporário e um cliente remoto através de dados móveis. Anote quais as células da matriz que funcionam. Esse padrão indica normalmente se o DNS é local, remoto ou não está relacionado.
Mantenha a Correção Apenas se Esta Sobreviver a Alterações de Cache e Reinícios
As correções de DNS podem parecer funcionar porque a cache de um cliente conserva uma resposta antiga ou porque ainda está ativo um contorno temporário do resolvedor. Limpe ou deixe expirar a cache relevante, renove as definições de rede do cliente e reinicie uma vez o resolvedor ou o router antes de declarar o problema resolvido.
A reatribuição de DNS e as definições de NAT podem sobrepor-se, por isso documente qual é a única alteração que resolve o teste com falhas, em vez de manter várias exceções desnecessárias.
Se o DNS apenas revelar uma alteração maior no router ou na sub-rede, o percurso de acesso remoto após a alteração do router torna-se a próxima linha de investigação, depois de restaurar as definições normais do cliente.
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...
