La quatrième page d’une longue discussion d’assistance ZimaOS suit les problèmes récurrents d’un utilisateur avec Jellyfin et Nginx Proxy Manager après la première configuration réussie de l’accès à distance. La leçon utile n’est pas celle d’un port magique unique : une erreur 502 peut réapparaître lorsque la cible du proxy inverse, le mappage des ports de Jellyfin, le réseau Docker ou l’état de l’application change.
Cette page se concentre uniquement sur les publications 61 à 80. Elle ne reprend pas la configuration précédente de DuckDNS et des certificats, traitée ailleurs dans la même discussion.
Séparez le message de l’API NPM de l’erreur 502 de Jellyfin
L’utilisateur a d’abord vu « La communication avec l’API a échoué, NPM fonctionne-t-il correctement ? ». L’examen des journaux par la communauté a montré que Nginx Proxy Manager fonctionnait et que le renouvellement de Let's Encrypt avait réussi. Le message temporaire concernant l’API pouvait donc être dû à une session de navigateur obsolète ou à une brève interruption entre l’interface et le backend, tandis que l’erreur 502 publique restait un problème distinct de connexion entre le proxy et Jellyfin.
Gardez les trois types d’adresses distincts
| Type d’adresse | Rôle d’exemple | NPM doit-il lui transmettre les requêtes ? |
|---|---|---|
| Adresse WAN publique | Adresse exposée par le FAI, mise à jour par DuckDNS | Non |
| Adresse LAN de ZimaOS | Adresse stable du réseau domestique telle que 192.168.1.50
|
Oui, lorsque Jellyfin publie un port hôte |
| Adresse ou nom du conteneur Docker | Point de terminaison interne tel que jellyfin:8096
|
Oui, uniquement lorsque NPM peut accéder au même réseau Docker |
La discussion alternait constamment entre un nom de conteneur, une adresse LAN de l’hôte et une adresse Docker interne. Ces éléments ne sont pas interchangeables. Choisissez un itinéraire pris en charge et testez-le depuis le conteneur NPM avant de modifier TLS ou le DNS.
Lisez le mappage des ports dans le bon sens
Les paramètres de Jellyfin indiquaient le port hôte 8097 mappé au port du conteneur 8096. Lorsque NPM se connecte via l’adresse LAN de ZimaOS, il doit utiliser le port hôte publié. Lorsque NPM se connecte directement par nom de conteneur sur un réseau Docker partagé, il utilise normalement le port interne de Jellyfin.
Une réinitialisation de connexion depuis NPM a montré que l’itinéraire sélectionné ne produisait toujours pas de réponse Jellyfin valide. C’est un élément plus probant que de simplement redémarrer les deux conteneurs.
Utilisez un ordre de diagnostic par couches
- Ouvrez Jellyfin en local et confirmez la lecture avant de toucher au proxy.
- Vérifiez que le conteneur Jellyfin est en cours d’exécution et consultez la correspondance enregistrée entre les ports de l’hôte et du conteneur.
- Choisissez soit l’adresse LAN stable de ZimaOS avec le port hôte publié, soit le nom d’un conteneur avec le port interne sur un réseau partagé.
- Testez ce point de terminaison exact depuis l’environnement de NPM.
- Ce n’est qu’une fois le routage HTTP fonctionnel que vous devez réactiver TLS et tester le domaine public.
- Après toute modification d’application ou tout redémarrage, répétez les tests locaux et ceux du proxy avant de modifier le DNS.
Une modification du chemin multimédia peut entraîner un autre problème
Plus tard, les utilisateurs distants pouvaient parcourir Jellyfin, mais ne pouvaient pas lire les fichiers multimédias. Le propriétaire a modifié les paramètres du conteneur Jellyfin et le site public a cessé de répondre. L’examen des journaux par la communauté a ensuite montré que Jellyfin fonctionnait et analysait /Media/Movies, ce qui a réorienté l’attention vers la cible du proxy. Cela montre pourquoi chaque modification doit être consignée et testée séparément.
Les chemins Linux sont sensibles à la casse lors d’une sauvegarde
Une sauvegarde de configuration a échoué parce que la commande faisait référence à /DATA/AppData/duckdns, alors que le véritable répertoire était /DATA/AppData/DuckDNS. Linux considère ces chemins comme différents. Le fil de discussion d’origine proposait une commande d’archivage créée par la communauté, mais celle-ci n’ayant pas été fournie par IceWhale, elle n’est pas reproduite ici comme procédure officielle de sauvegarde.
Avant d’archiver AppData, répertoriez les noms exacts des répertoires, arrêtez les applications lorsque leurs bases de données nécessitent un instantané cohérent, puis vérifiez l’archive en restaurant une copie dans un emplacement temporaire.
Accès à distance actuellement pris en charge
Pour l’administration et l’accès aux fichiers, les documents actuels de ZimaOS décrivent un accès chiffré pair à pair via l’accès à distance ZimaClient. Un proxy inverse public pour Jellyfin reste une procédure avancée utilisant un service tiers et ne doit exposer que le service multimédia, pas le tableau de bord de ZimaOS.
FAQ sur l’erreur 502 de Jellyfin
Le message « Échec de l’API NPM » prouve-t-il que NPM est arrêté ?
Non. Dans le fil de discussion, les journaux de NPM et le renouvellement du certificat fonctionnaient correctement, tandis que le navigateur affichait ce message.
NPM doit-il utiliser le port 8096 ou 8097 ?
Utilisez le port interne avec un réseau direct entre conteneurs, ou le port publié sur l’hôte lors de la redirection vers l’adresse LAN de ZimaOS.
Pourquoi la sauvegarde indiquait-elle que DuckDNS n’existait pas ?
Le véritable dossier AppData utilisait un D majuscule, tout comme DNS ; les chemins Linux sont sensibles à la casse.
