O Jellyfin funciona por Wi-Fi, mas falha através de Ethernet ou VPN

Se o Jellyfin funcionar através de Wi-Fi, mas falhar através de Ethernet ou de uma VPN, o servidor está normalmente saudável; o caminho até ele é que mudou. As causas mais comuns são um IP/sub-rede ou uma resposta DNS diferentes, uma rota que prefere a interface errada, regras de firewall/rede local que classificam a ligação de forma diferente ou uma rota VPN que se sobrepõe à LAN.

Utilize um URL do Jellyfin conhecido por funcionar e faça testes por camadas a partir do cliente afetado. Primeiro, confirme o IP de destino e a porta; depois, compare as rotas; em seguida, verifique a firewall e as Redes Locais do Jellyfin; só depois analise o comportamento específico da VPN relativamente à sub-rede ou ao nó de saída. Não reinstale o Jellyfin enquanto o mesmo servidor estiver acessível através de outra interface, pois essa evidência já aponta para um problema de rede e não para o estado da aplicação.

Compare o Endereço de Destino através de Wi-Fi e Ethernet

Na ligação Wi-Fi funcional, registe o nome do anfitrião do Jellyfin, o endereço IP resolvido, a sub-rede do cliente e a porta. Mude para Ethernet e repita as mesmas verificações. Se o nome do anfitrião for resolvido para um endereço diferente ou inacessível, corrija o DNS ou a rota do cliente antes de alterar as definições do Jellyfin.

A documentação de rede do Jellyfin explica que o acesso normal utiliza o IP do anfitrião e a porta HTTP(S) configurada, enquanto a descoberta local está limitada à sub-rede local. Consulte o comportamento da rede local quando um cliente ligado por cabo está numa VLAN ou sub-rede diferente da rede Wi-Fi.

Teste diretamente o IP do servidor através de Ethernet. Se o IP funcionar, mas o nome do anfitrião falhar, o problema está no DNS. Se nenhum dos dois funcionar, prossiga para as verificações de rota e firewall; se a porta TCP estabelecer ligação, mas a aplicação se comportar de forma diferente, analise a classificação local/remota do Jellyfin.

Verifique Que Interface e Rota o Cliente Está Realmente a Utilizar

Um computador com adaptadores Wi-Fi, Ethernet e VPN pode manter várias rotas em simultâneo. Quando a Ethernet é ligada, o sistema operativo pode preferir uma nova rota predefinida ou uma rota de sub-rede mais específica, enviando o tráfego do Jellyfin por um caminho diferente do caminho Wi-Fi funcional.

Inspecione a rota para o IP do servidor Jellyfin utilizando as ferramentas de encaminhamento do seu sistema operativo e compare-a com o estado funcional. Desative temporariamente apenas uma interface para confirmar a causa e, depois, volte a ativá-la; não elimine permanentemente rotas até saber qual é a regra incorreta.

Se a rota apontar para o gateway Ethernet correto e o servidor estiver acessível através de ping, mas a porta do Jellyfin falhar, o próximo teste deverá ser à firewall ou à ligação do serviço, e não ao DNS.

Verifique as Regras da Firewall e as Redes Locais do Jellyfin

Compare a política da firewall para a sub-rede Ethernet, a sub-rede VPN e a sub-rede Wi-Fi. Os routers domésticos e os switches geridos aplicam frequentemente regras diferentes para VLAN ou redes de convidados, mesmo quando as três ligações estão fisicamente dentro da mesma casa.

No Jellyfin, reveja os valores CIDR das Redes Locais e a política de acesso remoto. Um cliente proveniente de uma sub-rede não listada pode ser tratado como remoto, o que pode alterar a permissão de acesso desse utilizador, apesar de o servidor estar normalmente à escuta.

Para um exemplo mais abrangente de separação entre sucesso local e falha do caminho remoto, consulte os caminhos de acesso local e remoto. A mesma disciplina aplica-se aqui: confirme cada salto da rede antes de alterar a aplicação.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Procure uma Sobreposição de Sub-redes da VPN ou um Comportamento do Nó de Saída

Quando a falha ocorre apenas com uma VPN ativa, compare as rotas da VPN com a LAN física. Duas redes que utilizem a mesma sub-rede privada podem fazer com que o cliente envie o tráfego do Jellyfin para o túnel, apesar de o servidor estar fisicamente próximo.

A Tailscale documenta casos em que as rotas de sub-rede, os nós de saída ou as definições de acesso à LAN podem impedir um cliente de alcançar um dispositivo local. Utilize a sua resolução de problemas de conectividade LAN como exemplo de como o encaminhamento da VPN pode substituir o caminho que funcionava antes de o túnel ser ativado.

Desative temporariamente a aceitação de rotas da VPN ou o nó de saída e volte a testar o mesmo IP do Jellyfin. Se o acesso voltar imediatamente, mantenha o servidor Jellyfin inalterado e corrija antes o encaminhamento da VPN ou a política de acesso à LAN.

Volte a Testar o Caminho Original do Cliente Depois de Cada Correção de Rede

Depois de identificar a causa, aplique apenas a alteração correspondente: corrija o DNS, ajuste as métricas ou os prefixos das rotas, permita a sub-rede Ethernet/VPN na firewall ou corrija a entrada das Redes Locais do Jellyfin. Em seguida, reative todas as interfaces normais e repita o método de ligação original.

Verifique tanto o cliente Web do Jellyfin como um cliente nativo, se a sua casa utilizar ambos, pois a descoberta, os URLs de servidor guardados e o acesso HTTP direto podem seguir caminhos diferentes. Teste também depois de reiniciar ou voltar a ligar o cliente, para que as rotas em cache não façam um sucesso temporário parecer permanente.

Só avance para uma investigação mais aprofundada se o IP de destino, a rota, a firewall e a classificação das Redes Locais estiverem todos corretos, mas a mesma interface continuar a falhar. Recolha as tabelas de rotas funcionais e problemáticas, os IPs dos clientes e os registos do servidor relativos a uma tentativa; essa evidência é muito mais útil do que reinstalar o Jellyfin ou repor todas as definições de rede de uma só vez.