Jellyfin fonctionne-t-il de manière fiable derrière un CGNAT ou un double NAT ?

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Does Jellyfin Work Reliably Behind CGNAT or Double NAT?

Oui, Jellyfin peut fonctionner de manière fiable derrière un CGNAT ou un double NAT, mais uniquement lorsque les clients distants utilisent un tunnel accessible, un relais ou un chemin d’adressage routable.

La lecture locale n’est pas affectée, car les clients et le serveur communiquent au sein du réseau domestique. L’accès distant échoue lorsqu’un traducteur en amont détient l’adresse publique et que l’utilisateur ne peut pas créer de mappage entrant à travers chaque couche NAT. Un VPN maillé peut établir un chemin coordonné sortant, tandis qu’un relais VPS fournit un point de rendez-vous stable, au prix d’une dépendance supplémentaire à la bande passante et à la latence.

Pourquoi la redirection de ports classique s’arrête au mauvais routeur

La redirection de ports ne fonctionne que lorsque le routeur configuré reçoit du trafic destiné à une adresse IP publique qu’il contrôle. En présence d’un double NAT, un autre routeur se trouve en amont ; avec un CGNAT, le fournisseur partage une adresse publique entre plusieurs clients et contrôle le mappage en amont.

Les utilisateurs qui auto-hébergent remarquent que le DDNS ne peut pas contourner le CGNAT, car un nom d’hôte peut identifier une adresse sans fournir de route entrante vers le serveur privé. La découverte et l’accessibilité sont deux problèmes distincts.

Jellyfin lui-même ne fonctionne pas mal dans cette situation. Le composant défaillant est le chemin entrant non sollicité, ce qui explique pourquoi les sessions locales restent normales tandis que les tentatives de connexion externes expirent.

Les VPN maillés créent un chemin privé coordonné en sortie

Un VPN maillé attribue des adresses privées aux appareils authentifiés et tente de traverser le NAT grâce au trafic sortant des deux côtés. Lorsque la traversée directe réussit, les flux multimédias peuvent circuler directement entre les pairs sans exposer le port de Jellyfin sur l’internet public.

Un témoignage actuel sur le streaming à distance décrit Tailscale comme en grande partie résistant au CGNAT, tout en reconnaissant que certaines combinaisons de NAT particulièrement strictes peuvent encore nécessiter un relais. La fiabilité dépend du chemin effectivement sélectionné, et non de l’étiquette du VPN.

Ce modèle convient aux appareils personnels et aux petits groupes de confiance, car chaque client rejoint le réseau privé. Il est moins pratique pour des utilisateurs de navigateurs quelconques qui ne peuvent pas installer ou authentifier un client VPN.

Un relais VPS échange l’accessibilité contre un autre goulet d’étranglement

Un VPS public peut accepter les connexions entrantes et les transférer par un tunnel sortant vers le serveur domestique. Cette solution fonctionne même lorsque la traversée directe échoue, mais chaque octet multimédia peut transiter par le réseau du VPS, ce qui fait de sa capacité de sortie, de sa région, de son processeur et de la stabilité du tunnel des éléments déterminants pour la lecture.

Une conception détaillée de relais VPS utilise WireGuard ou un routage de type Headscale pour créer ce point de rendez-vous public. Cette méthode résout le problème d’adressabilité, mais pas celui d’un débit montant domestique insuffisant.

Un relais situé loin des deux extrémités peut ajouter de la latence, et une sortie facturée au volume peut rendre le streaming à haut débit coûteux. Il doit être évalué comme une infrastructure à part entière, plutôt que considéré comme un substitut transparent à une adresse IP publique.

-15% OFF

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

Single board computer zimaboard2

Verdict sur la fiabilité et critères de test

Le « oui » conditionnel ne tient plus lorsque tous les chemins disponibles passent par une région lente, que le débit montant domestique ne peut pas maintenir le débit transmis ou que l’intégration des clients est trop complexe pour les utilisateurs visés. La réussite de la traversée NAT ne suffit pas à prouver la fiabilité de la lecture.

La comparaison des débits montants limités explique pourquoi un chemin accessible en lecture directe peut malgré tout provoquer des mises en mémoire tampon. Réduire le débit au moyen du transcodage peut améliorer la diffusion tout en augmentant les besoins en calcul du serveur. Un autre rapport de terrain recommande également de procéder à une vérification du chemin distant, plutôt que de supposer que le symptôme visible identifie le goulet d’étranglement.

Effectuez trois tests avant de déclarer la solution opérationnelle : vérifiez que le chemin de connexion est direct ou notez la région du relais ; diffusez au débit maximal habituel pendant au moins 30 minutes ; puis répétez le test après que les deux extrémités ont changé de réseau. N’acceptez la conception que si le débit, la reconnexion et le contrôle d’accès restent stables dans les trois cas.