この情報源では、ZimaOSダッシュボードをポート80から移動し、リバースプロキシ用にポート80/443を確保し、ローカルDNSレコードを作成して、Nginxのプロキシ先をZimaOSサーバーの静的LAN IPと各アプリの実際のポートに設定する、動作するローカルリバースプロキシ構成が示されています。
重要な設計上の選択は、DNSループを回避することでした。ユーザーのBind9レコードでは、food.sdakのような分かりやすい名前を使用し、一方でNginxのアップストリーム先は、ホスト名を自分自身経由でプロキシするのではなく、ZimaOSの静的IP（例：10.66.66.30:9925）のままにしました。
ZimaOSのWebUIをポート80から移動する
情報源では、ユーザーがZimaOSのWebUIをポート83に変更しました。正確な代替ポートは重要ではありません。未使用のポートを選び、記録しておきましょう。
変更後は、まず直接アクセスを確認します。
http://ZIMA_LAN_IP:83新しいダッシュボードの直接アクセスURLが機能するまで、Nginxを追加しないでください。
ポート443にも同様の計画が必要になる場合がある
コミュニティの回答では、ZimaOSのHTTPS設定は開発者モードにあり、同じく443番ポートを使用するリバースプロキシと競合する可能性があると説明されています。両方を有効にする前に、443番ポートをどのサービスが使用するかを決めてください。
NginxでHTTPSを終端する場合、セキュリティモデルで両方の通信経路にTLSが必要とされない限り、バックエンドはLAN上のプライベートHTTPのままにできます。
リバースプロキシの接続先には安定したLAN IPを使用する
情報源のユーザーはZimaOSホストに静的IPを割り当て、そのアドレスをNginxのアップストリーム設定で使用しました。現在のZimaOSでは、設定 → ネットワークからDHCPまたは手動の静的ネットワーク設定を利用できます。
現在のZimaOSで静的IPを設定する手順をご覧ください。
分かりやすい名前用にローカルDNSレコードを作成する
家庭内専用のDNS名前空間では、可能な限り通常のユニキャストDNSに.localを使用しないでください。このサフィックスは一般的にmDNSで使用されるためです。実際の内部ドメイン、または意図的に管理する別のローカル名前空間を使用しましょう。
NginxをIP:ポートのバックエンドに接続する
これにより、同じプロキシ内部から公開用または分かりやすいホスト名を名前解決して、誤って再びプロキシへトラフィックを送り返すことを防げます。
インタラクティブなアプリのWebSocket/Upgrade通信を維持する
ZimaOSや多くのセルフホストアプリでは、長時間維持されるWebSocket接続またはHTTP Upgrade接続を使用します。リバースプロキシが必要なUpgradeヘッダーを転送しない場合、ページは見た目上読み込まれていても、ライブウィジェットやアプリのダイアログが機能しないことがあります。
これらを必要とするアプリでは、適切なNginx/Nginx Proxy ManagerのWebSocketサポートを使用してください。
ローカルDNSにパブリックインターネットへの公開は必要ない
情報源の目的は、NASをインターネットに公開することではなく、ローカルでの利便性を高めることでした。外部アクセスを認証、証明書、ファイアウォールルール、適切な脅威モデルとともに意図的に設計するのでない限り、プロキシのリスナーとDNSレコードは信頼できるネットワーク内に限定してください。
情報源では再起動によってARP/状態の問題が解消されたが、基本設定ではない
ユーザーはポート変更後にZimaOSとIPFireの両方を再起動し、古いARP/ネットワーク状態が解消されたと報告しました。ただし、これは情報源固有のクリーンアップであり、プロキシを変更するたびに必須となる普遍的な手順ではありません。
Nginxリバースプロキシに関するよくある質問
情報源では、どこでZimaOSのWebUIポートを変更しましたか？
設定 → 一般です。
なぜ情報源では、Nginxの接続先に静的IPを使用したのですか？
DNS/プロキシループを回避し、バックエンドの接続先を確実にするためです。
ローカルリバースプロキシの名前をインターネットに公開する必要はありますか？
いいえ。ローカルDNSを使用すれば、構成全体をLAN内に維持できます。
