Communityoplossing

HTTPS instellen voor lokale ZimaOS-apps met Nginx Proxy Manager

A February 2026 discussion about giving local Jellyfin and other ZimaOS apps HTTPS. The source user ultimately used Nginx Proxy Manager with DuckDNS certificates, while the thread made clear that the ZimaOS HTTPS toggle does not automatically secure every container.

Als je HTTPS inschakelt voor het ZimaOS-dashboard, krijgen Jellyfin, Vaultwarden, Nginx Proxy Manager of andere Docker-applicaties niet automatisch een HTTPS-adres. Die misvatting leidde precies tot deze discussie uit februari 2026. De gebruiker had HTTPS ingeschakeld in de ZimaOS-instellingen, het certificaat dat voor de ZimaOS-interface was gegenereerd opgeslagen en geprobeerd dit in Nginx Proxy Manager te importeren, maar Jellyfin en NPM werkten nog steeds niet zoals verwacht.

De discussie resulteerde uiteindelijk in een werkende configuratie uit de community: gebruik Nginx Proxy Manager als TLS-beëindigingspunt voor afzonderlijke applicaties, verplaats de ZimaOS-gateway weg van poort 80 en 443 als die poorten nodig zijn voor de reverse proxy, configureer een hostnaam via DuckDNS en vraag een certificaat voor die hostnaam aan. De oorspronkelijke gebruiker plaatste later een screenshot waarop de proxyhosts online waren en vatte het resultaat samen als werkend.

Begrijp de drie afzonderlijke HTTPS-lagen

Er zijn drie verschillende zaken die gemakkelijk door elkaar worden gehaald:

  • HTTPS voor het ZimaOS-dashboard beschermt alleen de ZimaOS-beheerinterface.
  • HTTP voor applicaties is de normale interne poort die een app zoals Jellyfin gebruikt.
  • HTTPS via een reverse proxy is een openbare of lokale hostnaam die TLS beëindigt en verkeer doorstuurt naar de interne HTTP-poort van de app.

Het certificaat dat voor de ZimaOS-beheerinterface is gegenereerd, is dus geen universeel certificaat voor elke applicatie. Een reverse proxy heeft een certificaat nodig waarvan de hostnaam overeenkomt met het adres dat gebruikers daadwerkelijk in hun browser openen.

Gebruik Nginx Proxy Manager als HTTPS-toegangspunt

Het meest herbruikbare onderdeel van de communityoplossing is de architectuur, niet de exacte poortnummers uit 2026. Nginx Proxy Manager ontvangt HTTPS-verzoeken voor hostnamen zoals jellyfin.example.net en stuurt die door naar de lokale HTTP-service van Jellyfin. Jellyfin kan op zijn normale interne poort blijven luisteren; de openbare certificaten hoeven niet door Jellyfin zelf te worden beheerd.

De huidige versie van Nginx Proxy Manager werkt nog steeds volgens dit model: maak een Proxy Host aan, geef de doelhost en -poort op, koppel vervolgens een SSL-certificaat en forceer desgewenst SSL. Gebruik voor een nieuwe installatie de huidige Nginx Proxy Manager-procedure voor proxyhosts en certificaten in plaats van een oude schermafbeelding als vaste weergave van de interface te beschouwen.

Los conflicten met poort 80 en 443 op voordat je certificaten aanvraagt

De oorspronkelijke gebruiker ontdekte dat de ZimaOS-gateway poort 80 en 443 al gebruikte. Dat is belangrijk, omdat een reverse proxy normaal gesproken op die standaardpoorten wil luisteren. De gekozen oplossing was om de poorten van de ZimaOS-gateway te wijzigen in /etc/casaos/gateway.ini: poort 80 werd gewijzigd in 85 en poort 443 in 444. Daarna werd de gatewayservice opnieuw gestart.

Deze exacte wijzigingen kwamen van de gebruiker en niet uit een reactie van IceWhale-support in deze discussie. Beschouw ze daarom als een historische workaround uit de community en niet als een universele reeks opdrachten. Noteer voordat je dashboardpoorten wijzigt de huidige URL, zorg dat je weet hoe je daarna bij ZimaOS komt en gebruik bij voorkeur de huidige ZimaOS-interface wanneer die een officieel ondersteunde manier biedt om de beheerpoort te wijzigen.

Waarom DuckDNS de oorspronkelijke gebruiker hielp

