Jellyfin działa przez Wi-Fi, ale nie działa przez Ethernet ani VPN

Jeśli Jellyfin działa przez Wi‑Fi, ale nie działa przez Ethernet lub VPN, serwer zwykle jest sprawny — zmieniła się ścieżka dostępu do niego. Najczęstsze przyczyny to inny adres IP/podsieć lub odpowiedź DNS, trasa preferująca niewłaściwy interfejs, reguły zapory sieciowej lub sieci lokalnej, które odmiennie klasyfikują połączenie, albo trasa VPN nakładająca się na sieć LAN.

Użyj jednego sprawdzonego adresu URL Jellyfin i przetestuj go na urządzeniu, którego dotyczy problem, warstwami. Najpierw potwierdź docelowy adres IP i port, następnie porównaj trasy, potem sprawdź zaporę sieciową i ustawienie Local Networks w Jellyfin, a dopiero na końcu przeanalizuj specyficzne dla VPN ustawienia podsieci lub węzła wyjściowego. Nie instaluj ponownie Jellyfin, jeśli ten sam serwer jest dostępny przez inny interfejs, ponieważ wskazuje to na problem z siecią, a nie ze stanem aplikacji.

Porównaj adres docelowy przez Wi‑Fi i Ethernet

Na działającym połączeniu Wi‑Fi zapisz nazwę hosta Jellyfin, rozpoznany adres IP, podsieć klienta i port. Przełącz się na Ethernet i powtórz te same czynności. Jeśli nazwa hosta wskazuje inny lub niedostępny adres, napraw DNS albo trasę klienta, zanim zmienisz ustawienia Jellyfin.

Dokumentacja sieciowa Jellyfin wyjaśnia, że standardowy dostęp korzysta z adresu IP hosta i skonfigurowanego portu HTTP(S), a wykrywanie lokalne jest ograniczone do lokalnej podsieci. Zapoznaj się z informacjami o działaniu sieci lokalnej, gdy klient przewodowy znajduje się w innej sieci VLAN lub podsieci niż sieć Wi‑Fi.

Przetestuj bezpośrednio adres IP serwera przez Ethernet. Jeśli adres IP działa, ale nazwa hosta nie, problem dotyczy DNS. Jeśli nie działa żadne z nich, przejdź do sprawdzania trasy i zapory; jeśli port TCP nawiązuje połączenie, ale aplikacja zachowuje się inaczej, sprawdź klasyfikację lokalną/zdalną w Jellyfin.

Sprawdź, którego interfejsu i trasy klient faktycznie używa

Urządzenie wyposażone w Wi‑Fi, Ethernet i adaptery VPN może jednocześnie mieć kilka tras. Po podłączeniu Ethernetu system operacyjny może preferować nową trasę domyślną lub bardziej szczegółową trasę podsieci, kierującą ruch Jellyfin inną drogą niż działająca ścieżka Wi‑Fi.

Sprawdź trasę do adresu IP serwera Jellyfin za pomocą narzędzi routingu systemu operacyjnego i porównaj ją ze stanem działającym. Tymczasowo wyłącz tylko jeden interfejs, aby potwierdzić przyczynę, a następnie włącz go ponownie; nie usuwaj trwale tras, dopóki nie ustalisz, która reguła jest błędna.

Jeśli trasa wskazuje właściwą bramę Ethernet, serwer odpowiada na ping, ale port Jellyfin nie działa, kolejnym krokiem powinno być sprawdzenie zapory lub powiązania usługi, a nie DNS.

Zweryfikuj reguły zapory sieciowej i ustawienie Local Networks w Jellyfin

Porównaj zasady zapory dla podsieci Ethernet, podsieci VPN i podsieci Wi‑Fi. Routery domowe i zarządzane przełączniki często stosują różne reguły dla sieci VLAN lub gościnnych, nawet jeśli wszystkie trzy połączenia fizycznie znajdują się w tym samym domu.

W Jellyfin sprawdź wartości CIDR w sekcji Local Networks oraz zasady zdalnego dostępu. Klient łączący się z nieumieszczonej na liście podsieci może zostać uznany za zdalny, co może zmienić dostępność usługi dla danego użytkownika, mimo że serwer normalnie nasłuchuje.

Szerszy przykład rozdzielenia lokalnego sukcesu od problemu ze ścieżką zdalną znajdziesz w artykule lokalne a zdalne ścieżki dostępu. Ta sama zasada obowiązuje tutaj: sprawdź każdy etap połączenia, zanim zmienisz aplikację.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Poszukaj nakładania się podsieci VPN lub działania węzła wyjściowego

Gdy problem występuje tylko przy włączonym VPN, porównaj trasy VPN z fizyczną siecią LAN. Dwie sieci korzystające z tej samej prywatnej podsieci mogą spowodować, że klient skieruje ruch Jellyfin do tunelu, mimo że serwer znajduje się fizycznie w pobliżu.

Dokumentacja Tailscale opisuje sytuacje, w których trasy podsieci, węzły wyjściowe lub ustawienia dostępu do sieci LAN mogą uniemożliwić klientowi połączenie z urządzeniem lokalnym. Skorzystaj z sekcji rozwiązywania problemów z łącznością LAN, aby zobaczyć, jak routing VPN może zmienić ścieżkę działającą przed włączeniem tunelu.

Tymczasowo wyłącz akceptowanie tras VPN lub węzeł wyjściowy i ponownie przetestuj ten sam adres IP Jellyfin. Jeśli dostęp natychmiast powróci, pozostaw serwer Jellyfin bez zmian i skoryguj routing VPN lub zasady dostępu do sieci LAN.

Ponownie przetestuj pierwotną ścieżkę klienta po każdej poprawce sieciowej

Po ustaleniu przyczyny wprowadź tylko odpowiednią zmianę: popraw DNS, dostosuj metryki tras lub prefiksy, zezwól na ruch z podsieci Ethernet/VPN w zaporze albo popraw wpis Local Networks w Jellyfin. Następnie przywróć wszystkie normalne interfejsy i powtórz połączenie pierwotną metodą.

Sprawdź zarówno interfejs webowy Jellyfin, jak i jednego klienta natywnego, jeśli w domu korzystasz z obu, ponieważ wykrywanie, zapisane adresy serwerów i bezpośredni dostęp HTTP mogą przebiegać różnymi ścieżkami. Przetestuj także po ponownym uruchomieniu klienta lub ponownym połączeniu, aby zapisane trasy nie sprawiły, że tymczasowy sukces będzie wyglądał na trwały.

Eskaluje problem dopiero wtedy, gdy docelowy adres IP, trasa, zapora i klasyfikacja Local Networks są prawidłowe, a dany interfejs nadal nie działa. Zapisz działające i niedziałające tablice routingu, adresy IP klientów oraz logi serwera z jednej próby; te informacje są znacznie bardziej przydatne niż ponowna instalacja Jellyfin lub jednoczesne resetowanie wszystkich ustawień sieciowych.