Jellyfin은 Wi-Fi에서는 작동하지만 이더넷이나 VPN에서는 작동하지 않습니다

에바 왕

IceWhale author

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

Jellyfin Works on Wi-Fi but Fails on Ethernet or VPN - Zima Store Online

Jellyfin이 Wi-Fi에서는 작동하지만 이더넷이나 VPN을 통해서는 실패한다면, 서버 자체는 대개 정상이며 서버로 연결되는 경로가 바뀐 것입니다. 가장 흔한 원인은 다른 IP/서브넷 또는 DNS 응답, 잘못된 인터페이스를 우선하는 라우팅, 연결을 다르게 분류하는 방화벽/로컬 네트워크 규칙, LAN과 겹치는 VPN 경로입니다.

정상적으로 작동하는 Jellyfin URL 하나를 사용해 문제가 발생하는 클라이언트에서 단계별로 테스트하세요. 먼저 대상 IP와 포트를 확인하고, 그다음 경로를 비교한 뒤, 방화벽과 Jellyfin의 로컬 네트워크를 점검하세요. VPN별 서브넷이나 출구 노드 동작은 그 이후에 확인하면 됩니다. 동일한 서버가 다른 인터페이스를 통해 연결되는 동안에는 Jellyfin을 재설치하지 마세요. 이 증거는 이미 애플리케이션 상태가 아니라 네트워크 문제임을 가리키기 때문입니다.

Wi-Fi와 이더넷에서 대상 주소 비교

정상적으로 작동하는 Wi-Fi 연결에서 Jellyfin 호스트 이름, 확인된 IP 주소, 클라이언트 서브넷, 포트를 기록하세요. 이더넷으로 전환한 뒤 동일한 항목을 다시 확인합니다. 호스트 이름이 다른 주소나 연결할 수 없는 주소로 확인된다면 Jellyfin 설정을 변경하기 전에 DNS 또는 클라이언트 경로를 수정하세요.

Jellyfin의 네트워킹 문서에 따르면 일반적인 액세스에는 호스트 IP와 구성된 HTTP(S) 포트가 사용되며, 로컬 검색은 로컬 서브넷으로 제한됩니다. 유선 클라이언트가 Wi-Fi 네트워크와 다른 VLAN 또는 서브넷에 있다면 로컬 네트워크 동작을 검토하세요.

이더넷에서 서버 IP에 직접 연결해 테스트하세요. IP로는 작동하지만 호스트 이름으로는 실패한다면 원인은 DNS입니다. 둘 다 작동하지 않으면 라우팅과 방화벽을 계속 확인하세요. TCP 포트에는 연결되지만 앱의 동작이 다르다면 Jellyfin의 로컬/원격 분류를 점검하세요.

클라이언트가 실제로 사용하는 인터페이스와 경로 확인

Wi-Fi, 이더넷, VPN 어댑터가 있는 시스템에는 여러 경로가 동시에 존재할 수 있습니다. 이더넷이 연결되면 운영 체제가 새로운 기본 경로나 더 구체적인 서브넷 경로를 우선하여 Jellyfin 트래픽을 Wi-Fi에서 정상적으로 작동하던 경로와 다른 곳으로 보낼 수 있습니다.

운영 체제의 라우팅 도구를 사용해 Jellyfin 서버 IP로 향하는 경로를 확인하고 정상 작동 상태와 비교하세요. 원인을 확인하기 위해 한 번에 하나의 인터페이스만 일시적으로 비활성화한 다음 다시 활성화하세요. 어떤 규칙이 잘못되었는지 알기 전에는 경로를 영구적으로 삭제하지 마세요.

경로가 올바른 이더넷 게이트웨이를 가리키고 서버에 ping으로 연결되지만 Jellyfin 포트가 실패한다면, 다음으로 확인할 것은 DNS가 아니라 방화벽 또는 서비스 바인딩입니다.

방화벽 규칙과 Jellyfin 로컬 네트워크 확인

이더넷 서브넷, VPN 서브넷, Wi-Fi 서브넷에 적용되는 방화벽 정책을 비교하세요. 홈 라우터와 관리형 스위치는 세 연결이 모두 물리적으로 같은 집 안에 있더라도 VLAN 또는 게스트 네트워크 규칙을 서로 다르게 적용하는 경우가 많습니다.

Jellyfin에서 로컬 네트워크 CIDR 값과 원격 액세스 정책을 검토하세요. 허용 목록에 없는 서브넷에서 연결하는 클라이언트는 원격 클라이언트로 처리될 수 있으며, 이로 인해 서버가 정상적으로 수신 대기 중이어도 해당 사용자의 액세스 허용 여부가 달라질 수 있습니다.

로컬에서는 성공하지만 원격 경로에서는 실패하는 상황을 구분하는 더 일반적인 예시는 로컬 액세스 경로와 원격 액세스 경로 비교를 참조하세요. 여기에도 동일한 원칙이 적용됩니다. 애플리케이션을 변경하기 전에 각 네트워크 홉을 확인하세요.

-15% OFF

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

Single board computer zimaboard2

VPN 서브넷 중복 또는 출구 노드 동작 확인

VPN을 활성화했을 때만 문제가 발생한다면 VPN 경로와 실제 LAN을 비교하세요. 동일한 사설 서브넷을 사용하는 두 네트워크가 있으면 서버가 물리적으로 가까이 있어도 클라이언트가 Jellyfin 트래픽을 터널로 보낼 수 있습니다.

Tailscale 문서에는 서브넷 경로, 출구 노드 또는 LAN 액세스 설정으로 인해 클라이언트가 로컬 장치에 연결하지 못하는 경우가 설명되어 있습니다. VPN 라우팅이 터널을 활성화하기 전 정상적으로 작동하던 경로를 어떻게 덮어쓸 수 있는지 보여 주는 예로 LAN 연결 문제 해결을 참고하세요.

VPN 경로 수락 또는 출구 노드를 일시적으로 비활성화한 뒤 동일한 Jellyfin IP로 다시 테스트하세요. 액세스가 즉시 복구된다면 Jellyfin 서버는 변경하지 말고 VPN 라우팅 또는 LAN 액세스 정책을 수정하세요.

각 네트워크 수정 후 원래 클라이언트 경로 재테스트

원인을 파악한 뒤에는 해당 변경만 적용하세요. DNS를 수정하거나, 경로 메트릭 또는 접두사를 조정하거나, 방화벽에서 이더넷/VPN 서브넷을 허용하거나, Jellyfin의 로컬 네트워크 항목을 수정하면 됩니다. 그런 다음 모든 정상 인터페이스를 복원하고 원래 연결 방식을 반복하세요.

가정에서 두 가지를 모두 사용한다면 Jellyfin 웹 클라이언트와 기본 클라이언트 하나를 모두 확인하세요. 검색, 저장된 서버 URL, 직접 HTTP 액세스는 서로 다른 경로를 사용할 수 있기 때문입니다. 또한 클라이언트를 재부팅하거나 다시 연결한 후에도 테스트하여 캐시된 경로로 인해 일시적인 성공이 영구적인 것처럼 보이지 않게 하세요.

대상 IP, 경로, 방화벽, 로컬 네트워크 분류가 모두 올바른데도 동일한 인터페이스에서 계속 실패할 때만 추가 조사를 진행하세요. 한 번의 시도에서 정상 작동하는 경로 테이블과 실패하는 경로 테이블, 클라이언트 IP, 서버 로그를 수집하세요. 이 증거는 Jellyfin을 재설치하거나 모든 네트워크 설정을 한 번에 초기화하는 것보다 훨씬 유용합니다.