Jellyfin funktioniert über WLAN, aber nicht über Ethernet oder VPN

Wenn Jellyfin über WLAN funktioniert, aber über Ethernet oder ein VPN ausfällt, ist der Server in der Regel intakt; der Pfad dorthin hat sich geändert. Die häufigsten Ursachen sind eine andere IP-Adresse, ein anderes Subnetz oder eine andere DNS-Antwort, eine Route, die die falsche Schnittstelle bevorzugt, Firewall- bzw. lokale Netzwerkregeln, die die Verbindung anders einstufen, oder eine VPN-Route, die sich mit dem LAN überschneidet.

Verwende eine bekannte, funktionierende Jellyfin-URL und teste sie vom betroffenen Client aus schrittweise. Überprüfe zuerst Ziel-IP-Adresse und Port, vergleiche anschließend die Routen und prüfe danach Firewall und Jellyfin-Einstellung für lokale Netzwerke. Erst danach solltest du VPN-spezifische Subnetz- oder Exit-Node-Einstellungen untersuchen. Installiere Jellyfin nicht neu, solange derselbe Server über eine andere Schnittstelle erreichbar ist, denn das weist bereits auf ein Netzwerkproblem und nicht auf den Anwendungsstatus hin.

Vergleiche die Zieladresse über WLAN und Ethernet

Notiere bei der funktionierenden WLAN-Verbindung den Jellyfin-Hostnamen, die aufgelöste IP-Adresse, das Client-Subnetz und den Port. Wechsle zu Ethernet und wiederhole dieselben Prüfungen. Wenn der Hostname in eine andere oder nicht erreichbare Adresse aufgelöst wird, behebe zuerst DNS oder die Client-Route, bevor du Jellyfin-Einstellungen änderst.

Die Jellyfin-Netzwerkdokumentation erklärt, dass der normale Zugriff die Host-IP-Adresse und den konfigurierten HTTP(S)-Port verwendet, während die lokale Erkennung auf das lokale Subnetz beschränkt ist. Sieh dir das Verhalten im lokalen Netzwerk an, wenn sich ein kabelgebundener Client in einem anderen VLAN oder Subnetz als das WLAN-Netzwerk befindet.

Teste die Server-IP direkt über Ethernet. Wenn die IP-Adresse funktioniert, der Hostname aber nicht, liegt die Ursache bei DNS. Wenn beides nicht funktioniert, fahre mit der Prüfung von Route und Firewall fort. Wenn die TCP-Verbindung zum Port hergestellt wird, sich die App aber anders verhält, untersuche Jellyfins Einstufung als lokal oder entfernt.

Prüfe, welche Schnittstelle und Route der Client tatsächlich verwendet

Ein Gerät mit WLAN-, Ethernet- und VPN-Adaptern kann mehrere Routen gleichzeitig verwenden. Sobald Ethernet verbunden ist, bevorzugt das Betriebssystem möglicherweise eine neue Standardroute oder eine spezifischere Subnetzroute, die den Jellyfin-Datenverkehr über einen anderen Pfad als die funktionierende WLAN-Verbindung leitet.

Untersuche die Route zur IP-Adresse des Jellyfin-Servers mit den Routing-Werkzeugen deines Betriebssystems und vergleiche sie mit dem funktionierenden Zustand. Deaktiviere vorübergehend nur eine Schnittstelle, um die Ursache einzugrenzen, und aktiviere sie anschließend wieder. Lösche Routen nicht dauerhaft, bevor du weißt, welche Regel falsch ist.

Wenn die Route auf das korrekte Ethernet-Gateway zeigt und der Server per Ping erreichbar ist, der Jellyfin-Port aber fehlschlägt, ist die nächste Prüfung die Firewall oder die Dienstbindung und nicht DNS.

Überprüfe Firewallregeln und Jellyfins lokale Netzwerke

Vergleiche die Firewallrichtlinien für Ethernet-, VPN- und WLAN-Subnetz. Heimrouter und verwaltete Switches wenden häufig unterschiedliche VLAN- oder Gastnetzregeln an, selbst wenn sich alle drei Verbindungen physisch im selben Zuhause befinden.

Prüfe in Jellyfin die CIDR-Werte unter „Lokale Netzwerke“ sowie die Richtlinie für den Fernzugriff. Ein Client aus einem nicht aufgeführten Subnetz kann als entfernt behandelt werden. Dadurch kann sich ändern, ob der Zugriff für den betreffenden Benutzer erlaubt ist, obwohl der Server weiterhin normal lauscht.

Ein umfassenderes Beispiel für die Trennung zwischen lokalem Erfolg und einem fehlerhaften Fernzugriffspfad findest du unter lokalen und entfernten Zugriffspfaden. Dieselbe Vorgehensweise gilt auch hier: Überprüfe jeden Netzwerkabschnitt, bevor du die Anwendung änderst.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Achte auf überlappende VPN-Subnetze oder das Verhalten von Exit-Nodes

Wenn der Fehler nur bei aktiviertem VPN auftritt, vergleiche die VPN-Routen mit dem physischen LAN. Zwei Netzwerke mit demselben privaten Subnetz können dazu führen, dass der Client Jellyfin-Datenverkehr durch den Tunnel sendet, obwohl sich der Server physisch in der Nähe befindet.

Tailscale dokumentiert Fälle, in denen Subnetzrouten, Exit-Nodes oder LAN-Zugriffseinstellungen verhindern können, dass ein Client ein lokales Gerät erreicht. Nutze die Fehlerbehebung bei der LAN-Konnektivität als Beispiel dafür, wie VPN-Routing den Pfad überschreiben kann, der vor der Aktivierung des Tunnels funktioniert hat.

Deaktiviere vorübergehend die Annahme von VPN-Routen oder den Exit-Node und teste dieselbe Jellyfin-IP erneut. Wenn der Zugriff sofort wieder funktioniert, lass den Jellyfin-Server unverändert und korrigiere stattdessen das VPN-Routing oder die LAN-Zugriffsrichtlinie.

Teste den ursprünglichen Clientpfad nach jeder Netzwerkänderung erneut

Sobald du die Ursache eingegrenzt hast, nimm nur die passende Änderung vor: Korrigiere DNS, passe Routenmetriken oder Präfixe an, erlaube das Ethernet- bzw. VPN-Subnetz in der Firewall oder korrigiere den Eintrag unter Jellyfins lokalen Netzwerken. Aktiviere anschließend alle normalen Schnittstellen wieder und wiederhole die ursprüngliche Verbindungsmethode.

Prüfe sowohl den Jellyfin-Webclient als auch einen nativen Client, falls in deinem Haushalt beide verwendet werden, denn Erkennung, gespeicherte Server-URLs und direkter HTTP-Zugriff können unterschiedliche Pfade nutzen. Teste außerdem nach einem Neustart oder einer erneuten Verbindung des Clients, damit zwischengespeicherte Routen einen vorübergehenden Erfolg nicht dauerhaft erscheinen lassen.

Untersuche weitere Ursachen nur, wenn Ziel-IP-Adresse, Route, Firewall und die Einstufung unter „Lokale Netzwerke“ korrekt sind, die Verbindung über dieselbe Schnittstelle aber weiterhin fehlschlägt. Sichere die funktionierenden und fehlerhaften Routingtabellen, die Client-IP-Adressen und die Serverprotokolle eines Verbindungsversuchs. Diese Informationen sind weitaus hilfreicher, als Jellyfin neu zu installieren oder alle Netzwerkeinstellungen gleichzeitig zurückzusetzen.