ZimaOS 대시보드에서 HTTPS를 활성화해도 Jellyfin, Vaultwarden, Nginx Proxy Manager 또는 다른 모든 Docker 애플리케이션에 HTTPS 주소가 자동으로 부여되는 것은 아닙니다. 이러한 오해가 바로 2026년 2월에 시작된 이 스레드의 발단이었습니다. 사용자는 ZimaOS 설정에서 HTTPS를 활성화하고 ZimaOS 인터페이스용으로 생성된 인증서를 저장한 뒤 Nginx Proxy Manager로 가져오려고 했지만, Jellyfin과 NPM은 여전히 예상대로 작동하지 않았습니다.
결국 이 스레드는 작동하는 커뮤니티 구성에 도달했습니다. 개별 애플리케이션의 TLS 종료 지점으로 Nginx Proxy Manager를 사용하고, 리버스 프록시에 해당 포트가 필요하다면 ZimaOS 게이트웨이를 80번 및 443번 포트에서 다른 포트로 옮긴 다음, DuckDNS를 통해 호스트 이름을 구성하고 해당 호스트 이름용 인증서를 발급하는 방식입니다. 이후 원 작성자는 프록시 호스트가 온라인 상태인 모습을 보여 주는 스크린샷을 게시하고 정상적으로 작동한다고 요약했습니다.
서로 다른 세 가지 HTTPS 계층 이해하기
쉽게 혼동할 수 있는 요소는 서로 다른 세 가지입니다.
- ZimaOS 대시보드 HTTPS는 ZimaOS 관리 인터페이스 자체를 보호합니다.
- 애플리케이션 HTTP는 Jellyfin과 같은 앱이 사용하는 일반적인 내부 포트입니다.
- 리버스 프록시 HTTPS는 TLS를 종료한 뒤 트래픽을 앱의 내부 HTTP 포트로 전달하는 공개 또는 로컬 호스트 이름입니다.
따라서 ZimaOS 관리 UI용으로 생성된 인증서는 모든 애플리케이션에 사용할 수 있는 범용 인증서가 아닙니다. 리버스 프록시는 사용자가 브라우저에서 실제로 여는 주소와 일치하는 호스트 이름의 인증서를 필요로 합니다.
Nginx Proxy Manager를 HTTPS 진입점으로 사용하기
커뮤니티 해결 방법에서 가장 재사용하기 좋은 부분은 정확한 2026년 포트 번호가 아니라 아키텍처입니다. Nginx Proxy Manager는 jellyfin.example.net과 같은 호스트 이름에 대한 HTTPS 요청을 수신하고 이를 로컬 Jellyfin HTTP 서비스로 전달합니다. Jellyfin은 기존의 일반적인 내부 포트에서 계속 수신 대기하면 되며, 공개 인증서를 직접 관리할 필요가 없습니다.
현재 Nginx Proxy Manager도 이 모델을 유지합니다. 프록시 호스트를 만들고 대상 호스트와 포트를 지정한 다음 SSL 인증서를 연결하고 필요에 따라 SSL 강제를 활성화하면 됩니다. 새로 설정할 때는 오래된 스크린샷을 고정된 UI 구성으로 간주하지 말고 현재 Nginx Proxy Manager의 프록시 호스트 및 인증서 설정 절차를 따르세요.
인증서 발급 전에 80번 및 443번 포트 충돌 해결하기
원 작성자는 ZimaOS 게이트웨이가 이미 80번 및 443번 포트를 사용하고 있다는 사실을 발견했습니다. 일반적으로 리버스 프록시는 이러한 표준 포트에서 수신 대기하려 하기 때문에 이는 중요합니다. 사용자는 /etc/casaos/gateway.ini에서 ZimaOS 게이트웨이 포트를 변경해 80번 포트를 85번으로, 443번 포트를 444번으로 옮긴 뒤 게이트웨이 서비스를 다시 시작했습니다.
이러한 정확한 수정 방법은 이 스레드의 IceWhale 지원 답변이 아니라 사용자가 제시한 것입니다. 따라서 보편적으로 적용할 명령어 순서가 아니라 역사적인 커뮤니티 해결 방법으로 간주해야 합니다. 대시보드 포트를 변경하기 전에 현재 URL을 기록하고 변경 후 ZimaOS에 다시 접속할 방법을 알고 있는지 확인하세요. 또한 관리 포트를 변경할 수 있도록 지원되는 방법을 현재 ZimaOS UI에서 제공한다면 이를 우선 사용하세요.
DuckDNS가 원 작성자에게 도움이 된 이유
인증 기관은 검증할 수 있는 호스트 이름을 필요로 합니다. 사용자는 DuckDNS를 구성한 다음 Nginx Proxy Manager를 통해 해당 호스트 이름용 인증서를 요청했습니다. 이는 “앱에 어떻게 접속하나요?”와는 다른 문제를 해결했습니다. DNS가 이름을 제공하고, NPM이 HTTPS 종료와 전달을 담당한 것입니다.
로컬 전용 HTTPS에도 로컬에서 확인되는 DNS가 필요합니다
원래 질문은 원격 접속이 아니라 로컬 네트워크 내부에서의 HTTPS에 관한 것이었습니다. 도메인 이름을 사용한다고 해서 트래픽이 집 밖으로 나가야 하는 것은 아닙니다. 로컬 DNS 또는 분할 DNS를 통해 네트워크 내부에서 호스트 이름이 ZimaOS LAN 주소로 확인되도록 한 다음, Nginx Proxy Manager가 해당 호스트 이름에 대한 신뢰할 수 있는 인증서를 제공하게 할 수 있습니다.
이는 원시 사설 IP 주소로 접속한 뒤 공개 인증서가 해당 IP와 일치하도록 만들려는 것보다 일반적으로 더 깔끔합니다. 인증서는 호스트 이름에 대해 검증되고, 로컬 DNS가 해당 호스트 이름이 사설 주소로 확인되도록 결정합니다.
자체 서명 인증서도 선택할 수 있지만 신뢰 설정이 필요합니다
한 커뮤니티 답변에서는 OpenSSL로 인증서를 생성해 Nginx Proxy Manager로 가져오는 방법을 제안했습니다. 순수하게 로컬에서만 사용한다면 이 방법이 작동할 수 있지만, 브라우저와 기기는 자체 서명 인증서를 자동으로 신뢰하지 않습니다. 정상적인 HTTPS 연결로 표시되기를 원하는 모든 클라이언트가 해당 발급 인증서 또는 로컬 CA를 신뢰하도록 설정해야 합니다.
여러 대의 휴대폰, TV, 태블릿 및 앱을 사용하는 가정에서는 모든 기기에 로컬 CA를 수동으로 설치하는 것보다 공개적으로 신뢰되는 인증서를 호스트 이름에 사용하는 편이 더 쉬운 경우가 많습니다.
Cloudflare는 필수가 아니라 대안 아키텍처입니다
다른 참여자는 집 안팎에서 Cloudflare를 사용한다고 말했습니다. 동일한 호스트 이름이 원격에서도 작동해야 한다면 Cloudflare가 유용할 수 있지만, 원래 질문에는 공개 액세스가 필요하지 않았습니다. LAN에서 HTTPS를 사용하고 싶다는 이유만으로 터널을 추가하지 마세요.
각 계층을 별도로 확인하기
- 애플리케이션이 직접 로컬 HTTP 주소를 통해 열리는지 확인합니다.
- 호스트 이름이 의도한 리버스 프록시로 확인되는지 확인합니다.
- Nginx Proxy Manager가 애플리케이션의 내부 호스트와 포트에 연결할 수 있는지 확인합니다.
- 일반 프록시 라우팅이 작동한 후에만 인증서를 연결합니다.
- 그런 다음 HTTPS를 강제하고 둘 이상의 로컬 클라이언트에서 테스트합니다.
이 순서를 따르면 인증서 문제를 Docker 라우팅 문제나 포트 충돌 문제로 잘못 판단하는 일을 방지할 수 있습니다.
ZimaOS 로컬 HTTPS FAQ
ZimaOS HTTPS 토글을 켜면 Jellyfin도 자동으로 보호되나요?
아니요. ZimaOS 관리 인터페이스만 보호하며, 모든 Docker 애플리케이션을 보호하지는 않습니다.
LAN 전용 HTTPS에도 공개 도메인이 필요한가요?
인증서와 일치하는 호스트 이름이 필요합니다. 해당 호스트 이름은 네트워크 내부에서 사설 LAN 주소로 확인되도록 설정할 수 있습니다.
원 작성자는 왜 ZimaOS를 80번 및 443번 포트에서 다른 포트로 옮겼나요?
Nginx Proxy Manager가 표준 HTTP 및 HTTPS 포트를 필요로 했기 때문입니다. 이 변경은 해당 설치 환경을 위한 커뮤니티 해결 방법이었습니다.
원 작성자의 설정은 정상적으로 작동한다고 확인되었나요?
예. 원 작성자는 인증서가 적용된 NPM 호스트가 온라인 상태인 모습을 보여 주었고 설정이 작동한다고 말했습니다.
