Jellyfin peut-il fonctionner derrière un proxy inverse sur un sous-chemin ?

Oui. Jellyfin peut fonctionner derrière un proxy inverse sur un sous-chemin tel que https://example.com/jellyfin, mais Jellyfin et le proxy doivent utiliser le même chemin de base.

Un échec lié à un sous-chemin ressemble généralement à un site partiellement fonctionnel : la page de connexion peut s’afficher tandis que le JavaScript, les images, les WebSockets, les redirections ou les clients natifs échouent. Testez le chemin par étapes — URL de base d’abord, route du proxy ensuite, puis en-têtes transmis et adresse du client — afin de distinguer un chemin incohérent d’un problème lié à TLS ou à l’identité du proxy.

Faites correspondre l’URL de base de Jellyfin au sous-chemin public

Définissez l’URL de base de Jellyfin sur le préfixe public exact que vous souhaitez utiliser, par exemple /jellyfin. N’ajoutez pas de préfixe interne différent simplement parce que le proxy utilise un bloc d’emplacement nommé ; le chemin visible dans le navigateur et l’URL de base de Jellyfin doivent désigner la même racine d’application.

La documentation Apache de Jellyfin consacrée aux proxys inverses fournit explicitement un exemple de sous-chemin et demande aux administrateurs de définir l’URL de base sur /jellyfin avant de connecter les clients à cette adresse complète. exemple officiel de sous-chemin

Redémarrez Jellyfin après avoir modifié l’URL de base, puis ouvrez le sous-chemin public dans une nouvelle fenêtre de navigation privée. Si la redirection initiale supprime immédiatement /jellyfin ou le duplique, corrigez l’URL de base avant de modifier les paramètres WebSocket ou d’authentification.

Acheminez le même préfixe via le proxy inverse

Configurez le proxy inverse afin que les requêtes commençant par le préfixe public soient transférées vers Jellyfin sans appliquer de transformation de chemin supplémentaire. La conception la plus simple consiste en un préfixe public, une URL de base Jellyfin correspondante et un service en amont.

Le guide Caddy de Jellyfin montre le même modèle : configurez le chemin de base de Jellyfin, redirigez le préfixe sans barre oblique finale vers sa forme avec barre oblique finale, puis transmettez les requêtes sous ce préfixe au serveur principal Jellyfin. chemin de base et route du proxy correspondants

Si le navigateur reçoit une erreur 404 du proxy avant que Jellyfin n’enregistre la requête, la route est incorrecte au niveau du proxy. Si Jellyfin reçoit la requête mais génère des liens sans le préfixe, l’URL de base est incorrecte au niveau de l’application. Gardez ces deux signatures d’échec distinctes.

Vérifiez les ressources statiques et les WebSockets, pas seulement la page de connexion

Une réponse HTML réussie ne suffit pas pour considérer la configuration du sous-chemin comme fonctionnelle. Ouvrez les outils de développement ou les journaux du proxy et vérifiez que les requêtes JavaScript, CSS, d’images, d’API et WebSocket restent toutes sous le même préfixe public.

Les exemples de proxy inverse de Jellyfin incluent la gestion des WebSockets, car les clients interactifs maintiennent une connexion socket en plus des requêtes HTTP ordinaires. Une règle de proxy qui ne gère que les requêtes de pages peut donc sembler correcte jusqu’à ce que l’état de lecture, les mises à jour de session ou le fonctionnement de l’interface en temps réel cessent de fonctionner. exigences du proxy inverse

Le critère de réussite est simple : aucune réponse 404/502 répétée pour les ressources préfixées, la mise à niveau WebSocket réussit et la navigation ne revient pas à la racine du site. Si une seule catégorie de requêtes échoue, corrigez la règle correspondante du proxy au lieu de modifier la bibliothèque ou les paramètres d’authentification de Jellyfin.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Conservez l’identité du client via le proxy

Une fois le chemin fonctionnel, vérifiez les informations transmises concernant le client. Jellyfin utilise la configuration de confiance du proxy pour décider s’il doit accepter les adresses et protocoles transmis, ce qui influence le comportement local ou distant ainsi que les règles d’accès externe.

Le guide réseau de Jellyfin avertit que les en-têtes transmis par un proxy non approuvé sont ignorés et recommande de configurer l’adresse du proxy dans les proxys connus. paramètre des proxys connus Une vérification distincte de l’adresse IP du client est utile lorsque le site fonctionne, mais que chaque requête semble provenir du proxy.

Ne résolvez pas un problème d’identité en faisant confiance à chaque sous-réseau privé ou à chaque en-tête transmis. Ajoutez uniquement le saut réel du proxy ou le réseau de proxy contrôlé, puis comparez une requête du réseau local et une requête distante dans les journaux Jellyfin afin de confirmer leur classification.

Testez séparément les adresses du navigateur et des clients natifs

Saisissez l’adresse complète du serveur, y compris le sous-chemin, lorsqu’un client Jellyfin vous demande l’URL du serveur. Un client enregistré avec https://example.com ne peut pas deviner que Jellyfin se trouve sous /jellyfin.

Testez un navigateur et un client natif depuis le réseau local, puis recommencez via le nom d’hôte public. Si le nom d’hôte fonctionne mais que l’accès direct par adresse IP locale échoue, cela peut être normal lorsque la route du proxy et le certificat dépendent du nom d’hôte ; le test du nom d’hôte par rapport à l’adresse IP aide à isoler ce cas sans affaiblir le proxy.

Arrêtez-vous lorsque l’URL préfixée fonctionne lors de la connexion, de la navigation, de l’utilisation des WebSockets et de la lecture sur les clients que vous prenez réellement en charge. Si un seul client échoue alors que le navigateur et les autres clients fonctionnent, considérez qu’il s’agit d’un problème d’adresse ou de compatibilité du client plutôt que de réécrire une configuration de proxy fonctionnelle.