Een certificaatautoriteit heeft een hostnaam nodig die zij kan valideren. De gebruiker configureerde DuckDNS en gebruikte die hostnaam vervolgens om via Nginx Proxy Manager een certificaat aan te vragen. Daarmee werd een ander probleem opgelost dan “hoe bereik ik de app?”: DNS leverde de naam, terwijl NPM zorgde voor TLS-beëindiging en doorsturen.

Nginx Proxy Manager toont meerdere online DuckDNS-proxyhosts met Let's Encrypt-certificaten voor ZimaOS-applicaties
De oorspronkelijke gebruiker toonde meerdere online proxyhosts met Let's Encrypt-certificaten nadat de ZimaOS-gateway van de standaard proxypoorten was verplaatst.

Voor alleen lokaal HTTPS is nog steeds DNS nodig die lokaal resolveert

De oorspronkelijke vraag ging specifiek over HTTPS binnen het lokale netwerk, niet over externe toegang. Een domeinnaam zorgt er niet voor dat verkeer het huis moet verlaten. Je kunt een hostnaam binnen je netwerk via lokale DNS of split-DNS laten verwijzen naar het LAN-adres van ZimaOS en Nginx Proxy Manager vervolgens een vertrouwd certificaat voor die hostnaam laten aanbieden.

Dit is doorgaans netter dan naar een rechtstreeks privé-IP-adres te browsen en te proberen een openbaar certificaat daarop te laten aansluiten. Het certificaat wordt voor de hostnaam gevalideerd; je lokale DNS bepaalt dat de hostnaam naar een privé-adres moet verwijzen.

Een zelfondertekend certificaat is een andere optie, maar je moet het vertrouwen beheren

Een reactie uit de community stelde voor om met OpenSSL een certificaat te genereren en dit in Nginx Proxy Manager te importeren. Dat kan werken voor uitsluitend lokaal gebruik, maar browsers en apparaten vertrouwen een zelfondertekend certificaat niet automatisch. Elke client die een probleemloze HTTPS-verbinding moet tonen, moet het uitgeverscertificaat of de lokale CA vertrouwen.

Voor een huishouden met veel telefoons, tv's, tablets en apps is een openbaar vertrouwd certificaat voor een hostnaam vaak eenvoudiger dan overal handmatig een lokale CA installeren.

Cloudflare is een alternatieve architectuur, geen vereiste

Een andere deelnemer zei Cloudflare zowel binnen als buiten het thuisnetwerk te gebruiken. Cloudflare kan nuttig zijn als dezelfde hostnaam op afstand moet werken, maar voor de oorspronkelijke vraag was openbare toegang niet nodig. Voeg niet alleen daarom een tunnel toe omdat je HTTPS op het LAN wilt gebruiken.

Controleer elke laag afzonderlijk

  1. Controleer of de applicatie via het rechtstreekse lokale HTTP-adres opent.
  2. Controleer of de hostnaam naar de bedoelde reverse proxy resolveert.
  3. Controleer of Nginx Proxy Manager de interne host en poort van de applicatie kan bereiken.
  4. Koppel het certificaat pas nadat gewone proxyroutering werkt.
  5. Forceer daarna HTTPS en test vanaf meer dan één lokale client.

Met deze volgorde voorkom je dat een certificaatprobleem wordt verward met een Docker-routeringsprobleem of een poortconflict.

Veelgestelde vragen over lokaal HTTPS op ZimaOS

Beveiligt de HTTPS-schakelaar van ZimaOS Jellyfin automatisch?

Nee. De schakelaar beveiligt de ZimaOS-beheerinterface, niet elke Docker-applicatie.

Heb ik een openbaar domein nodig voor HTTPS dat alleen op het LAN werkt?

Je hebt een hostnaam nodig die overeenkomt met je certificaat. Die hostnaam kan binnen je netwerk naar een privé-LAN-adres verwijzen.

Waarom verplaatste de oorspronkelijke gebruiker ZimaOS weg van poort 80 en 443?

Nginx Proxy Manager had de standaardpoorten voor HTTP en HTTPS nodig. De wijziging was een community-workaround voor die installatie.

Is bevestigd dat de configuratie van de oorspronkelijke gebruiker werkte?

Ja. De oorspronkelijke vraagsteller toonde de NPM-hosts online met certificaten en zei dat de configuratie werkte.