프록시 또는 DNS 변경 후 Jellyfin 세션이 손실되는 이유는 무엇인가요?

프록시 또는 DNS를 변경했다고 해서 모든 Jellyfin 로그인이 자동으로 무효화되지는 않습니다. 세션 손실은 일반적으로 변경으로 인해 기존 로그인 상태가 기대하는 호스트 이름, 스킴, 경로, 백엔드 서버 식별자, 인증 계층 또는 클라이언트 경로까지 함께 달라질 때 발생합니다.

먼저 단순한 DNS 레코드 업데이트인지 오리진 변경인지 구분하세요. 하나의 계정과 기기를 고정한 상태에서 일반적인 공개 호스트 이름으로 직접 LAN에 접속한 경우를 비교하고, 클라이언트 데이터를 삭제하기 전에 처음 실패한 요청을 기록하세요. 목표는 증상이 사라질 때까지 사용자를 초기화하는 것이 아니라 어떤 경계가 변경되었는지 파악하는 것입니다.

먼저 공개 오리진이 실제로 변경되었는지 확인하세요

이전과 현재의 스킴, 호스트 이름, 포트, 기본 경로, 프록시 경로를 기록하세요. DNS A 또는 AAAA 레코드는 브라우저 오리진을 변경하지 않고도 동일한 호스트 이름을 다른 주소로 연결할 수 있지만, 호스트 이름을 변경하거나 애플리케이션 기본 경로를 바꾸면 서로 다른 클라이언트 경계가 생성됩니다. 사용자 지정 도메인으로 이전할 때는 애플리케이션과 인증 경로가 새 도메인에 맞아야 합니다. 사용자 지정 도메인 이전 체크리스트에서는 이러한 DNS와 애플리케이션 간의 결합을 명확히 설명합니다.

인증 상태는 인증 상태가 제공되는 위치에 민감합니다. 유용한 세션 쿠키 범위 체크리스트는 각 인증 메커니즘에 연결된 도메인과 경로를 매핑하는 것부터 시작합니다. Jellyfin 클라이언트는 모두 동일한 방식으로 상태를 저장하지 않으므로 브라우저 동작이 모든 앱을 대표한다고 가정하지 말고 영향을 받은 클라이언트에서 테스트하세요.

이전 호스트 이름은 계속 작동하지만 새 호스트 이름에서 로그인을 요구한다면, 달리 입증되기 전까지는 이를 예상된 오리진 이전으로 간주하세요. 동일한 호스트 이름에서 프록시 변경 후에만 모든 사용자가 로그아웃된다면 호스트 이름은 유지하고 업스트림 식별자, 헤더, 프록시 측 인증을 점검하세요.

DNS가 여전히 의도한 동일한 Jellyfin 인스턴스로 연결되는지 확인하세요

LAN 클라이언트에서 호스트 이름을 확인하고, 원격 접속이 중요하다면 외부 리졸버에서도 확인하세요. 반환된 주소가 의도한 리버스 프록시에 도달하는지, 프록시가 이전 컨테이너나 테스트 인스턴스, 복원된 복제본 또는 영구 데이터베이스가 다른 두 번째 서버가 아니라 예상한 Jellyfin 서비스로 라우팅하는지 확인하세요.

DNS 전환은 실제로는 다른 백엔드로 클라이언트를 보내고 있는데 세션 문제처럼 보일 수 있습니다. 인증을 건드리기 전에 서버 식별 응답, 사용자 목록 동작, 라이브러리 상태, 프록시 업스트림 대상을 비교하세요. 새 경로가 새로 생성되었거나 복원된 Jellyfin 인스턴스로 연결된다면 기존 클라이언트 자격 증명이 더 이상 해당 인스턴스에서 유효한 세션을 나타내지 않을 수 있습니다.

프록시와 세션 상태 수명 주기를 분리해 유지하는 관련 ZimaSpace 워크플로가 여기서 유용합니다. 인그레스 재시작으로 애플리케이션 식별자나 기존 세션을 검증하는 상태가 조용히 교체되어서는 안 됩니다.

전달된 호스트, 스킴, 경로 및 프록시 인증을 비교하세요

변경 후 적용된 프록시 구성을 캡처하세요. 공개 Host 값, 전달된 스킴, 클라이언트 주소, 웹소켓 업그레이드 경로, 리디렉션, 인증 미들웨어를 마지막으로 작동했던 설정과 비교하세요. HTTPS에서 예상치 못한 HTTP 또는 다른 호스트 URL로 리디렉션되면 유효한 로그인이 사라진 것처럼 보일 수 있습니다.

