ZimaOS上のSonarr、Radarr、Lidarr、TransmissionなどのコンテナがIPアドレスでは相互に到達できるのに、次のような安定した名前を使用できない場合 transmission:9091、基本的なコンテナ接続ではなく、通常は名前解決が問題です。この違いが、2025年11月のIceWhale Communityスレッドで重要な発見となりました。
Dockerのデフォルト bridge ネットワークでは、ユーザー定義ブリッジと同じ方法でコンテナ名の自動DNSが提供されません。このスレッドではさらに、手動で作成したブリッジネットワークがDocker上には存在していてもZimaOSのWebUIに正しく表示されるまで時間がかかる場合があり、Composeのラベル要件によって、UIが本来有効なDockerネットワークを拒否することがあるという、ZimaOS固有の別の問題も明らかになりました。
主な症状：IPでは動作するが、コンテナ名では失敗する
元のユーザーは、RadarrからTransmissionへ次の方法で接続することを望んでいました。
http://transmission:9091コンテナのIPアドレスは再起動やアップデート後に変わるため、ハードコードする方法は信頼できませんでした。コンテナ同士はIPで到達できましたが、ホスト名ベースの呼び出しは失敗しました。
Dockerのデフォルトブリッジではこの問題を解決できない理由
Dockerの現在のブリッジネットワークのドキュメントによると、デフォルトのブリッジ上のコンテナはIPアドレスで通信できますが、ユーザー定義ブリッジではコンテナ間の自動DNS解決が提供されます。
したがって、「すべてのアプリがbridgeを使用する」ことは、必ずしもDockerの組み込みDNSを備えた名前付きユーザー定義ブリッジを使用していることを意味しません。
ユーザー定義ブリッジを作成する
sudo -i
docker network create media-net同じユーザー定義ブリッジに接続されたコンテナは、通常、コンテナ名またはネットワークエイリアスで相互に名前解決できます。
現在のZimaOSドキュメントでも同じパターンを使用
現在のZimaSpaceドキュメントでは、デフォルトのブリッジでは期待するコンテナDNSの動作が得られないため、Zabbixガイドでカスタムネットワークを明示的に使用しています。
sudo docker network create zabbix-net最新のZimaOS Zabbixインストールガイドを参照してください。
ZimaOS固有の問題：WebUIの同期
元のスレッドでは、DockerまたはPortainerでカスタムブリッジを作成しても、ZimaOSアプリの設定からすぐにそのネットワークを使用できるようにはならないと説明されていました。ユーザーには次のようなエラーが表示されました。
ネットワーク internal-network が見つかりましたが、ラベルが正しくありません
com.docker.compose.network set to ""エンジニアとのテスト後、Zima-GiorgioはDockerのネットワーク自体は正常に動作しているものの、WebUIがDockerバックエンドと同期していない可能性があると述べました。
コミュニティで確認された手順：ネットワーク作成後に再起動する
sudo -i
docker network create net-a
docker network create net-b
再起動再起動後、新しく作成したネットワークがアプリ設定パネルに表示されました。別の参加者も、自身のテストでは再起動していなかったことが重要な手順だったと確認し、その後はカスタムブリッジ上で名前解決が機能しました。
標準のDockerでは通常、次の後にホスト全体を再起動する必要はありません。 docker network createこれは、2025年のスレッドで確認されたZimaOS固有の動作です。
Composeラベルの互換性問題がまだ残っていた
再起動によって同期の問題が明確になった後も、スレッドでは別の制限が記録されていました。ZimaOSでは、手動で作成したネットワークに誤った com.docker.compose.network ラベル。
最終的にZima-Giorgioは、作成したネットワークの一部を選択できない問題は不具合のようで、チームに報告すると述べました。このスレッドには、ネットワーク選択に関するすべてのエッジケースが修正されたという後日の確認はありません。
ネットワークはUIだけでなくDockerから確認する
docker network inspect media-net
docker inspect CONTAINER_A
docker inspect CONTAINER_B次に、1つのコンテナから名前解決をテストします。
docker exec CONTAINER_A ping -c 2 CONTAINER_Bイメージに次のコマンドが含まれていない場合 ping、別の利用可能な診断ツール、または同じネットワーク上の一時テストコンテナを使用します。
IPアドレスを変更する代わりに名前またはエイリアスを使用する
ユーザー定義ブリッジでDocker DNSが機能するようになったら、次のような安定したエンドポイントを使うようアプリケーションを設定します。
http://transmission:9091またはComposeで定義したネットワークエイリアス。
Cloudflaredが原因でしたか？
元のスレッドでは、Cloudflaredが根本原因だとは特定されていません。IP通信はすでに機能しており、問題はDockerのDNSおよび名前解決の動作と一致していました。
一時的な回避策：ホストIPと公開ポート
元の投稿者は、ZimaOSホスト用に固定LAN IPを一時的に予約し、そのIPと公開ポートを使用するようアプリを設定しました。これは機能する場合がありますが、Docker内部の安定したサービス名ルーティングではなく、ホストの公開ポート経由の経路を使用します。
ZimaOSコンテナ名解決チェックリスト
- IPアドレス間の通信が機能することを確認します。
- コンテナがデフォルトブリッジ上にあるか、名前付きのユーザー定義ブリッジ上にあるかを確認します。
- 安定したDNSが必要な場合は、カスタムブリッジを作成します。
- 必要なすべてのサービスを同じカスタムネットワークに接続します。
- 元のスレッドに対応するZimaOSバージョンでは、WebUIがDockerネットワークの状態を更新するよう再起動してください。
- 次のコマンドで確認します
docker inspectおよびdocker network inspect. - 別のコンテナ内からコンテナ名の解決をテストします。
- ZimaOSがComposeラベルの不一致を報告する場合、それはDockerネットワークが無効である証拠ではなく、UIまたは統合に関する問題として扱ってください。
ZimaOS DockerブリッジFAQ
ブリッジ上のコンテナ同士が名前で解決できないのはなぜですか？
DockerのデフォルトブリッジではIP通信は可能ですが、ユーザー定義ブリッジのようにコンテナ名を自動でDNS解決する機能はありません。
docker network createの後に再起動する必要がありますか？
標準のDockerでは通常、そのようなことはありません。この2025年のZimaOSスレッドでは、ZimaOS WebUIが新しいネットワーク状態を取得できるようにするため、再起動が必要でした。
CloudflaredによってDockerブリッジのDNSが機能しなくなりますか？
元のスレッドでは、その点は明らかにされていません。
Dockerに固定IPを割り当てるべきですか？
通常は不要です。ユーザー定義のDocker DNSとエイリアスのほうが、ハードコードされたコンテナIPより移植性に優れています。
