Jellyfin fungerar via Wi-Fi men inte via Ethernet eller VPN

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

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

Om Jellyfin fungerar via Wi-Fi men inte via Ethernet eller VPN är servern vanligtvis felfri; det är vägen till den som har ändrats. De vanligaste orsakerna är en annan IP-adress eller ett annat subnät eller DNS-svar, en rutt som föredrar fel gränssnitt, brandväggsregler eller regler för lokala nätverk som klassificerar anslutningen annorlunda, eller en VPN-rutt som överlappar det lokala nätverket.

Använd en känd fungerande Jellyfin-URL och testa från den berörda klienten i flera lager. Kontrollera först mål-IP och port, jämför sedan rutter och kontrollera därefter brandvägg och Jellyfins lokala nätverk. Granska VPN-specifika subnät eller exit-nod-beteende först efter det. Installera inte om Jellyfin medan samma server kan nås via ett annat gränssnitt, eftersom det redan visar att problemet ligger i nätverket och inte i applikationens tillstånd.

Jämför måladressen via Wi-Fi och Ethernet

Anteckna Jellyfin-värdnamnet, den upplösta IP-adressen, klientens subnät och porten när Wi-Fi-anslutningen fungerar. Byt till Ethernet och upprepa samma kontroller. Om värdnamnet pekar på en annan eller onåbar adress åtgärdar du DNS eller klientens rutt innan du ändrar Jellyfins inställningar.

Jellyfins nätverksdokumentation förklarar att normal åtkomst använder värdens IP-adress och den konfigurerade HTTP(S)-porten, medan lokal upptäckt är begränsad till det lokala subnätet. Läs om lokalt nätverksbeteende när en trådbunden klient finns på ett annat VLAN eller subnät än Wi-Fi-nätverket.

Testa serverns IP-adress direkt från Ethernet. Om IP-adressen fungerar men värdnamnet inte gör det ligger problemet i DNS. Om inget av dem fungerar fortsätter du med kontroller av rutter och brandvägg. Om TCP-porten ansluter men appen beter sig annorlunda granskar du Jellyfins klassificering av lokala och fjärranslutna klienter.

Kontrollera vilket gränssnitt och vilken rutt klienten faktiskt använder

En dator med Wi-Fi-, Ethernet- och VPN-adaptrar kan ha flera rutter samtidigt. När Ethernet ansluts kan operativsystemet föredra en ny standardrutt eller en mer specifik subnätsrutt som skickar Jellyfin-trafiken någon annanstans än den fungerande Wi-Fi-vägen.

Kontrollera rutten till Jellyfin-serverns IP-adress med operativsystemets routingverktyg och jämför den med det fungerande läget. Inaktivera tillfälligt endast ett gränssnitt för att bekräfta orsaken och aktivera det sedan igen. Ta inte bort rutter permanent innan du vet vilken regel som är fel.

Om rutten pekar på rätt Ethernet-gateway och servern kan nås med ping men Jellyfin-porten inte fungerar, är nästa test brandväggen eller tjänstens bindning snarare än DNS.

Verifiera brandväggsregler och Jellyfins lokala nätverk

Jämför brandväggspolicyn för Ethernet-subnätet, VPN-subnätet och Wi-Fi-subnätet. Hemroutrar och hanterade switchar tillämpar ofta olika VLAN- eller gästnätverksregler även när alla tre anslutningarna fysiskt finns i samma hem.

Granska värdena för CIDR i Local Networks och policyn för fjärråtkomst i Jellyfin. En klient från ett subnät som inte finns med i listan kan behandlas som fjärransluten, vilket kan ändra om användaren får åtkomst trots att servern normalt lyssnar.

För ett bredare exempel på hur man skiljer lokal åtkomst från fel på fjärrvägen, se lokala kontra fjärranslutna åtkomstvägar. Samma metod gäller här: verifiera varje nätverkshopp innan du ändrar applikationen.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Leta efter överlappande VPN-subnät eller exit-nod-beteende

När felet endast uppstår med aktiv VPN jämför du VPN-rutterna med det fysiska lokala nätverket. Två nätverk som använder samma privata subnät kan få klienten att skicka Jellyfin-trafiken genom tunneln trots att servern fysiskt finns i närheten.

Tailscale dokumenterar fall där subnätsrutter, exit-noder eller inställningar för åtkomst till det lokala nätverket kan hindra en klient från att nå en lokal enhet. Använd deras felsökning av LAN-anslutning som exempel på hur VPN-routing kan åsidosätta vägen som fungerade innan tunneln aktiverades.

Inaktivera tillfälligt godkännande av VPN-rutter eller exit-noden och testa samma Jellyfin-IP igen. Om åtkomsten omedelbart återkommer låter du Jellyfin-servern vara oförändrad och korrigerar i stället VPN-routingen eller policyn för åtkomst till det lokala nätverket.

Testa den ursprungliga klientvägen igen efter varje nätverksåtgärd

När du har identifierat orsaken tillämpar du endast den matchande ändringen: korrigera DNS, justera ruttmått eller prefix, tillåt Ethernet- eller VPN-subnätet i brandväggen eller korrigera posten för Jellyfins lokala nätverk. Återställ sedan alla normala gränssnitt och upprepa den ursprungliga anslutningsmetoden.

Verifiera både Jellyfins webbklient och en inbyggd klient om hushållet använder båda, eftersom upptäckt, sparade server-URL:er och direkt HTTP-åtkomst kan följa olika vägar. Testa även efter en omstart eller återanslutning av klienten så att cachade rutter inte får en tillfällig framgång att verka permanent.

Gå vidare till nästa supportnivå först om mål-IP, rutt, brandvägg och klassificering i Local Networks är korrekta men samma gränssnitt fortfarande inte fungerar. Spara de fungerande och felande routingtabellerna, klienternas IP-adresser och serverloggar från ett försök. Den informationen är mycket mer användbar än att installera om Jellyfin eller återställa alla nätverksinställningar på en gång.