Jellyfin fonctionne en Wi-Fi, mais échoue en Ethernet ou via un VPN

Si Jellyfin fonctionne en Wi-Fi mais échoue via Ethernet ou un VPN, le serveur est généralement en bon état ; c’est le chemin d’accès qui a changé. Les causes les plus courantes sont une adresse IP ou un sous-réseau différent, une réponse DNS différente, une route qui privilégie la mauvaise interface, des règles de pare-feu ou de réseau local qui classent la connexion différemment, ou encore une route VPN qui chevauche le réseau local.

Utilisez une URL Jellyfin connue pour fonctionner et effectuez des tests par étapes depuis le client concerné. Commencez par vérifier l’adresse IP et le port de destination, puis comparez les routes, vérifiez le pare-feu et les réseaux locaux de Jellyfin, et examinez seulement ensuite le comportement propre au VPN concernant le sous-réseau ou le nœud de sortie. Ne réinstallez pas Jellyfin tant que le même serveur reste accessible via une autre interface, car cela indique déjà un problème réseau plutôt qu’un problème d’état de l’application.

Comparez l’adresse de destination en Wi-Fi et en Ethernet

Sur la connexion Wi-Fi fonctionnelle, notez le nom d’hôte Jellyfin, l’adresse IP résolue, le sous-réseau du client et le port. Passez ensuite en Ethernet et répétez les mêmes vérifications. Si le nom d’hôte se résout vers une adresse différente ou inaccessible, corrigez le DNS ou la route du client avant de modifier les paramètres de Jellyfin.

La documentation réseau de Jellyfin explique que l’accès normal utilise l’adresse IP de l’hôte et le port HTTP(S) configuré, tandis que la découverte locale est limitée au sous-réseau local. Consultez le comportement du réseau local lorsqu’un client filaire se trouve sur un VLAN ou un sous-réseau différent de celui du réseau Wi-Fi.

Testez directement l’adresse IP du serveur depuis Ethernet. Si l’adresse IP fonctionne mais que le nom d’hôte échoue, le problème vient du DNS. Si aucun des deux ne fonctionne, poursuivez avec les vérifications de routage et de pare-feu ; si la connexion au port TCP fonctionne mais que l’application se comporte différemment, examinez la classification local/distant de Jellyfin.

Vérifiez quelle interface et quelle route le client utilise réellement

Une machine équipée d’adaptateurs Wi-Fi, Ethernet et VPN peut conserver plusieurs routes simultanément. Lorsque l’Ethernet est connecté, le système d’exploitation peut privilégier une nouvelle route par défaut ou une route de sous-réseau plus spécifique, qui dirige le trafic Jellyfin vers un autre chemin que celui du Wi-Fi fonctionnel.

Examinez la route vers l’adresse IP du serveur Jellyfin à l’aide des outils de routage de votre système d’exploitation et comparez-la à l’état fonctionnel. Désactivez temporairement une seule interface pour confirmer cette piste, puis réactivez-la ; ne supprimez pas définitivement de routes avant de savoir quelle règle est incorrecte.

Si la route pointe vers la bonne passerelle Ethernet et que le serveur répond au ping, mais que le port Jellyfin échoue, le test suivant doit porter sur le pare-feu ou la liaison du service, plutôt que sur le DNS.

Vérifiez les règles du pare-feu et les réseaux locaux de Jellyfin

Comparez les règles du pare-feu pour le sous-réseau Ethernet, le sous-réseau VPN et le sous-réseau Wi-Fi. Les routeurs domestiques et les commutateurs administrables appliquent souvent des règles VLAN ou de réseau invité différentes, même si les trois connexions se trouvent physiquement dans le même domicile.

Dans Jellyfin, vérifiez les valeurs CIDR des réseaux locaux et la politique d’accès distant. Un client provenant d’un sous-réseau non répertorié peut être considéré comme distant, ce qui peut modifier l’autorisation d’accès pour cet utilisateur, même si le serveur écoute normalement.

Pour un exemple plus général permettant de distinguer une réussite locale d’un échec lié au chemin distant, consultez les chemins d’accès local et distant. La même méthode s’applique ici : vérifiez chaque saut réseau avant de modifier l’application.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Recherchez un chevauchement de sous-réseaux VPN ou un comportement lié au nœud de sortie

Lorsque l’échec apparaît uniquement avec un VPN activé, comparez les routes VPN avec celles du réseau local physique. Deux réseaux utilisant le même sous-réseau privé peuvent amener le client à envoyer le trafic Jellyfin dans le tunnel, même si le serveur se trouve physiquement à proximité.

Tailscale documente des cas où les routes de sous-réseau, les nœuds de sortie ou les paramètres d’accès au réseau local peuvent empêcher un client d’atteindre un appareil local. Utilisez son guide de dépannage de la connectivité au réseau local comme exemple de la manière dont le routage VPN peut remplacer le chemin qui fonctionnait avant l’activation du tunnel.

Désactivez temporairement l’acceptation des routes VPN ou le nœud de sortie, puis retestez la même adresse IP Jellyfin. Si l’accès revient immédiatement, laissez le serveur Jellyfin inchangé et corrigez plutôt le routage VPN ou la politique d’accès au réseau local.

Retestez le chemin client d’origine après chaque correction réseau

Une fois la cause identifiée, appliquez uniquement la modification correspondante : corriger le DNS, ajuster les métriques ou les préfixes de route, autoriser le sous-réseau Ethernet/VPN dans le pare-feu, ou corriger l’entrée des réseaux locaux de Jellyfin. Restaurez ensuite toutes les interfaces normales et répétez la méthode de connexion d’origine.

Vérifiez à la fois le client web Jellyfin et un client natif si votre foyer utilise les deux, car la découverte, les URL de serveur enregistrées et l’accès HTTP direct peuvent emprunter des chemins différents. Effectuez également un test après le redémarrage ou la reconnexion du client afin que des routes mises en cache ne transforment pas une réussite temporaire en succès permanent.

Ne passez à l’étape supérieure que si l’adresse IP de destination, la route, le pare-feu et la classification des réseaux locaux sont tous corrects, mais que la même interface échoue toujours. Recueillez les tables de routage fonctionnelles et défaillantes, les adresses IP des clients et les journaux du serveur lors d’une même tentative ; ces éléments sont bien plus utiles que de réinstaller Jellyfin ou de réinitialiser tous les paramètres réseau en une seule fois.