Ce long fil d'assistance couvre de nombreux sujets pour débutants, mais son résultat le plus utile et le plus facile à retrouver semble se trouver à la page 3 : un serveur Jellyfin fonctionnait en local, DuckDNS était résolu et un certificat SSL existait, mais le domaine public renvoyait une erreur 502 Bad Gateway. La communauté a finalement séparé le problème en trois couches : la connexion de Nginx Proxy Manager à Jellyfin, la configuration TLS et la gestion du port 443 par le routeur.
La découverte décisive est survenue lorsque l'utilisateur a désactivé le service NAS intégré du routeur sur le port 443. Après cela, HTTP et HTTPS accédaient tous deux à Jellyfin.
Une erreur 502 signifiait que le proxy ne pouvait pas joindre Jellyfin
Le dépannage de la communauté s'est d'abord concentré sur la cible en amont de Nginx Proxy Manager. Le service HTTP normal de Jellyfin utilisait le port 8096 : le proxy devait transférer les requêtes vers le conteneur Jellyfin en HTTP, au lieu de considérer le port HTTPS facultatif de Jellyfin comme service en amont.
Les recommandations actuelles de Jellyfin utilisent le même modèle : ses exemples de reverse proxy Nginx transfèrent le trafic normal et les WebSockets vers Jellyfin sur le port 8096.
Le proxy et Jellyfin ont besoin d'un chemin Docker accessible
À un moment donné, le nom du conteneur ne fonctionnait pas. L'aide de la communauté a donc configuré le proxy pour utiliser l'adresse Docker interne de Jellyfin. Le chemin HTTP a alors commencé à fonctionner.
Utiliser l'adresse IP interne changeante d'un conteneur est moins robuste que de placer les deux services sur un réseau Docker partagé et contrôlé, avec une résolution stable par nom de service. Le fil source documente ce qui a fonctionné dans cette installation, et non une conception Compose idéale pour chaque serveur.
Corrigez le routage HTTP avant d'ajouter SSL
Une importante source de confusion venait du fait que les options TLS étaient modifiées alors que le proxy ne pouvait toujours pas joindre Jellyfin. La communauté a temporairement supprimé SSL de l'hôte proxy, vérifié d'abord le routage HTTP simple, puis réactivé le certificat et forcé HTTPS.
Cet ordre de dépannage est plus utile que la copie d'une adresse IP donnée : vérifiez d'abord le routage vers le service en amont, puis diagnostiquez TLS.
Le routeur utilisait le port 443
Après que HTTP a enfin ouvert Jellyfin, la réactivation de HTTPS redirigeait l'utilisateur vers la page de connexion du routeur. C'était l'indice le plus révélateur du fil : le port 443 entrant était géré par la fonction NAS/administration du routeur au lieu d'être redirigé vers Nginx Proxy Manager.
L'utilisateur a désactivé le service NAS interne du routeur sur le port 443, puis a confirmé que HTTPS fonctionnait.
Le fonctionnement de HTTPS à distance ne garantissait pas la découverte locale dans les applications
Le fil a ensuite abordé les clients Roku et mobiles. L'accès au navigateur via le domaine public fonctionnait, mais la découverte automatique locale et le comportement du hairpin/NAT loopback restaient irréguliers. La communauté a finalement utilisé DLNA comme solution pratique pour Roku.
Ce suivi ne doit pas être mélangé avec le chemin 502/HTTPS résolu. Le routage distant par reverse proxy et la découverte des appareils locaux sont deux comportements réseau distincts.
Il s'agissait d'une aide réseau de la communauté, pas d'une procédure de sécurité IceWhale
Les étapes détaillées du reverse proxy provenaient de participants de la communauté. Exposer Jellyfin via un domaine nécessite une gestion rigoureuse du routeur, de TLS, de l'authentification et des mises à jour. Ne publiez pas de services d'administration ZimaOS sans rapport simplement parce que le port 443 est redirigé vers un reverse proxy.
FAQ Jellyfin avec NPM
Quelle était la cause de l'erreur 502 Bad Gateway ?
Nginx Proxy Manager ne parvenait pas initialement à joindre correctement le service Jellyfin en amont. Une fois le routage corrigé, Jellyfin s'est chargé en HTTP.
Pourquoi HTTPS ouvrait-il la page de connexion du routeur ?
Le routeur utilisait lui-même le port 443. La désactivation ou le déplacement de ce service du routeur a permis au port 443 d'atteindre Nginx Proxy Manager.
NPM doit-il faire transiter Jellyfin en HTTP ou en HTTPS en interne ?
La configuration fonctionnelle du fil et les exemples Nginx actuels de Jellyfin utilisent HTTP vers le service Jellyfin sur le port 8096, TLS étant terminé au niveau du reverse proxy.
Le HTTPS distant permet-il la découverte automatique de Jellyfin sur Roku ?
Non. La découverte des clients, l'isolation Wi-Fi, le réseau Docker et le NAT loopback sont des problèmes distincts.
