Docker がコンテナに 172.x のブリッジアドレスを割り当てるからといって、UniFi Network Application に専用の 192.168.x.x アドレスが必要になるわけではありません。通常のブリッジモードでは、必要なホストポートを公開し、UniFi の Inform Host に LAN から到達可能なホスト名または IP アドレスを設定します。LAN 上のデバイスはホストのアドレスと通信し、Docker はコンテナをプライベートネットワーク内に保持します。
2026 年の元スレッドでは、コンテナ内部のブリッジ IP と、LAN デバイスが使用すべきアドレスが混同されていました。現在の LinuxServer ドキュメントでは、この点が明確に説明されています。UniFi コンテナはブリッジモードのまま使用でき、アクセス可能な Inform Host を設定し、ポート 8080 を維持することでデバイスの採用を行えます。
172.x アドレスが表示される理由
Docker のブリッジネットワークでは通常、172.17.x.x のようなプライベートなコンテナアドレスが割り当てられます。このアドレスはコンテナ間のネットワーク通信に使用するものであり、物理 LAN 上のスイッチやアクセスポイントが使用するアドレスではありません。
公開ポートには ZimaOS ホストの IP アドレスを使用する
ZimaOS サーバーが 192.168.1.20 で、UniFi が 8443 と 8080 を公開している場合、UI と Inform エンドポイントにはホスト経由でアクセスします。
https://192.168.1.20:8443
http://192.168.1.20:8080/informUniFi の Inform Host を設定する
現在の LinuxServer の UniFi ドキュメントでは、Docker ユーザーは UniFi デバイスから到達可能なホスト名または IP アドレスを Inform Host/Override に設定するよう案内されています。
通常は、ZimaOS の LAN IP アドレス、または安定したローカル DNS 名を指定します。
ポート 8080 は 1 対 1 でマッピングする
LinuxServer は、UniFi デバイスとの通信では、UniFi のシステムプロパティ内でも対応する変更を行わない限り、8080:8080 が必要だと警告しています。ホスト側の 18080 をコンテナの 8080 に割り当てても、デバイスの採用が安定して維持されるとは限りません。
ホストモードは「コンテナに専用の LAN IP を与える」ことと同じではない
Docker のホストモードでは、コンテナがホストのネットワーク名前空間を共有します。コンテナに 2 つ目の 192.168.x.x アドレスが作成されるわけではありません。
本当に別の LAN IP が必要な場合は、macvlan/ipvlan 構成を使用することになりますが、ルーティングやホストとコンテナ間の通信に関する注意点が増えます。
通常はブリッジモードがより簡単
ブリッジモードではアプリが分離され、ポートの所有関係が明確になり、ドキュメントに記載された Inform Host のオーバーライドも利用できます。多くの環境では、コントローラーによるデバイスの採用と管理にこれで十分です。
外部 MongoDB の要件を忘れない
現在の LinuxServer UniFi Network Application では、外部 MongoDB インスタンスが必要です。ホストモードで失敗し、ブリッジモードでは動作する場合は、選択したネットワークモードでも MongoDB のホスト名とネットワーク経路が有効であることを確認してください。
コントローラーをインターネットに直接公開しない
管理アクセスは LAN 内に限定するか、プライベートなリモートアクセスネットワークの背後に置いてください。プライベートネットワークガイドでは、より安全なネットワーク構成について説明しています。
安定したホストアドレスを使用する
採用済みのデバイスにはコントローラーの場所が通知されるため、ルーターの DHCP 予約、または適切に管理された固定アドレスによって、ZimaOS ホストに安定した LAN IP を割り当ててください。コントローラーのホストが 192.168.1.20 から別のアドレスに変わると、デバイスが古い Inform エンドポイントへの接続を続ける可能性があります。
各ポートの用途を理解する
8443 の UniFi Web インターフェースは、構成要素の 1 つにすぎません。デバイスの Inform 通信には 8080 が使用され、その他の検出や STUN サービスには、構成によって追加のポートが使用されます。そのため、ブラウザーではコントローラーが正常に見えても、デバイスの採用に失敗することがあります。
現在の LinuxServer のポート一覧を使用し、環境に必要なポートだけを公開してください。ただし、デバイス管理に必要なポートは正確に維持してください。
Synology からの復元は慎重に行う
コントローラーを Synology から移行する場合は、新しい ZimaOS コンテナと外部 MongoDB が正常に動作していることを確認してから、UniFi のバックアップを復元してください。その後、古いコントローラーを停止する前に、Inform Host とデバイスの状態を確認します。
移行中に、同じサイトやデバイスを要求するアクティブなコントローラーを 2 台同時に実行しないでください。実行する場合は、採用への影響を十分に理解している必要があります。
専用の LAN IP が実際に役立つ場合
macvlan/ipvlan アドレスは、厳密なファイアウォール分離、ポート競合の回避、またはコントローラーを別のアプライアンスのように見せる場合に役立ちます。Docker に 172.x の内部アドレスが表示されるというだけで必要になるものではありません。
macvlan を選択する場合は、一般的なホストと macvlan 間の通信制限を考慮し、MongoDB にコントローラーネットワークから到達できることを確認してください。
FAQ
UniFi コンテナには 192.168 の LAN IP が必要ですか？
いいえ。多くの環境では、ブリッジモードに公開ポートと到達可能な Inform Host を組み合わせれば十分です。
Docker で UniFi デバイスの採用に失敗するのはなぜですか？
よくある原因は、到達できないコンテナ IP を通知していることです。Inform Host には、ZimaOS の LAN アドレス、または別の到達可能なホスト名を設定してください。
ホストネットワークを使用すべきですか？
理由がある場合に限って使用してください。ホストモードでは ZimaOS ホストのネットワークを共有しますが、専用の LAN IP が作成されるわけではありません。
macvlan はいつ使用すべきですか？
コンテナに本当に独自の LAN 上の識別情報が必要で、追加のルーティングやホストからのアクセスに関する複雑さを理解している場合に限って使用してください。
