Porque é que o Jellyfin perde sessões após uma alteração do proxy ou do DNS?

Uma alteração no proxy ou no DNS não deverá, por si só, destruir todos os inícios de sessão do Jellyfin. A perda de sessão costuma ocorrer quando a alteração também modifica o nome do anfitrião, o esquema, o caminho, a identidade do servidor de backend, a camada de autenticação ou a rota do cliente esperada pelo estado de início de sessão existente.

Comece por distinguir uma simples atualização do registo DNS de uma alteração da origem. Mantenha uma conta e um dispositivo conhecidos fixos, compare o acesso direto pela LAN com o nome de anfitrião público normal e registe o primeiro pedido que falhou antes de limpar os dados do cliente. O objetivo é identificar que fronteira mudou, não repor utilizadores até o sintoma desaparecer.

Decida Primeiro Se a Origem Pública Mudou Realmente

Anote o esquema, o nome de anfitrião, a porta, o caminho base e a rota do proxy antigos e novos. Um registo DNS A ou AAAA pode apontar o mesmo nome de anfitrião para um endereço diferente sem alterar a origem do navegador, enquanto passar de um nome de anfitrião para outro ou alterar o caminho base de uma aplicação cria uma fronteira diferente para o cliente. As migrações de domínios personalizados também exigem que a aplicação e o caminho de autenticação concordem sobre o novo domínio; uma lista de verificação para a migração de domínios personalizados torna explícita essa ligação entre DNS e aplicação.

O estado de autenticação é sensível ao local onde é apresentado. Uma útil lista de verificação do âmbito dos cookies de sessão começa por mapear o domínio e o caminho associados a cada mecanismo de autenticação. Os clientes Jellyfin não armazenam todos o estado exatamente da mesma forma, por isso teste o cliente afetado em vez de presumir que o comportamento do navegador descreve todas as aplicações.

Se o nome de anfitrião antigo ainda funcionar, mas o novo pedir o início de sessão, considere isso uma migração de origem esperada até prova em contrário. Se o mesmo nome de anfitrião terminar a sessão de todos apenas depois de o proxy ser alterado, mantenha o nome de anfitrião e investigue a identidade a montante, os cabeçalhos e a autenticação do lado do proxy.

Verifique Se o DNS Continua a Chegar à Instância Jellyfin Pretendida

Resolva o nome de anfitrião a partir de um cliente na LAN e, se o acesso remoto for relevante, a partir de um resolvedor externo. Confirme que o endereço devolvido chega ao proxy inverso pretendido e que o proxy encaminha para o serviço Jellyfin esperado, e não para um contentor antigo, uma instância de teste, um clone restaurado ou um segundo servidor com uma base de dados persistente diferente.

Uma mudança de DNS pode parecer um problema de sessão quando, na realidade, envia o cliente para um backend diferente. Compare uma resposta que identifique o servidor, o comportamento da lista de utilizadores, o estado da biblioteca e o destino a montante do proxy antes de alterar a autenticação. Se a nova rota chegar a uma instância Jellyfin nova ou restaurada, as credenciais existentes do cliente podem já não representar uma sessão válida nessa instância.

O fluxo de trabalho relacionado da ZimaSpace para manter separados os ciclos de vida do proxy e do estado da sessão é útil neste caso: um reinício do ponto de entrada não deverá substituir silenciosamente a identidade da aplicação nem o estado que valida as sessões existentes.

Compare o Host, o Esquema, o Caminho Encaminhados e a Autenticação do Proxy

Registe a configuração efetiva do proxy depois da alteração. Compare o valor público de Host, o esquema encaminhado, o endereço do cliente, o caminho de atualização do websocket, os redirecionamentos e qualquer middleware de autenticação com a última configuração funcional. Um redirecionamento de HTTPS para um URL HTTP ou para um nome de anfitrião alternativo inesperado pode fazer com que um início de sessão válido pareça ter desaparecido.

