Att aktivera HTTPS för ZimaOS-instrumentpanelen ger inte automatiskt Jellyfin, Vaultwarden, Nginx Proxy Manager eller alla andra Docker-applikationer en HTTPS-adress. Det missförståndet var precis det som startade den här tråden i februari 2026. Användaren hade aktiverat HTTPS i ZimaOS-inställningarna, sparat certifikatet som genererats för ZimaOS-gränssnittet och försökt importera det till Nginx Proxy Manager, men Jellyfin och NPM fungerade fortfarande inte som förväntat.
Tråden ledde till slut fram till en fungerande konfiguration från communityn: använd Nginx Proxy Manager som TLS-termineringspunkt för enskilda applikationer, flytta ZimaOS-gatewayen från portarna 80 och 443 om de behövs av reverse proxyn, konfigurera ett värdnamn via DuckDNS och utfärda ett certifikat för värdnamnet. Källanvändaren publicerade senare en skärmbild som visade proxyvärdarna online och sammanfattade resultatet som fungerande.
Förstå de tre separata HTTPS-lagren
Det finns tre olika saker som är lätta att blanda ihop:
- HTTPS för ZimaOS-instrumentpanelen skyddar själva ZimaOS-hanteringsgränssnittet.
- HTTP för applikationen är den normala interna porten som används av en app som Jellyfin.
- HTTPS via reverse proxy är ett offentligt eller lokalt värdnamn som terminerar TLS och vidarebefordrar trafiken till appens interna HTTP-port.
Certifikatet som genereras för ZimaOS-hanteringsgränssnittet är därför inte ett universellt certifikat för alla applikationer. En reverse proxy behöver ett certifikat vars värdnamn matchar den adress som användarna faktiskt öppnar i webbläsaren.
Använd Nginx Proxy Manager som HTTPS-ingång
Den mest återanvändbara delen av communitylösningen är arkitekturen, inte de exakta portnumren från 2026. Nginx Proxy Manager tar emot HTTPS-begäranden för värdnamn som jellyfin.example.net och vidarebefordrar dem till den lokala Jellyfin-tjänsten via HTTP. Jellyfin kan fortsätta att lyssna på sin normala interna port; den behöver inte själv hantera det publika certifikatet.
Den aktuella versionen av Nginx Proxy Manager använder fortfarande denna modell: skapa en proxyvärd, ange målserver och port, anslut sedan ett SSL-certifikat och tvinga vid behov SSL. För en ny installation bör du följa det aktuella flödet i Nginx Proxy Manager för proxyvärdar och certifikat i stället för att behandla en gammal skärmbild som en fast beskrivning av gränssnittet.
Lös konflikter på port 80 och 443 innan du utfärdar certifikat
Källanvändaren upptäckte att ZimaOS-gatewayen redan använde portarna 80 och 443. Det är viktigt eftersom en reverse proxy normalt vill lyssna på dessa standardportar. Lösningen var att ändra ZimaOS-gatewayens portar i /etc/casaos/gateway.ini, så att 80 ändrades till 85 och 443 till 444, och därefter starta om gatewaytjänsten.
De exakta ändringarna kom från användaren och inte från ett supportsvar från IceWhale i den här tråden. De bör därför betraktas som en historisk workaround från communityn, inte som en universell kommandosekvens. Innan du ändrar instrumentpanelens portar bör du notera den aktuella URL:en, kontrollera att du vet hur du når ZimaOS efteråt och i första hand använda det aktuella ZimaOS-gränssnittet om det erbjuder ett stödd sätt att ändra hanteringsporten.
Varför DuckDNS hjälpte källanvändaren
En certifikatutfärdare behöver ett värdnamn som den kan validera. Användaren konfigurerade DuckDNS och använde sedan värdnamnet för att begära ett certifikat via Nginx Proxy Manager. Det löste ett annat problem än ”hur når jag appen?”: DNS tillhandahöll namnet, medan NPM stod för HTTPS-terminering och vidarebefordran.
HTTPS endast lokalt kräver fortfarande DNS som fungerar lokalt
Den ursprungliga frågan gällde specifikt HTTPS inom det lokala nätverket, inte fjärråtkomst. Ett domännamn tvingar inte trafiken att lämna hemmet. Du kan få ett värdnamn att peka på ZimaOS LAN-adress inom nätverket via lokal DNS eller split DNS och sedan låta Nginx Proxy Manager tillhandahålla ett betrott certifikat för värdnamnet.
Detta är vanligtvis renare än att surfa till en rå privat IP-adress och försöka få ett publikt certifikat att matcha den. Certifikatet valideras för värdnamnet, medan din lokala DNS avgör att värdnamnet ska peka på en privat adress.
Ett självsignerat certifikat är ett annat alternativ, men tillit måste hanteras
Ett svar från communityn föreslog att generera ett certifikat med OpenSSL och importera det till Nginx Proxy Manager. Det kan fungera för rent lokal användning, men webbläsare och enheter litar inte automatiskt på ett självsignerat certifikat. Varje klient som ska visa en felfri HTTPS-anslutning måste lita på det utfärdande certifikatet eller den lokala certifikatutfärdaren.
För ett hushåll med många telefoner, TV-apparater, surfplattor och appar är det ofta enklare att använda ett publikt betrott certifikat för ett värdnamn än att installera en lokal certifikatutfärdare manuellt överallt.
Cloudflare är en alternativ arkitektur, inte ett krav
En annan deltagare uppgav att de använde Cloudflare både i och utanför hemnätverket. Cloudflare kan vara användbart om samma värdnamn måste fungera på distans, men källfrågan krävde inte publik åtkomst. Lägg inte till en tunnel bara för att HTTPS önskas på det lokala nätverket.
Verifiera varje lager separat
- Kontrollera att applikationen öppnas via sin direkta lokala HTTP-adress.
- Kontrollera att värdnamnet pekar på den avsedda reverse proxyn.
- Kontrollera att Nginx Proxy Manager kan nå applikationens interna värd och port.
- Anslut certifikatet först när vanlig proxytrafik fungerar.
- Tvinga därefter HTTPS och testa från mer än en lokal klient.
Den här ordningen förhindrar att ett certifikatproblem förväxlas med ett Docker-routingproblem eller en portkonflikt.
Vanliga frågor om lokal HTTPS på ZimaOS
Skyddar ZimaOS HTTPS-reglage Jellyfin automatiskt?
Nej. Det skyddar ZimaOS-hanteringsgränssnittet, inte alla Docker-applikationer.
Behöver jag en publik domän för HTTPS som endast används på LAN?
Du behöver ett värdnamn som certifikatet matchar. Värdnamnet kan peka på en privat LAN-adress inom nätverket.
Varför flyttade källanvändaren ZimaOS från portarna 80 och 443?
Nginx Proxy Manager behövde standardportarna för HTTP och HTTPS. Ändringen var en workaround från communityn för den installationen.
Bekräftades källkonfigurationen fungera?
Ja. Originalförfattaren visade NPM-värdarna online med certifikat och uppgav att konfigurationen fungerade.
