Włączenie HTTPS dla panelu ZimaOS nie zapewnia automatycznie adresu HTTPS dla Jellyfin, Vaultwarden, Nginx Proxy Manager ani żadnej innej aplikacji Docker. To nieporozumienie doprowadziło właśnie do rozpoczęcia tego wątku w lutym 2026 roku. Użytkownik włączył HTTPS w ustawieniach ZimaOS, zapisał certyfikat wygenerowany dla interfejsu ZimaOS i próbował zaimportować go do Nginx Proxy Manager, ale Jellyfin i NPM nadal nie działały zgodnie z oczekiwaniami.
Wątek ostatecznie doprowadził do działającej konfiguracji społecznościowej: użycia Nginx Proxy Manager jako punktu terminacji TLS dla poszczególnych aplikacji, przeniesienia bramy ZimaOS z portów 80 i 443, jeśli są potrzebne odwrotnemu proxy, skonfigurowania hosta przez DuckDNS oraz wystawienia certyfikatu dla tego hosta. Użytkownik później opublikował zrzut ekranu pokazujący działające hosty proxy i podsumował wynik jako działający.
Poznaj trzy oddzielne warstwy HTTPS
Łatwo pomylić ze sobą trzy różne elementy:
- HTTPS panelu ZimaOS chroni sam interfejs zarządzania ZimaOS.
- HTTP aplikacji to zwykły wewnętrzny port używany przez aplikację taką jak Jellyfin.
- HTTPS odwrotnego proxy to publiczny lub lokalny host, który kończy połączenie TLS i przekazuje ruch do wewnętrznego portu HTTP aplikacji.
Certyfikat wygenerowany dla interfejsu zarządzania ZimaOS nie jest więc uniwersalnym certyfikatem dla każdej aplikacji. Odwrotne proxy potrzebuje certyfikatu, którego nazwa hosta odpowiada adresowi faktycznie otwieranemu przez użytkowników w przeglądarce.
Użyj Nginx Proxy Manager jako punktu wejścia HTTPS
Najbardziej uniwersalnym elementem rozwiązania społecznościowego jest architektura, a nie dokładne numery portów z 2026 roku. Nginx Proxy Manager odbiera żądania HTTPS dla hostów takich jak jellyfin.example.net i przekazuje je do lokalnej usługi Jellyfin działającej przez HTTP. Jellyfin może nadal nasłuchiwać na swoim zwykłym wewnętrznym porcie — nie musi samodzielnie zarządzać publicznym certyfikatem.
Obecny Nginx Proxy Manager nadal działa w ten sposób: utwórz Proxy Host, określ hosta docelowego i port, a następnie dołącz certyfikat SSL i opcjonalnie wymuś SSL. W przypadku nowej konfiguracji skorzystaj z aktualnego procesu konfiguracji hostów proxy i certyfikatów w Nginx Proxy Manager, zamiast traktować stary zrzut ekranu jako niezmienny układ interfejsu.
Rozwiąż konflikty portów 80 i 443 przed wystawieniem certyfikatów
Użytkownik odkrył, że brama ZimaOS już korzystała z portów 80 i 443. Ma to znaczenie, ponieważ odwrotne proxy zwykle chce nasłuchiwać na tych standardowych portach. Rozwiązaniem było zmienienie portów bramy ZimaOS w pliku /etc/casaos/gateway.ini — port 80 zmieniono na 85, a 443 na 444 — a następnie ponowne uruchomienie usługi bramy.
Te dokładne zmiany pochodziły od użytkownika, a nie z odpowiedzi zespołu pomocy IceWhale w tym wątku. Należy traktować je jako historyczne obejście opracowane przez społeczność, a nie uniwersalną sekwencję poleceń. Przed zmianą portów panelu zanotuj bieżący adres URL, upewnij się, że wiesz, jak później uzyskać dostęp do ZimaOS, i preferuj aktualny interfejs ZimaOS, jeśli oferuje obsługiwany sposób zmiany portu zarządzania.
Dlaczego DuckDNS pomógł użytkownikowi
Urząd certyfikacji potrzebuje hosta, który może zweryfikować. Użytkownik skonfigurował DuckDNS, a następnie użył tego hosta do zamówienia certyfikatu przez Nginx Proxy Manager. Rozwiązało to inny problem niż „jak uzyskać dostęp do aplikacji?”: DNS dostarczył nazwę, a NPM zapewnił terminację HTTPS i przekierowanie.
HTTPS tylko lokalnie nadal wymaga DNS rozpoznającego nazwę lokalnie
Pierwotne pytanie dotyczyło konkretnie HTTPS wewnątrz sieci lokalnej, a nie dostępu zdalnego. Nazwa domenowa nie oznacza, że ruch musi opuszczać dom. Możesz skonfigurować rozpoznawanie hosta na adres LAN ZimaOS wewnątrz swojej sieci za pomocą lokalnego DNS lub DNS typu split DNS, a następnie pozwolić Nginx Proxy Managerowi obsługiwać zaufany certyfikat dla tej nazwy.
Zwykle jest to wygodniejsze niż otwieranie adresu prywatnego IP i próba dopasowania do niego publicznego certyfikatu. Certyfikat jest wystawiony dla hosta, a lokalny DNS decyduje, że host powinien wskazywać prywatny adres.
Certyfikat samopodpisany to kolejna opcja, ale wymaga zarządzania zaufaniem
Jedna z odpowiedzi społecznościowych sugerowała wygenerowanie certyfikatu za pomocą OpenSSL i zaimportowanie go do Nginx Proxy Manager. Może to działać w przypadku użycia wyłącznie lokalnego, ale przeglądarki i urządzenia nie będą automatycznie ufać certyfikatowi samopodpisanemu. Każdy klient, który ma wyświetlać prawidłowe połączenie HTTPS, musi ufać certyfikatowi wystawiającemu lub lokalnemu urzędowi certyfikacji.
W gospodarstwie domowym z wieloma telefonami, telewizorami, tabletami i aplikacjami użycie publicznie zaufanego certyfikatu dla hosta często jest łatwiejsze niż ręczne instalowanie lokalnego urzędu certyfikacji wszędzie.
Cloudflare to alternatywna architektura, a nie wymaganie
Inny uczestnik powiedział, że używa Cloudflare zarówno wewnątrz domu, jak i poza nim. Cloudflare może być przydatny, jeśli ten sam host ma działać zdalnie, ale pierwotne pytanie nie wymagało publicznego dostępu. Nie dodawaj tunelu tylko dlatego, że chcesz korzystać z HTTPS w sieci LAN.
Weryfikuj każdą warstwę osobno
- Sprawdź, czy aplikacja otwiera się przez bezpośredni lokalny adres HTTP.
- Sprawdź, czy host wskazuje na zamierzone odwrotne proxy.
- Sprawdź, czy Nginx Proxy Manager może połączyć się z wewnętrznym hostem i portem aplikacji.
- Dołącz certyfikat dopiero po uruchomieniu zwykłego przekierowania proxy.
- Następnie wymuś HTTPS i przetestuj połączenie z więcej niż jednego lokalnego klienta.
Taka kolejność zapobiega pomyleniu problemu z certyfikatem z problemem routingu Dockera lub konfliktem portów.
Często zadawane pytania dotyczące lokalnego HTTPS w ZimaOS
Czy przełącznik HTTPS w ZimaOS automatycznie zabezpiecza Jellyfin?
Nie. Zabezpiecza interfejs zarządzania ZimaOS, a nie każdą aplikację Docker.
Czy do HTTPS tylko w sieci LAN potrzebuję publicznej domeny?
Potrzebujesz hosta, któremu odpowiada certyfikat. Ten host może wskazywać na prywatny adres LAN wewnątrz Twojej sieci.
Dlaczego użytkownik przeniósł ZimaOS z portów 80 i 443?
Nginx Proxy Manager potrzebował standardowych portów HTTP i HTTPS. Zmiana była obejściem zastosowanym przez społeczność w tej konkretnej instalacji.
Czy konfiguracja użytkownika została potwierdzona jako działająca?
Tak. Autor oryginalnego wpisu pokazał hosty NPM działające z certyfikatami i poinformował, że konfiguracja działa.
