Questo lungo thread di supporto tratta molti argomenti per principianti, ma il risultato più utile e facilmente ricercabile sembra trovarsi a pagina 3: un server Jellyfin funzionava localmente, DuckDNS veniva risolto e un certificato SSL era presente, eppure il dominio pubblico restituiva 502 Bad Gateway. La community ha infine separato il problema in tre livelli: la connessione di Nginx Proxy Manager a Jellyfin, la configurazione TLS e la gestione della porta 443 da parte del router.
La svolta finale è arrivata quando l'utente ha disabilitato il servizio NAS del router sulla porta 443. Dopodiché, sia HTTP sia HTTPS hanno raggiunto Jellyfin.
Un errore 502 indicava che il proxy non riusciva a raggiungere Jellyfin
Inizialmente, la risoluzione dei problemi della community si è concentrata sulla destinazione upstream di Nginx Proxy Manager. Il normale servizio HTTP di Jellyfin era attivo sulla porta 8096; il proxy doveva inoltrare le richieste al container Jellyfin tramite HTTP, invece di trattare la porta HTTPS opzionale di Jellyfin come upstream.
Le indicazioni attuali di Jellyfin seguono lo stesso modello: i suoi esempi di reverse proxy Nginx inoltrano il traffico normale e i WebSocket a Jellyfin sulla porta 8096.
Il proxy e Jellyfin hanno bisogno di un percorso Docker raggiungibile
A un certo punto, l'uso del nome del container non funzionava, quindi il collaboratore della community ha configurato il proxy per usare l'indirizzo Docker interno di Jellyfin. In questo modo il percorso HTTP ha iniziato a funzionare.
L'uso dell'indirizzo IP interno variabile di un container è meno solido rispetto all'inserimento di entrambi i servizi in una rete Docker condivisa e controllata, con una risoluzione stabile dei nomi dei servizi. Il thread originale documenta ciò che ha funzionato in quella specifica installazione, non una configurazione Compose ideale per ogni server.
Risolvi il routing HTTP prima di aggiungere SSL
Una fonte importante di confusione era la modifica delle opzioni TLS mentre il proxy non riusciva ancora a raggiungere Jellyfin. La community ha temporaneamente rimosso SSL dall'host proxy, verificato prima il routing HTTP semplice e solo dopo ripristinato il certificato e forzato HTTPS.
Questo ordine di troubleshooting è più utile che copiare un singolo indirizzo IP: verifica prima il routing upstream, poi diagnostica TLS.
Il router stava utilizzando la porta 443
Dopo che HTTP ha finalmente aperto Jellyfin, la riattivazione di HTTPS portava l'utente alla pagina di accesso del router. Era l'indizio più significativo del thread: la porta 443 in ingresso veniva gestita dalla funzione NAS/amministrazione del router, invece di essere inoltrata a Nginx Proxy Manager.
L'utente ha disabilitato il servizio NAS interno del router sulla porta 443 e ha quindi confermato che HTTPS funzionava.
Il funzionamento di HTTPS remoto non garantiva il rilevamento locale nell'app
In seguito, il thread ha esaminato i client Roku e per telefoni. L'accesso tramite browser attraverso il dominio pubblico funzionava, ma il rilevamento automatico locale e il comportamento hairpin/NAT loopback rimanevano incostanti. Alla fine, la community ha utilizzato DLNA come soluzione pratica per Roku.
Questo aspetto successivo non deve essere confuso con il percorso 502/HTTPS risolto. Il routing remoto tramite reverse proxy e il rilevamento dei dispositivi locali sono comportamenti di rete separati.
Si è trattato di assistenza della community sulla rete, non di una procedura di sicurezza IceWhale
I passaggi dettagliati per il reverse proxy provenivano dai partecipanti della community. Esporre Jellyfin tramite un dominio richiede un'attenta gestione del router, di TLS, dell'autenticazione e degli aggiornamenti. Non pubblicare servizi amministrativi ZimaOS non correlati solo perché la porta 443 è inoltrata a un reverse proxy.
Domande frequenti su Jellyfin e NPM
Che cosa ha causato il 502 Bad Gateway?
Inizialmente, Nginx Proxy Manager non riusciva a raggiungere correttamente l'upstream Jellyfin. Una volta corretto il routing, Jellyfin si è caricato tramite HTTP.
Perché HTTPS apriva la pagina di accesso del router?
Il router stesso utilizzava la porta 443. Disabilitare o spostare quel servizio del router ha permesso alla porta 443 di raggiungere Nginx Proxy Manager.
NPM dovrebbe usare HTTP o HTTPS internamente per il proxy verso Jellyfin?
La configurazione funzionante del thread e gli attuali esempi Nginx di Jellyfin usano HTTP verso il servizio Jellyfin sulla porta 8096, con TLS terminato sul reverse proxy.
HTTPS remoto permette il rilevamento automatico di Jellyfin su Roku?
No. Il rilevamento del client, l'isolamento Wi-Fi, la rete Docker e il NAT loopback sono problemi separati.
