Jellyfin werkt via wifi, maar niet via ethernet of VPN

Als Jellyfin via wifi werkt maar via Ethernet of een VPN niet, is de server meestal in orde; het pad ernaartoe is veranderd. De meest voorkomende oorzaken zijn een ander IP-adres/subnet of DNS-antwoord, een route die de verkeerde interface verkiest, firewall-/lokale-netwerkregels die de verbinding anders classificeren, of een VPN-route die overlapt met het LAN.

Gebruik één bekende, goed werkende Jellyfin-URL en test vanaf de getroffen client in lagen. Controleer eerst het bestemmings-IP en de poort, vergelijk daarna de routes en controleer vervolgens de firewall en de lokale netwerken van Jellyfin. Bekijk pas daarna VPN-specifiek subnet- of exit-nodegedrag. Installeer Jellyfin niet opnieuw zolang dezelfde server via een andere interface bereikbaar is, want dat bewijs wijst al op een netwerkprobleem en niet op de applicatiestatus.

Vergelijk het bestemmingsadres via wifi en Ethernet

Noteer bij de werkende wifi-verbinding de Jellyfin-hostnaam, het opgeloste IP-adres, het subnet van de client en de poort. Schakel over naar Ethernet en herhaal dezelfde controles. Als de hostnaam naar een ander of onbereikbaar adres verwijst, los dan eerst DNS of de clientroute op voordat je de Jellyfin-instellingen aanpast.

De netwerkdocumentatie van Jellyfin legt uit dat normale toegang het host-IP-adres en de geconfigureerde HTTP(S)-poort gebruikt, terwijl lokale detectie beperkt is tot het lokale subnet. Bekijk het gedrag van het lokale netwerk wanneer een bekabelde client zich op een andere VLAN of een ander subnet bevindt dan het wifi-netwerk.

Test het IP-adres van de server rechtstreeks via Ethernet. Als het IP-adres werkt maar de hostnaam niet, ligt het probleem bij DNS. Als geen van beide werkt, ga dan verder met route- en firewallcontroles. Als de TCP-poort verbinding maakt maar de app zich anders gedraagt, controleer dan de lokale/externe classificatie van Jellyfin.

Controleer welke interface en route de client daadwerkelijk gebruikt

Een apparaat met wifi-, Ethernet- en VPN-adapters kan meerdere routes tegelijk hebben. Wanneer Ethernet wordt verbonden, kiest het besturingssysteem mogelijk een nieuwe standaardroute of een specifiekere subnetroute, waardoor Jellyfin-verkeer ergens anders naartoe wordt gestuurd dan via het werkende wifi-pad.

Bekijk de route naar het IP-adres van de Jellyfin-server met de routeringshulpmiddelen van je besturingssysteem en vergelijk die met de werkende situatie. Schakel tijdelijk slechts één interface uit om de oorzaak te bevestigen en schakel deze daarna weer in. Verwijder routes niet permanent voordat je weet welke regel onjuist is.

Als de route naar de juiste Ethernetgateway wijst en de server via ping bereikbaar is, maar de Jellyfin-poort niet werkt, is de volgende test gericht op de firewall of de servicebinding en niet op DNS.

Controleer firewallregels en de lokale netwerken van Jellyfin

Vergelijk het firewallbeleid voor het Ethernetsubnet, VPN-subnet en wifi-subnet. Thuisrouters en beheerde switches passen vaak verschillende VLAN- of gastnetwerkregels toe, ook als alle drie de verbindingen zich fysiek binnen hetzelfde huis bevinden.

Controleer in Jellyfin de CIDR-waarden van Lokale netwerken en het beleid voor externe toegang. Een client die vanuit een niet-vermeld subnet verbinding maakt, kan als extern worden behandeld. Daardoor kan voor die gebruiker de toegang anders worden beperkt, ook al luistert de server normaal.

Zie voor een breder voorbeeld van het scheiden van lokaal succes en een fout in het externe pad lokale en externe toegangspaden. Dezelfde werkwijze geldt hier: bewijs elke netwerkhop voordat je de applicatie wijzigt.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Zoek naar overlappende VPN-subnets of exit-nodegedrag

Als het probleem alleen optreedt wanneer een VPN is ingeschakeld, vergelijk dan de VPN-routes met het fysieke LAN. Twee netwerken die hetzelfde privénetwerk gebruiken, kunnen ervoor zorgen dat de client Jellyfin-verkeer de tunnel in stuurt, ook al bevindt de server zich fysiek in de buurt.

Tailscale documenteert situaties waarin subnetroutes, exit-nodes of LAN-toegangsinstellingen ervoor kunnen zorgen dat een client geen lokaal apparaat kan bereiken. Gebruik de probleemoplossing voor LAN-verbindingen als voorbeeld van hoe VPN-routering het pad kan overschrijven dat werkte voordat de tunnel werd ingeschakeld.

Schakel tijdelijk het accepteren van VPN-routes of de exit-node uit en test opnieuw met hetzelfde Jellyfin-IP-adres. Als de toegang onmiddellijk terugkomt, laat de Jellyfin-server dan ongewijzigd en corrigeer in plaats daarvan de VPN-routering of het LAN-toegangsbeleid.

Test het oorspronkelijke clientpad opnieuw na elke netwerkoplossing

Pas zodra je de juiste oorzaak hebt vastgesteld alleen de bijbehorende wijziging toe: corrigeer DNS, pas routemetrieken of -prefixen aan, geef het Ethernet-/VPN-subnet toegang in de firewall, of corrigeer de vermelding bij Lokale netwerken in Jellyfin. Herstel daarna alle normale interfaces en herhaal de oorspronkelijke verbindingsmethode.

Controleer zowel de Jellyfin-webclient als één native client als je huishouden beide gebruikt, omdat detectie, opgeslagen server-URL's en rechtstreekse HTTP-toegang verschillende paden kunnen volgen. Test ook na het opnieuw opstarten of opnieuw verbinden van een client, zodat gecachte routes een tijdelijk succes niet permanent laten lijken.

Onderzoek het verder alleen als het bestemmings-IP, de route, de firewall en de classificatie bij Lokale netwerken allemaal correct zijn, maar dezelfde interface nog steeds niet werkt. Leg de werkende en falende routetabellen, client-IP-adressen en serverlogboeken van één poging vast. Die informatie is veel nuttiger dan Jellyfin opnieuw installeren of alle netwerkinstellingen tegelijk resetten.