Docker Compose Network Not Resolving Between Containers

by

When containers in a Docker Compose setup can’t reach each other by name — for example, your app container failing to connect to a database container using its service name — the cause is almost always related to how Compose networks and DNS resolution work, not a broken Docker installation. This is one of the more confusing Docker Compose issues because everything looks correct in the compose file at first glance.

The Problem

Your docker-compose.yml defines multiple services, say app and db, and your application tries to connect to the database using a hostname like db or db:5432. Instead of connecting, you get errors like:

getaddrinfo ENOTFOUND db
could not translate host name "db" to address
Name or service not known

Pinging the service by name from inside the container fails, even though both containers are clearly running and both `docker ps` and `docker compose ps` show everything as healthy.

Why It Happens

Docker Compose automatically creates a network for your project and connects every service defined in the same docker-compose.yml to it, using the service name as a resolvable hostname through Docker’s built-in embedded DNS server. When name resolution fails between containers, it’s usually one of these:

  • The containers are actually on different networks (common when running multiple docker-compose.yml files, or mixing docker run with docker compose up, which don’t share the same default network)
  • A custom network is defined in the compose file, but one of the services isn’t explicitly attached to it, so it falls back to a different default network
  • The service you’re trying to reach hasn’t fully started yet, so the name isn’t resolvable at the moment the connection is attempted — this is especially common with databases that take a few seconds to accept connections after the container itself reports as “running”
  • You’re using the container’s exposed host port instead of its internal port when connecting from another container, mixing up host-mapped ports with internal container ports (these are two completely different things in Docker’s networking model)

The Fix

First, confirm both containers are actually on the same network before changing anything else:

docker network ls
docker network inspect <network_name>

The output should list both containers under the same network. If they’re not, check your docker-compose.yml for an explicit networks section — if one service defines a custom network, every service that needs to talk to it must be attached to that same network:

services:
  app:
    networks:
      - backend
  db:
    networks:
      - backend

networks:
  backend:

Next, test resolution directly from inside a running container, rather than assuming it works based on the compose file alone:

docker compose exec app ping db
docker compose exec app getent hosts db

If this fails, restart the stack cleanly to force Compose to rebuild the network from scratch, which resolves stale network state left over from previous runs or renamed services:

docker compose down
docker compose up -d

Also double-check that your connection string uses the internal container port, not the host-mapped port from the ports section. For example, if your compose file has ports: ["5433:5432"], other containers should still connect using port 5432, since that mapping only affects access from the host machine, not container-to-container traffic — the internal Docker network always uses the container’s own exposed port regardless of any host port remapping.

Still Not Working?

If the containers are confirmed to be on the same network and still can’t resolve each other, check whether the depending service is starting before the one it needs is ready. Adding a depends_on with a healthcheck condition ensures one service waits until the other is actually accepting connections, not just started:

depends_on:
  db:
    condition: service_healthy

Without a healthcheck condition, depends_on only waits for the container to start, not for the application inside it to be ready — which is a very common source of intermittent “works sometimes, fails other times” connection issues in Compose setups.

Leave a Comment