새 네트워크로 이동한 후 Jellyfin 설정을 재구성하는 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How to Rebuild a Jellyfin Setup After Moving to a New Network - Zima Store Online

네트워크를 변경한 후 Jellyfin을 다시 구축하려면 먼저 로컬 서비스 경로를 복원한 다음, 스토리지 마운트, ID, DNS, 원격 액세스를 별도의 단계로 검증하세요.

새 라우터, 서브넷, VLAN 또는 DNS 도메인으로 인해 정상적인 Jellyfin 데이터베이스가 고장 난 것처럼 보일 수 있습니다. 클라이언트, 마운트, 리버스 프록시가 더 이상 동일한 경로를 공유하지 않기 때문입니다. 기존 네트워크 기록과 애플리케이션 데이터 사본을 보관하세요. 목표는 클라이언트에서 서비스와 미디어까지 이어지는 경로를 명확히 확인하고, Jellyfin이 아니라 네트워크 계층 자체가 문제일 때 중단할 기준을 마련하는 것입니다.

변경하기 전에 기존 경로를 기록하세요

서버 주소, 호스트 이름, 서브넷, 게이트웨이, DNS 이름, 마운트된 미디어 경로, 리버스 프록시 대상, 인증서 이름, 방화벽 또는 포트 포워딩 규칙을 기록하세요. 로컬 스트리밍과 원격 스트리밍을 분리해서 정리하세요. 기존 호스트에 아직 접근할 수 있다면 새 주소를 할당하기 전에 Jellyfin 구성을 내보내고 사용자와 라이브러리 목록을 작성하세요.

이렇게 하면 재구축을 위한 기준선이 만들어집니다. 사용자가 서비스에 접근하고, 서비스가 데이터베이스와 미디어에 접근하며, 백업이 대상 위치에 도달해야 합니다. 공용 포트나 새 프록시 규칙부터 시작하지 마세요.

안정적인 주소에서 로컬 서비스를 복원하세요

서버에 DHCP 예약 또는 고정 주소를 설정한 다음, 동일한 LAN에서 Jellyfin 웹 인터페이스가 열리는지 확인하세요. 서비스 바인딩 주소와 호스트 방화벽을 점검하고, DNS를 변경하기 전에 로컬 클라이언트로 테스트하세요. 앱은 시작되지만 라이브러리가 비어 있다면 데이터베이스를 다시 구축하지 말고 중단한 뒤 스토리지 경로를 확인하세요.

Jellyfin의 마이그레이션 지침은 내부 데이터가 경로에 민감하며 컨테이너 경로가 기록된 미디어 위치와 일치해야 한다고 강조합니다(경로에 민감한 마이그레이션 지침). 경로 불일치는 메타데이터 문제가 아니라 토폴로지 문제로 처리하세요.

DNS보다 먼저 마운트와 권한을 다시 연결하세요

미디어 및 백업 볼륨을 안정적인 경로에 마운트한 다음 Jellyfin 서비스 계정으로 읽기 권한을 테스트하세요. 각 라이브러리에서 파일 하나를 읽고 애플리케이션 데이터 디렉터리에 파일 하나를 쓰는지 확인하세요. 캐시와 다운로드한 아트워크는 재구축 가능한 스토리지에 보관하고, 사용자 미디어, 데이터베이스, 백업은 보호된 역할의 스토리지에 유지하세요.

재시작 후 Jellyfin이 시작되기 전에 마운트가 다시 생성되고 라이브러리 스캔에서 파일 누락 경고가 발생하지 않으면 PASS입니다. 마운트가 대화형 로그인에 의존한다면 계속 진행하기 전에 부팅 순서를 수정하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

ID, DNS, 원격 액세스를 순서대로 다시 구축하세요

로컬 재생이 정상적으로 작동한 후 호스트 이름과 내부 DNS 레코드를 복원하세요. IP가 아닌 이름을 사용해 클라이언트를 테스트한 다음, 외부에서 리버스 프록시 또는 VPN을 검증하세요. 인증과 권한 부여를 라우팅과 분리해서 확인하세요. 로그인 실패는 새 포트 포워딩이 잘못되었다는 증거가 아닙니다.

실제 클라이언트 구성에서 직접 재생 하나와 트랜스코딩 하나를 실행하세요. 확인된 엔드포인트, 재생 모드, 실패 지점을 기록하세요. 커뮤니티의 마이그레이션 사례는 경로와 네트워크 가정을 비교하는 데 유용하지만, 해당 하드웨어나 라우터 설정을 일반화하지 마세요(마이그레이션 사례 연구).

롤백과 확장 계획을 명확히 유지하세요

로컬 재생, 사용자 액세스, 원격 라우팅, 복원이 모두 통과할 때까지 기존 DNS 레코드, 구성 백업, 이전 네트워크 기록을 보관하세요. 공유 경로의 성능이 저하될 때만 관리용 별도 VLAN이나 두 번째 네트워크 인터페이스처럼 전용 경로를 추가해 확장하세요. 서버가 안정적인 주소, 영구 마운트 또는 테스트된 복구 경로를 확보하지 못한다면 재구축을 중단하세요. 이러한 기반이 없으면 클라이언트 구성을 아무리 변경해도 문제를 해결할 수 없습니다.