Como reconstruir uma configuração do Jellyfin após mudar para uma nova rede
Reconstrua o Jellyfin após uma alteração de rede, restaurando primeiro o caminho do serviço local e validando depois, separadamente, as montagens de armazenamento, a identidade, o DNS e o acesso remoto.
Um novo router, uma nova sub-rede, VLAN ou domínio DNS pode fazer com que uma base de dados Jellyfin saudável pareça avariada, porque os clientes, as montagens e os proxies inversos deixam de partilhar o mesmo caminho. Guarde as notas da rede antiga e uma cópia dos dados da aplicação. O objetivo é ter um caminho conhecido entre o cliente, o serviço e os ficheiros multimédia, com um limite claro para parar quando a camada em falha for a própria rede — e não o Jellyfin.
Registe o caminho antigo antes de alterar seja o que for
Anote o endereço do servidor, o nome do anfitrião, a sub-rede, o gateway, o nome DNS, os caminhos dos ficheiros multimédia montados, o destino do proxy inverso, o nome do certificado e quaisquer regras de firewall ou reencaminhamento de portas. Separe o streaming local do streaming remoto. Se o anfitrião antigo ainda estiver disponível, exporte a configuração do Jellyfin e faça uma lista dos utilizadores e das bibliotecas antes de atribuir novos endereços.
Isto cria a referência para a reconstrução: um utilizador chega ao serviço, o serviço chega à sua base de dados e aos ficheiros multimédia, e as cópias de segurança chegam ao seu destino. Não comece por abrir uma porta pública ou criar uma nova regra de proxy.
Restaure o serviço local num endereço estável
Atribua ao servidor uma reserva DHCP ou um endereço estático e confirme que a interface Web do Jellyfin abre a partir da mesma LAN. Verifique o endereço de ligação do serviço e a firewall do anfitrião e teste um cliente local antes de alterar o DNS. Se a aplicação arrancar mas as bibliotecas estiverem vazias, pare e inspecione o caminho de armazenamento em vez de reconstruir a base de dados.
As orientações de migração do Jellyfin salientam que os dados internos dependem dos caminhos e que os caminhos dos contentores têm de corresponder às localizações multimédia registadas (orientações de migração dependentes dos caminhos). Trate uma incompatibilidade de caminhos como uma falha de topologia, não como uma falha de metadados.
Volte a ligar as montagens e as permissões antes do DNS
Monte os volumes de ficheiros multimédia e de cópias de segurança em caminhos estáveis e teste depois o acesso de leitura com a conta de serviço do Jellyfin. Verifique um ficheiro por biblioteca e uma escrita no diretório de dados da aplicação. Mantenha a cache e as capas transferidas num armazenamento que possa ser reconstruído, enquanto os ficheiros multimédia dos utilizadores, a base de dados e as cópias de segurança permanecem em funções protegidas.
O resultado é PASS quando um reinício recria as montagens antes de o Jellyfin arrancar e uma análise da biblioteca não produz avisos de ficheiros em falta. Se a montagem depender de uma sessão iniciada interativamente, corrija a ordem de arranque antes de continuar.
Reconstrua a identidade, o DNS e o acesso remoto por esta ordem
Depois de a reprodução local funcionar, restaure o nome do anfitrião e o registo DNS interno. Teste um cliente utilizando o nome, e não o IP, e valide depois o proxy inverso ou a VPN a partir do exterior da rede doméstica. Mantenha a autenticação e a autorização separadas do encaminhamento: uma falha de início de sessão não prova que o novo reencaminhamento de portas esteja incorreto.
Faça uma reprodução direta e uma transcodificação com a combinação real de clientes. Registe o endpoint observado, o modo de reprodução e o ponto de falha. Um caso de migração da comunidade é útil para comparar pressupostos relativos aos caminhos e à rede, mas não generalize as respetivas definições de hardware ou do router (estudo de caso de migração).
Mantenha explícitos o rollback e a expansão
Mantenha o registo DNS antigo, a cópia de segurança da configuração e as notas da rede anterior até a reprodução local, o acesso dos utilizadores, o encaminhamento remoto e a reposição terem sido todos aprovados. Expanda apenas adicionando um caminho dedicado — como uma VLAN separada para gestão ou uma segunda interface de rede — quando o caminho partilhado degradar. Pare a reconstrução se o servidor não conseguir obter um endereço estável, montagens persistentes ou uma rota de recuperação testada; nenhuma quantidade de reconfiguração dos clientes corrige essas bases em falta.
Produtos recomendados
Configuração de NAS e Servidor
Mais para Ler
Como a análise e a automatização semelhantes à IA alteram as necessidades de armazenamento e computação do Jellyfin
A automatização e a análise de IA associada acrescentam digitalizações, dados derivados, processamento de CPU/GPU, cache, espaço temporário e agendamento em segundo plano, para...
Como integrar o Jellyfin numa rede de um apartamento pequeno ou arrendado
Crie uma rede Jellyfin adequada para arrendamento, com endereçamento local estável, cablagem mínima, hardware silencioso, acesso remoto compatível com CGNAT e alterações reversíveis.
Quantos utilizadores e tarefas em segundo plano deverá suportar um único servidor Jellyfin?
Trate os utilizadores do Jellyfin e as tarefas em segundo plano como uma única capacidade de carga partilhada; a capacidade esgota-se quando a latência...