Se existir outra camada de autenticação à frente do Jellyfin, mantenha estáveis a chave de assinatura, o nome do cookie, o domínio do cookie e o armazenamento de sessões durante a substituição do proxy. As arquiteturas com balanceadores de carga utilizam estado de afinidade de sessão e de encaminhamento para manter um pedido no backend pretendido; alterar essa camada pode criar uma terminação de sessão ou um ciclo, mesmo que o próprio Jellyfin continue saudável.

Não copie cegamente cabeçalhos de um exemplo de proxy não relacionado. Altere apenas um valor quando o pedido falhado ou o redirecionamento demonstrar que o valor atual está errado. A configuração de proxy mais segura é a mais pequena que preserva a origem pública e chega consistentemente ao backend correto.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Utilize um Teste de Cliente Limpo Sem Apagar as Provas Originais

Antes de limpar qualquer elemento, guarde a hora da falha, a versão do navegador ou da aplicação, o estado do pedido, a cadeia de redirecionamentos, a linha do registo do proxy e a entrada do registo do Jellyfin. Depois, utilize uma janela privada do navegador ou um segundo dispositivo de teste para iniciar sessão através da nova rota. Um novo início de sessão que funcione prova a acessibilidade; não explica por que motivo o estado antigo deixou de ser utilizável.

Compare três caminhos, por esta ordem: o endereço Jellyfin direto da LAN, o nome de anfitrião normal a partir da LAN e o nome de anfitrião normal a partir do exterior da LAN. Se o acesso direto funcionar enquanto o nome de anfitrião falha, mantenha os utilizadores e o estado da base de dados inalterados e investigue o DNS, o TLS, o proxy ou o middleware. Se todos os caminhos rejeitarem a mesma conta conhecida e válida, o problema voltou a estar dentro do Jellyfin ou do seu estado persistente.

Limpe o estado específico do site apenas no cliente afetado depois de recolher as provas do caminho do pedido. Evite eliminar todos os dispositivos registados ou revogar todas as sessões como primeiro passo, pois isso remove a comparação que poderia distinguir uma migração de encaminhamento de uma falha de autenticação do lado do servidor.

Valide a Alteração Através da Expiração do DNS, do Reinício do Proxy e do Reinício do Sistema

Depois de aplicar a correção correspondente, deixe expirar a janela do TTL do DNS anterior, reinicie apenas o proxy, depois reinicie o serviço Jellyfin e, por fim, reinicie o anfitrião. Repita os testes de início de sessão, fim de sessão, início da reprodução, avanço e retrocesso e nova ligação através do mesmo nome de anfitrião após cada evento.

Um resultado estável significa que o nome de anfitrião continua a resolver para o proxy pretendido, que o proxy volta a ligar-se à instância Jellyfin pretendida, que as sessões existentes sobrevivem aos reinícios normais dos componentes quando tal é esperado e que um novo início de sessão continua válido. Se as falhas surgirem apenas durante o arranque completo da pilha, utilize o caminho de recuperação entre o proxy e o serviço a montante para separar a prontidão da autenticação.

Registe nas notas da implementação o nome de anfitrião final, o nome do serviço a montante do proxy, o caminho base, a origem do certificado e qualquer segredo de sessão do lado do proxy. Assim, futuras alterações de DNS ou do proxy poderão ser testadas face a um contrato de identidade conhecido, em vez de este ter de ser redescoberto a partir dos sintomas do navegador.

Perguntas frequentes

A alteração de um registo DNS, por si só, invalida as sessões do Jellyfin?

Normalmente não, quando continuam a ser utilizados o mesmo nome de anfitrião, esquema, caminho e instância Jellyfin. Uma alteração de DNS torna-se relevante para a sessão quando envia os clientes para um backend diferente, altera a origem pública, modifica o TLS ou os redirecionamentos, ou altera uma camada de autenticação à frente do Jellyfin.

Devo revogar todas as sessões do Jellyfin depois de alterar um proxy?

Não como primeira medida de reparação. Preserve um cliente com falhas como prova, confirme que a nova rota chega ao servidor pretendido e teste separadamente um novo início de sessão. Revogue sessões apenas quando tiver rodado credenciais de forma intencional, suspeitar de exposição de tokens ou confirmar que o estado antigo do cliente já não deve ser considerado fiável.