Jellyfin 앞에 다른 인증 계층이 있다면 프록시 교체 과정에서도 해당 계층의 서명 키, 쿠키 이름, 쿠키 도메인, 세션 저장소를 안정적으로 유지하세요. 로드 밸런서 설계에서는 고정 세션 및 라우팅 상태를 사용해 요청이 의도한 백엔드에 계속 연결되도록 합니다. 이 계층을 변경하면 Jellyfin 자체는 정상이어도 로그아웃이나 로그인 루프가 발생할 수 있습니다.

관련 없는 프록시 예제의 헤더를 무작정 복사하지 마세요. 실패한 요청이나 리디렉션을 통해 현재 값이 잘못되었다는 사실이 확인될 때만 한 번에 하나의 값을 변경하세요. 가장 안전한 프록시 구성은 공개 오리진을 유지하고 올바른 백엔드에 일관되게 연결하는 데 필요한 최소한의 구성입니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

기존 증거를 삭제하지 않고 클린 클라이언트 테스트를 수행하세요

무언가를 삭제하기 전에 실패 시간, 브라우저 또는 앱 버전, 요청 상태, 리디렉션 체인, 프록시 로그 줄, Jellyfin 로그 항목을 저장하세요. 그런 다음 비공개 브라우저 창이나 두 번째 테스트 기기를 사용해 새 경로로 로그인하세요. 새 로그인이 성공했다는 것은 연결 가능성을 입증할 뿐이며, 기존 상태를 사용할 수 없게 된 이유를 설명해 주지는 않습니다.

다음 세 경로를 순서대로 비교하세요. 직접 LAN Jellyfin 주소, LAN에서 일반 호스트 이름, LAN 외부에서 일반 호스트 이름입니다. 직접 접속은 작동하지만 호스트 이름이 실패한다면 사용자와 데이터베이스 상태는 그대로 두고 DNS, TLS, 프록시 또는 미들웨어를 조사하세요. 모든 경로에서 동일한 정상 계정이 거부된다면 문제는 다시 Jellyfin 내부 또는 영구 상태로 범위가 좁혀집니다.

요청 경로에 대한 증거를 확보한 뒤에만 영향을 받은 클라이언트의 사이트별 상태를 삭제하세요. 모든 등록 기기를 삭제하거나 모든 세션을 철회하는 것을 첫 단계로 삼지 마세요. 그렇게 하면 라우팅 이전과 서버 측 인증 실패를 구분할 수 있는 비교 자료가 사라집니다.

DNS 만료, 프록시 재시작 및 재부팅을 통해 변경 사항을 검증하세요

일치하는 수정 사항을 적용한 후 이전 DNS TTL 시간이 만료될 때까지 기다리고, 프록시만 재시작한 다음 Jellyfin 서비스를 재시작하고 마지막으로 호스트를 재부팅하세요. 각 이벤트 후 동일한 호스트 이름으로 로그인, 로그아웃, 재생 시작, 탐색, 재연결 테스트를 반복하세요.

안정적인 결과란 호스트 이름이 계속 의도한 프록시로 확인되고, 프록시가 의도한 Jellyfin 인스턴스에 다시 연결되며, 정상적인 구성 요소 재시작 후 기존 세션이 유지되어야 할 때 유지되고, 새 로그인도 계속 유효한 상태를 의미합니다. 전체 스택 부팅 중에만 문제가 나타난다면 프록시에서 업스트림으로 이어지는 복구 경로를 사용해 준비 상태 문제와 인증 문제를 구분하세요.

최종 호스트 이름, 프록시 업스트림 이름, 기본 경로, 인증서 출처, 프록시 측 세션 비밀 키를 배포 문서에 기록하세요. 이후 DNS 또는 프록시 변경을 브라우저 증상에서 다시 추측하지 않고 알려진 식별자 계약을 기준으로 테스트할 수 있습니다.

FAQ

DNS 레코드만 변경해도 Jellyfin 세션이 무효화되나요?

일반적으로 동일한 호스트 이름, 스킴, 경로 및 Jellyfin 인스턴스를 계속 사용하는 경우에는 그렇지 않습니다. DNS 변경은 클라이언트를 다른 백엔드로 보내거나, 공개 오리진을 변경하거나, TLS 또는 리디렉션을 변경하거나, Jellyfin 앞의 인증 계층을 변경할 때 세션에 영향을 줍니다.

프록시를 변경한 후 모든 Jellyfin 세션을 철회해야 하나요?

첫 번째 복구 단계로는 권장하지 않습니다. 실패하는 클라이언트 하나를 증거로 보존하고, 새 경로가 의도한 서버에 연결되는지 확인한 다음, 새 로그인을 별도로 테스트하세요. 자격 증명을 의도적으로 교체했거나 토큰 노출이 의심되거나 기존 클라이언트 상태를 더 이상 신뢰해서는 안 된다는 사실이 확인된 경우에만 세션을 철회하세요.