Fix ZimaOS Docker Containers That Cannot Resolve Each Other

If Sonarr, Radarr, Lidarr, Transmission, or other containers on ZimaOS can reach each other by IP address but cannot use stable names such as transmission:9091, the problem is usually name resolution rather than basic container connectivity. That distinction became the key finding in this November 2025 IceWhale Community thread.

Docker's default bridge network does not provide automatic container-name DNS in the same way a user-defined bridge does. The thread then exposed a second ZimaOS-specific complication: manually created bridge networks could exist in Docker before they appeared correctly in the ZimaOS WebUI, and the UI could reject otherwise valid Docker networks because of Compose label expectations.

The Key Symptom: IP Works but Container Name Fails

The original user wanted Radarr to reach Transmission using:

http://transmission:9091

Container IP addresses changed after reboots or updates, so hard-coding them was unreliable. The containers could reach one another by IP but hostname-based calls failed.

Why the Default Docker Bridge Does Not Solve This

Docker's current bridge network documentation says containers on the default bridge can communicate by IP, while user-defined bridges provide automatic DNS resolution between containers.

So “all apps use bridge” does not necessarily mean they are using a named user-defined bridge with Docker's embedded DNS.

Create a User-Defined Bridge

sudo -i
docker network create media-net

Containers attached to the same user-defined bridge can normally resolve one another by container name or network alias.

Current ZimaOS Documentation Uses the Same Pattern

Current ZimaSpace documentation now explicitly uses a custom network in its Zabbix guide because the default bridge does not provide the desired container DNS behavior:

sudo docker network create zabbix-net

See the current ZimaOS Zabbix installation guide.

The ZimaOS-Specific Problem: WebUI Synchronization

In the source thread, creating a custom bridge through Docker or Portainer did not immediately make the network usable from the ZimaOS app settings. Users saw errors such as:

network internal-network was found but has incorrect label
com.docker.compose.network set to ""

After testing with an engineer, Zima-Giorgio said Docker networking itself behaved normally but the WebUI could be out of sync with the Docker backend.

The Community-Confirmed Step: Reboot After Creating the Network

sudo -i
docker network create net-a
docker network create net-b
reboot

After reboot, the newly created networks appeared in the app settings panel. Another participant confirmed that the missing reboot was the key step in their test and that name resolution worked on the custom bridge afterward.

Standard Docker does not normally require rebooting the whole host after docker network create; this was ZimaOS-specific behavior observed in the 2025 thread.

A Compose Label Compatibility Issue Still Remained

Even after reboot clarified the synchronization problem, the thread documented another limitation. ZimaOS could complain that a manually created network had an incorrect com.docker.compose.network label.

Zima-Giorgio ultimately said the inability to choose some created networks appeared to be an issue and would be forwarded to the team. The thread does not contain a later confirmation that every network-selection edge case was fixed.

Verify the Network from Docker, Not Only the UI

docker network inspect media-net
docker inspect CONTAINER_A
docker inspect CONTAINER_B

Then test name resolution from one container:

docker exec CONTAINER_A ping -c 2 CONTAINER_B

If the image does not include ping, use another available diagnostic tool or a temporary test container on the same network.

Use Names or Aliases Instead of Changing IP Addresses

Once Docker DNS works on a user-defined bridge, configure applications with a stable endpoint such as:

http://transmission:9091

or a network alias defined in Compose.

Was Cloudflared the Cause?

The source thread did not identify Cloudflared as the root cause. IP communication already worked and the failure aligned with Docker DNS/name-resolution behavior.

Temporary Workaround: Host IP and Published Ports

The original poster temporarily reserved a static LAN IP for the ZimaOS host and configured apps to use that IP plus published ports. This can work but routes through the host's published-port path rather than clean Docker-internal service-name routing.

ZimaOS Container Name Resolution Checklist

1. Confirm IP-to-IP communication works.
2. Check whether the containers are on the default bridge or a named user-defined bridge.
3. Create a custom bridge when stable DNS is required.
4. Attach all required services to the same custom network.
5. On ZimaOS versions matching the source thread, reboot so the WebUI refreshes its Docker network state.
6. Verify with docker inspect and docker network inspect.
7. Test container-name resolution from inside another container.
8. If ZimaOS reports a Compose label mismatch, treat that as a UI/integration issue rather than proof that Docker's network is invalid.

ZimaOS Docker Bridge FAQ

Why can't containers on bridge resolve each other by name?

Docker's default bridge allows IP communication but does not provide automatic container-name DNS like a user-defined bridge does.

Do I need to reboot after docker network create?

Standard Docker normally does not. In this 2025 ZimaOS thread, rebooting was needed to make the ZimaOS WebUI retrieve the new network state.

Does Cloudflared break Docker bridge DNS?

The source thread did not establish that.

Should I assign static Docker IPs?

Usually no. User-defined Docker DNS and aliases are more portable than hard-coded container IPs.