ZimaOSダッシュボードでHTTPSを有効にしても、Jellyfin、Vaultwarden、Nginx Proxy Manager、その他すべてのDockerアプリケーションにHTTPSアドレスが自動的に付与されるわけではありません。この誤解が、2026年2月に始まったこのスレッドのきっかけでした。ユーザーはZimaOSの設定でHTTPSを有効にし、ZimaOSインターフェース用に生成された証明書を保存してNginx Proxy Managerへインポートしようとしましたが、JellyfinとNPMは期待どおりに動作しませんでした。
最終的にスレッドでは、コミュニティによる動作する構成にたどり着きました。個々のアプリケーションのTLS終端ポイントとしてNginx Proxy Managerを使用し、リバースプロキシで80番および443番ポートが必要な場合はZimaOSゲートウェイをこれらのポートから移動し、DuckDNSでホスト名を設定して、そのホスト名用の証明書を発行します。その後、元のユーザーはプロキシホストがオンラインになっているスクリーンショットを投稿し、動作したと結果をまとめました。
3つの異なるHTTPSレイヤーを理解する
混同しやすいものが3つあります。
- 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がそのホスト名をプライベートアドレスへ解決します。
自己署名証明書も選択肢だが、信頼設定が必要
コミュニティの返信の1つでは、OpenSSLで証明書を生成し、Nginx Proxy Managerへインポートする方法が提案されました。完全にローカルで使用する場合は機能しますが、ブラウザーやデバイスは自己署名証明書を自動的には信頼しません。正常なHTTPS接続として表示させたいすべてのクライアントで、発行証明書またはローカルCAを信頼する必要があります。
複数のスマートフォン、テレビ、タブレット、アプリを使う家庭では、各デバイスにローカル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ホストがオンラインになっていることを示し、構成が動作したと述べています。
