Wenn Sonarr, Radarr, Lidarr, Transmission oder andere Container auf ZimaOS sich gegenseitig über IP-Adressen erreichen können, aber keine stabilen Namen wie transmission:9091liegt das Problem normalerweise bei der Namensauflösung und nicht bei der grundlegenden Container-Konnektivität. Diese Unterscheidung erwies sich als zentrale Erkenntnis in diesem IceWhale-Community-Thread vom November 2025.
Die standardmäßige Docker- bridge Das Netzwerk bietet nicht automatisch die DNS-Auflösung von Containernamen auf dieselbe Weise wie eine benutzerdefinierte Bridge. Im weiteren Verlauf des Threads zeigte sich außerdem eine zweite ZimaOS-spezifische Komplikation: Manuell erstellte Bridge-Netzwerke konnten in Docker vorhanden sein, bevor sie korrekt in der ZimaOS-WebUI angezeigt wurden, und die Benutzeroberfläche konnte ansonsten gültige Docker-Netzwerke aufgrund der von Compose erwarteten Labels ablehnen.
Das zentrale Symptom: IP funktioniert, aber der Containername nicht
Der ursprüngliche Nutzer wollte, dass Radarr Transmission über Folgendes erreicht:
http://transmission:9091
Die IP-Adressen der Container änderten sich nach Neustarts oder Aktualisierungen, sodass ihre feste Verwendung unzuverlässig war. Die Container konnten sich über ihre IP-Adressen erreichen, aber Verbindungen über Hostnamen schlugen fehl.
Warum die standardmäßige Docker-Bridge dieses Problem nicht löst
In der aktuellen Dokumentation zu Docker-Bridge-Netzwerken heißt es, dass Container im Standard-Bridge-Netzwerk über ihre IP-Adresse kommunizieren können, während benutzerdefinierte Bridges eine automatische DNS-Auflösung zwischen Containern ermöglichen.
„Alle Apps verwenden die Bridge“ bedeutet also nicht unbedingt, dass sie eine benannte benutzerdefinierte Bridge mit dem integrierten Docker-DNS verwenden.
Eine benutzerdefinierte Bridge erstellen
sudo -i
docker network create media-net
Container, die mit derselben benutzerdefinierten Bridge verbunden sind, können sich normalerweise über den Containernamen oder Netzwerkalias auflösen.
Die aktuelle ZimaOS-Dokumentation verwendet dasselbe Muster
In der aktuellen ZimaSpace-Dokumentation wird in der Zabbix-Anleitung nun ausdrücklich ein benutzerdefiniertes Netzwerk verwendet, da die Standard-Bridge nicht das gewünschte DNS-Verhalten für Container bietet:
sudo docker network create zabbix-net
Siehe die aktuelle ZimaOS-Anleitung zur Installation von Zabbix.
Das ZimaOS-spezifische Problem: WebUI-Synchronisierung
Im Quellthread wurde ein benutzerdefiniertes Bridge-Netzwerk, das über Docker oder Portainer erstellt wurde, in den App-Einstellungen von ZimaOS nicht sofort nutzbar. Nutzer sahen Fehler wie:
Das Netzwerk internal-network wurde gefunden, weist aber ein falsches Label auf
com.docker.compose.network set to ""
Nach Tests mit einem Entwickler sagte Zima-Giorgio, dass die Docker-Netzwerkfunktion selbst normal arbeitete, die WebUI jedoch möglicherweise nicht mit dem Docker-Backend synchronisiert war.
Der von der Community bestätigte Schritt: Neustart nach dem Erstellen des Netzwerks
sudo -i
docker network create net-a
docker network create net-b
Neustart
Nach dem Neustart erschienen die neu erstellten Netzwerke im Einstellungsbereich der App. Ein weiterer Teilnehmer bestätigte, dass der fehlende Neustart in seinem Test der entscheidende Schritt war und die Namensauflösung anschließend über die benutzerdefinierte Bridge funktionierte.
Standard-Docker erfordert normalerweise keinen Neustart des gesamten Hosts nach docker network create; dies war ein ZimaOS-spezifisches Verhalten, das im Thread von 2025 beobachtet wurde.
Ein Kompatibilitätsproblem mit Compose-Labels blieb weiterhin bestehen
Auch nachdem der Neustart das Synchronisierungsproblem geklärt hatte, dokumentierte der Thread eine weitere Einschränkung. ZimaOS konnte melden, dass ein manuell erstelltes Netzwerk ein falsches com.docker.compose.network Label.
Zima-Giorgio sagte letztlich, dass die fehlende Möglichkeit, einige erstellte Netzwerke auszuwählen, offenbar ein Problem sei und an das Team weitergeleitet werde. Der Thread enthält keine spätere Bestätigung, dass jeder Sonderfall bei der Netzwerkauswahl behoben wurde.
Netzwerk in Docker überprüfen, nicht nur in der Benutzeroberfläche
docker network inspect media-net
docker inspect CONTAINER_A
docker inspect CONTAINER_B
nicht enthält, teste anschließend die Namensauflösung von einem Container aus:
docker exec CONTAINER_A ping -c 2 CONTAINER_B
Wenn das Image ping, verwende ein anderes verfügbares Diagnosetool oder einen temporären Testcontainer im selben Netzwerk.
Namen oder Aliase verwenden, anstatt IP-Adressen zu ändern
Sobald Docker-DNS in einer benutzerdefinierten Bridge funktioniert, konfiguriere Anwendungen mit einem stabilen Endpunkt wie:
http://transmission:9091
oder ein in Compose definierter Netzwerkalias.
War Cloudflared die Ursache?
Im Quellthread wurde Cloudflared nicht als Grundursache identifiziert. Die IP-Kommunikation funktionierte bereits, und der Fehler entsprach dem DNS-/Namensauflösungsverhalten von Docker.
Vorübergehende Problemumgehung: Host-IP-Adresse und veröffentlichte Ports
Der ursprüngliche Beitragende reservierte vorübergehend eine statische LAN-IP-Adresse für den ZimaOS-Host und konfigurierte die Apps so, dass sie diese IP-Adresse zusammen mit veröffentlichten Ports verwenden. Das kann funktionieren, führt jedoch über den Pfad der vom Host veröffentlichten Ports statt über ein direktes Routing zu Docker-internen Dienstnamen.
Checkliste zur Auflösung von Containernamen in ZimaOS
- Bestätige, dass die Kommunikation von IP zu IP funktioniert.
- Prüfe, ob sich die Container in der standardmäßigen Bridge oder in einer benannten, benutzerdefinierten Bridge befinden.
- Erstelle eine benutzerdefinierte Bridge, wenn stabiles DNS erforderlich ist.
- Verbinde alle erforderlichen Dienste mit demselben benutzerdefinierten Netzwerk.
- Starte bei ZimaOS-Versionen, die dem Quellthread entsprechen, das System neu, damit die WebUI den Status ihres Docker-Netzwerks aktualisiert.
- Überprüfe dies mit
docker inspectunddocker network inspect. - Teste die Auflösung von Containernamen innerhalb eines anderen Containers.
- Wenn ZimaOS eine Abweichung bei den Compose-Labels meldet, sollte dies als UI-/Integrationsproblem und nicht als Beweis dafür betrachtet werden, dass das Docker-Netzwerk ungültig ist.
FAQ zur Docker-Bridge in ZimaOS
Warum können Container in der Bridge einander nicht über den Namen auflösen?
Die standardmäßige Docker-Bridge ermöglicht IP-Kommunikation, bietet aber keine automatische DNS-Auflösung von Containernamen wie eine benutzerdefinierte Bridge.
Muss ich nach docker network create neu starten?
Standard-Docker tut das normalerweise nicht. In diesem ZimaOS-Thread von 2025 war ein Neustart erforderlich, damit die ZimaOS-WebUI den neuen Netzwerkstatus abrufen konnte.
Beeinträchtigt Cloudflared das Docker-Bridge-DNS?
Im Quellthread wurde das nicht festgestellt.
Sollte ich statische Docker-IP-Adressen vergeben?
Normalerweise nicht. Benutzerdefiniertes Docker-DNS und Aliase sind portabler als fest codierte Container-IP-Adressen.
