O Jellyfin pode funcionar atrás de um proxy inverso num subcaminho?

Sim. O Jellyfin pode funcionar atrás de um proxy inverso num subcaminho, como https://example.com/jellyfin, mas o Jellyfin e o proxy têm de usar o mesmo caminho base.

Uma falha num subcaminho costuma parecer um site parcialmente funcional: a página de início de sessão pode carregar, enquanto o JavaScript, as imagens, os WebSockets, os redirecionamentos ou os clientes nativos falham. Teste o caminho por camadas — primeiro o URL base, depois a rota do proxy e, por fim, os cabeçalhos encaminhados e o endereço do cliente — para distinguir um caminho incompatível de um problema de TLS ou de identidade do proxy.

Faça Corresponder o URL Base do Jellyfin ao Subcaminho Público

Defina o URL base do Jellyfin com o prefixo público exato que pretende utilizar, por exemplo /jellyfin. Não adicione um prefixo interno diferente apenas porque o proxy utiliza um bloco de localização nomeado; o caminho visível no navegador e o URL base do Jellyfin têm de descrever a mesma raiz da aplicação.

A documentação oficial do proxy inverso Apache do Jellyfin fornece explicitamente um exemplo de subcaminho e instrui os administradores a definir o URL base como /jellyfin antes de ligarem os clientes a esse endereço completo. exemplo oficial de subcaminho

Reinicie o Jellyfin depois de alterar o URL base e, em seguida, abra o subcaminho público numa nova janela privada do navegador. Se o redirecionamento inicial remover imediatamente /jellyfin ou o duplicar, corrija o URL base antes de alterar as definições de WebSocket ou autenticação.

Encaminhe o Mesmo Prefixo Através do Proxy Inverso

Configure o proxy inverso para que os pedidos que começam pelo prefixo público sejam encaminhados para o Jellyfin sem inventar uma transformação de caminho adicional. A conceção mais simples consiste num prefixo público, num URL base do Jellyfin correspondente e num serviço de backend.

O guia do Caddy para o Jellyfin mostra o mesmo padrão: configure o caminho base do Jellyfin, redirecione o prefixo sem barra final para a versão com barra final e faça proxy dos pedidos sob esse prefixo para o backend do Jellyfin. caminho base e rota de proxy correspondentes

Se o navegador receber um erro 404 do proxy antes de o Jellyfin registar o pedido, a rota está incorreta na camada do proxy. Se o Jellyfin receber o pedido mas gerar ligações sem o prefixo, o URL base está incorreto na camada da aplicação. Mantenha estas duas assinaturas de falha separadas.

Verifique os Recursos Estáticos e os WebSockets, Não Apenas a Página de Início de Sessão

Uma resposta HTML bem-sucedida não é suficiente para considerar saudável a configuração do subcaminho. Abra as ferramentas de desenvolvimento ou o registo do proxy e confirme que os pedidos de JavaScript, CSS, imagens, API e WebSocket permanecem todos sob o mesmo prefixo público.

Os exemplos de proxy inverso do Jellyfin incluem o tratamento de WebSockets, porque os clientes interativos mantêm uma ligação de socket além dos pedidos HTTP normais. Por isso, uma regra de proxy que trate apenas os pedidos das páginas pode parecer correta até que o estado da reprodução, as atualizações da sessão ou o comportamento da interface em tempo real falhem. requisitos do proxy inverso

A condição de sucesso é simples: não devem ocorrer respostas 404/502 repetidas para recursos com prefixo, a atualização do WebSocket deve ser bem-sucedida e a navegação não deve escapar para a raiz do site. Se falhar apenas uma classe de pedidos, corrija essa regra do proxy em vez de alterar a biblioteca ou as definições de autenticação do Jellyfin.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Preserve a Identidade do Cliente Através do Proxy

Depois de o caminho funcionar, verifique as informações encaminhadas do cliente. O Jellyfin utiliza a configuração de confiança do proxy para decidir se os endereços e protocolos encaminhados devem ser aceites, o que afeta o comportamento entre acesso local e remoto e as regras de acesso externo.

O guia de rede do Jellyfin avisa que os cabeçalhos encaminhados de um proxy não fidedigno são descartados e recomenda configurar o endereço do proxy em Proxies Conhecidos. definição de Proxies Conhecidos Uma verificação separada do IP do cliente é útil quando o site funciona, mas todos os pedidos parecem ter origem no proxy.

Não resolva um problema de identidade confiando em todas as sub-redes privadas ou em todos os cabeçalhos encaminhados. Adicione apenas o salto real do proxy ou a rede de proxy controlada e, em seguida, compare um pedido da LAN com um pedido remoto nos registos do Jellyfin para confirmar que são classificados conforme esperado.

Teste Separadamente os Endereços do Navegador e do Cliente Nativo

Introduza o endereço completo do servidor, incluindo o subcaminho, quando um cliente Jellyfin pedir o URL do servidor. Um cliente guardado como https://example.com não consegue inferir que o Jellyfin está localizado em /jellyfin.

Teste um navegador e um cliente nativo a partir da LAN e, em seguida, repita o teste através do nome de anfitrião público. Se o nome de anfitrião funcionar mas o acesso direto pelo IP local não, isso pode ser esperado quando a rota do proxy e o certificado dependem do nome de anfitrião; os testes de nome de anfitrião versus IP ajudam a isolar esse caso sem enfraquecer o proxy.

Pare quando o URL com prefixo funcionar no início de sessão, na navegação, na utilização de WebSockets e na reprodução nos clientes que realmente suporta. Se apenas um cliente falhar enquanto o navegador e os restantes clientes funcionam, trate o problema como uma questão de endereço ou compatibilidade do cliente, em vez de reescrever uma configuração de proxy que funciona.