A acessibilidade do Jellyfin é feita por camadas: a descoberta, a resolução de nomes, o encaminhamento, as políticas de firewall e a NAT remota podem falhar de forma independente.
Um cliente pode não conseguir descobrir um servidor enquanto um URL local direto funciona, ou conseguir aceder à LAN enquanto o acesso remoto falha fora de casa. Estes sintomas parecem semelhantes no ecrã, mas pertencem a diferentes camadas da rede. Teste primeiro o caminho mais curto e adicione camadas apenas quando souber que a anterior funciona.
A descoberta não é acessibilidade básica
A descoberta automática ajuda um cliente a encontrar um servidor, mas um endereço direto e uma porta de serviço podem funcionar mesmo quando a descoberta não funciona. Considerar a descoberta como prova de acessibilidade total conduz ao teste errado.
O modelo de acessibilidade por camadas separa a descoberta local do acesso direto e mostra por que motivo os dois resultados podem divergir.
Uma descoberta falhada deve restringir o teste a multicast, isolamento do cliente ou política local, em vez de implicar imediatamente o processo do servidor.
O DNS e o encaminhamento são camadas separadas
Um nome pode ser resolvido para um endereço enquanto o cliente continua sem uma rota, permissão de firewall ou interface utilizável. As VPN, o DNS dividido e várias interfaces de rede tornam esta separação especialmente importante.
Use o encaminhamento DNS para distinguir a resolução DNS do encaminhamento de pacotes e da seleção do caminho.
Se o nome for resolvido, mas a porta estiver inacessível, as evidências já ultrapassaram a camada DNS.
A acessibilidade remota acrescenta NAT e políticas
As sessões remotas acrescentam endereçamento público, comportamento da NAT, regras de firewall, caminhos através de proxy ou VPN e, muitas vezes, um limite de carregamento diferente. Um sucesso local não prova que o caminho externo consegue aceder ao mesmo serviço.
A arquitetura do modelo de acessibilidade por camadas explica como as camadas remotas prolongam o caminho local, em vez de o substituírem.
A fronteira muda quando a falha ocorre apenas fora da LAN; investigue a NAT, o firewall, o proxy ou as condições de carregamento antes da descoberta local.
Use um mapa de acessibilidade pelo caminho mais curto
Teste o endereço local direto, o nome local, o nome remoto, a porta do serviço e, por fim, todo o fluxo de trabalho do cliente. Registe a camada em que o estado muda pela primeira vez de acessível para inacessível.
Use o DNS e o encaminhamento para manter o teste específico da camada e evitar alterar várias variáveis de rede ao mesmo tempo.
Pare assim que uma camada explicar a falha. Uma camada inferior bem-sucedida é uma indicação para avançar, não uma autorização para reescrever toda a rede.
Centro de Tecnologia e IA
Mais para Ler

Porque é que a arquitetura do Home Assistant muda à medida que um servidor doméstico adiciona mais serviços?
Mais serviços alteram a arquitetura do Home Assistant quando adicionam estado partilhado, filas, dispositivos, ciclos de atualização ou domínios de falha — e não...

Como medir o desempenho do Home Assistant sem confundir a cache com a capacidade
Um resultado em estado quente prova reutilização, não capacidade. Meça o arranque a frio, o estado estacionário em quente, a carga repetida, a latência...

De quanta simultaneidade de automações precisa o Home Assistant para controlar toda a casa?
A maioria das automatizações para toda a casa precisa apenas de uma sobreposição limitada; dimensione a simultaneidade com base na duração da execução ×...

