Abilitare HTTPS per il pannello di controllo di ZimaOS non assegna automaticamente un indirizzo HTTPS a Jellyfin, Vaultwarden, Nginx Proxy Manager o a qualsiasi altra applicazione Docker. È proprio questo fraintendimento ad aver dato origine alla discussione di febbraio 2026. L'utente aveva abilitato HTTPS nelle Impostazioni di ZimaOS, salvato il certificato generato per l'interfaccia di ZimaOS e provato a importarlo in Nginx Proxy Manager, ma Jellyfin e NPM continuavano a non comportarsi come previsto.
La discussione è infine arrivata a una configurazione funzionante condivisa dalla community: usare Nginx Proxy Manager come punto di terminazione TLS per le singole applicazioni, spostare il gateway di ZimaOS dalle porte 80 e 443 se necessarie al reverse proxy, configurare un hostname tramite DuckDNS e rilasciare un certificato per quell'hostname. In seguito l'utente ha pubblicato uno screenshot che mostrava i proxy host online e ha riassunto il risultato dicendo che funzionava.
Comprendere i tre livelli HTTPS separati
È facile confondere tre elementi diversi:
- HTTPS del pannello di controllo di ZimaOS protegge l'interfaccia di gestione di ZimaOS.
- HTTP dell'applicazione è la normale porta interna utilizzata da un'app come Jellyfin.
- HTTPS del reverse proxy è un hostname pubblico o locale che termina TLS e inoltra il traffico alla porta HTTP interna dell'app.
Il certificato generato per l'interfaccia di gestione di ZimaOS non è quindi un certificato universale per ogni applicazione. Un reverse proxy ha bisogno di un certificato il cui hostname corrisponda all'indirizzo che gli utenti aprono effettivamente nel browser.
Usare Nginx Proxy Manager come porta d'accesso HTTPS
La parte più riutilizzabile della soluzione della community è l'architettura, non i numeri esatti delle porte del 2026. Nginx Proxy Manager riceve le richieste HTTPS per hostname come jellyfin.example.net e le inoltra al servizio HTTP locale di Jellyfin. Jellyfin può continuare ad ascoltare sulla sua normale porta interna; non deve gestire direttamente il certificato pubblico.
La versione attuale di Nginx Proxy Manager mantiene questo modello: creare un Proxy Host, specificare host e porta di destinazione, quindi collegare un certificato SSL e, facoltativamente, forzare SSL. Per una nuova configurazione, segui il flusso attuale di Nginx Proxy Manager per proxy host e certificati, invece di considerare uno screenshot obsoleto come una descrizione fissa dell'interfaccia.
Risolvere i conflitti sulle porte 80 e 443 prima di rilasciare i certificati
L'utente ha scoperto che il gateway di ZimaOS utilizzava già le porte 80 e 443. Questo è importante perché normalmente un reverse proxy vuole ascoltare su queste porte standard. La soluzione adottata è stata modificare le porte del gateway di ZimaOS nel file /etc/casaos/gateway.ini, spostando la porta 80 sulla 85 e la 443 sulla 444, quindi riavviando il servizio del gateway.
Queste modifiche specifiche sono state indicate dall'utente e non provengono da una risposta dell'assistenza IceWhale in questa discussione. Devono essere considerate una soluzione alternativa storica della community, non una sequenza di comandi valida universalmente. Prima di modificare le porte del pannello di controllo, annota l'URL attuale, assicurati di sapere come raggiungere ZimaOS in seguito e preferisci l'interfaccia attuale di ZimaOS quando offre un metodo supportato per modificare la porta di gestione.
Perché DuckDNS è stato utile all'utente
Un'autorità di certificazione ha bisogno di un hostname che possa convalidare. L'utente ha configurato DuckDNS e poi ha utilizzato quell'hostname per richiedere un certificato tramite Nginx Proxy Manager. Questo ha risolto un problema diverso da «come raggiungo l'app?»: il DNS ha fornito il nome, mentre NPM ha fornito la terminazione HTTPS e l'inoltro.
Anche l'HTTPS solo locale richiede un DNS che risolva localmente
La domanda originale riguardava specificamente l'HTTPS all'interno della rete locale, non l'accesso remoto. Un nome di dominio non obbliga il traffico a uscire di casa. Puoi fare in modo che un hostname risolva all'indirizzo LAN di ZimaOS all'interno della rete tramite DNS locale o split DNS, quindi lasciare che Nginx Proxy Manager fornisca un certificato attendibile per quell'hostname.
Di solito è più semplice che navigare verso un indirizzo IP privato grezzo e cercare di far corrispondere a quell'indirizzo un certificato pubblico. Il certificato viene convalidato per l'hostname; il DNS locale stabilisce che l'hostname debba risolvere a un indirizzo privato.
Un certificato autofirmato è un'altra opzione, ma la fiducia deve essere gestita
Una risposta della community suggeriva di generare un certificato con OpenSSL e importarlo in Nginx Proxy Manager. Può funzionare per un uso esclusivamente locale, ma browser e dispositivi non considereranno automaticamente attendibile un certificato autofirmato. Ogni client che deve mostrare una connessione HTTPS senza avvisi deve considerare attendibile il certificato emittente o la CA locale.
Per una casa con molti telefoni, televisori, tablet e app, utilizzare un certificato pubblicamente attendibile per un hostname è spesso più semplice che installare manualmente una CA locale ovunque.
Cloudflare è un'architettura alternativa, non un requisito
Un altro partecipante ha detto di usare Cloudflare sia all'interno sia all'esterno della rete domestica. Cloudflare può essere utile se lo stesso hostname deve funzionare anche da remoto, ma la domanda originale non richiedeva l'accesso pubblico. Non aggiungere un tunnel solo perché desideri HTTPS sulla LAN.
Verificare separatamente ogni livello
- Verifica che l'applicazione si apra tramite il suo indirizzo HTTP locale diretto.
- Verifica che l'hostname risolva al reverse proxy previsto.
- Verifica che Nginx Proxy Manager riesca a raggiungere host e porta interni dell'applicazione.
- Collega il certificato solo dopo che il semplice instradamento tramite proxy funziona.
- Quindi forza HTTPS ed esegui il test da più di un client locale.
Questo ordine impedisce di confondere un problema di certificato con un problema di instradamento Docker o con un conflitto di porte.
Domande frequenti sull'HTTPS locale in ZimaOS
L'opzione HTTPS di ZimaOS protegge automaticamente Jellyfin?
No. Protegge l'interfaccia di gestione di ZimaOS, non ogni applicazione Docker.
Ho bisogno di un dominio pubblico per l'HTTPS solo sulla LAN?
Ti serve un hostname corrispondente al certificato. Questo hostname può risolvere a un indirizzo LAN privato all'interno della tua rete.
Perché l'utente ha spostato ZimaOS dalle porte 80 e 443?
Nginx Proxy Manager aveva bisogno delle porte HTTP e HTTPS standard. La modifica era una soluzione alternativa della community per quella specifica installazione.
La configurazione dell'utente è stata confermata come funzionante?
Sì. L'autore originale ha mostrato gli host NPM online con i certificati e ha detto che la configurazione funzionava.
