Inside a container, localhost points back to that container—not to your computer or another container. For two services on the same Docker Compose network, connect using the destination service’s name and its container port, such as db:5432. Publish a port when a service needs to be reached from the Docker host or another network; for a container connecting to the host on Docker Desktop, use host.docker.internal.
Why can’t a Docker container connect to localhost?
localhost is the loopback address for the network namespace where a process runs. A process in a container therefore reaches that container when it connects to localhost. It does not reach a separate database container or a service running on the host just because those services are on the same physical machine.
As an Amazon Associate I earn from qualifying purchases.
The right address depends on where the client process runs and where the destination service runs:
| Client | Destination | Address to use | Port path |
|---|---|---|---|
| Compose service | Another service on the same network | Service name, such as db |
Destination container port, such as 5432 |
| Docker host | Container service | localhost or the host address |
Published host port, such as 8001 |
| Container on Docker Desktop | Service running on the host | host.docker.internal |
The host service’s listening port |
| Container | Service on a separate isolated Docker network | Attach both to a shared network, or publish a port where appropriate | Depends on the chosen route |
For example, a Compose app connecting to a PostgreSQL service named db should use a URL such as postgres://db:5432, not localhost:5432. A browser on the host might instead use localhost:8001 if the container’s port 80 is published as host port 8001.
#1 Best Overall
How do Docker bridges and Compose DNS work?
Default bridge versus a user-defined bridge
Docker creates a default bridge network named bridge for containers that do not specify another network. Docker’s user-defined bridge networks are generally a better fit for application services: containers attached to the same user-defined bridge can communicate, and Docker provides automatic name resolution between them. On the default bridge, containers generally need IP addresses to reach one another unless legacy links are used.
A bridge is also a network boundary. Containers on the same bridge can communicate with each other; separate networks are isolated by default. A service on a different network cannot ordinarily reach an unpublished container port just because both containers run on the same host.
Compose service names are the stable destination
Compose creates a project network by default and connects the project’s services to it. A peer can reach a service by its Compose service name and the destination’s container port—for example, web:80 or db:5432. Docker’s Compose networking documentation explains: “Each container can now look up the service name web or db and get back the appropriate container’s IP address.”
Use the service name in application configuration rather than pinning a container IP. When Compose recreates a service, its new container may receive a different IP while keeping the same service name. The old connection closes; a client should detect the failure, resolve the service name again, and reconnect.
Use multiple networks to limit which services can communicate
A Compose project can define multiple networks and attach each service only to the networks it needs. For example, an application might join both a frontend and a backend network, while a proxy and database join only the network needed for their respective connections. This makes network membership an explicit part of the application’s reachability design.
Do you need to publish a port for container-to-container communication?
No—not when both containers are on the same user-defined bridge or Compose network. The client can connect directly to the destination service name and container port. Adding a ports: entry is not the usual fix for one Compose service failing to reach another; check that they share a network and that the client uses the correct service name and container port.
Port publishing maps a host port to a container port. For example, -p 8080:80 forwards host TCP port 8080 to container port 80. The host can then reach the service through its published port. Docker’s port publishing documentation describes how published ports expose container services through host networking.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
On a bridge network, a container port is ordinarily available to the Docker host and containers on that same network. It is not ordinarily available to unrelated networks or remote machines unless you publish it or configure direct routing.
Bind published ports deliberately
Without a specific host IP, a published port binds on all host addresses by default. For local development where access should be limited to the Docker host, bind to loopback explicitly:
Rank #4
docker run -p 127.0.0.1:8080:80 IMAGE
Docker documents a caveat for Engine versions before 28.0.0: in some circumstances, machines on the same layer-2 network could reach ports published to localhost. Account for that version-specific behavior when relying on a loopback-only binding as an exposure boundary.
How can a container reach a service running on the host?
Docker Desktop
For a container on Docker Desktop, use host.docker.internal as the host name, followed by the port on which the host service listens—for example, host.docker.internal:3000. Docker Desktop documents this name for container-to-host access. Its networking runs through a backend and VM, so the host may not expose a Linux-style docker0 interface for direct inspection. See Docker’s Docker Desktop networking documentation.
Linux Docker Engine
On Linux, Compose documents using the host-gateway value in extra_hosts to add a host mapping such as host.docker.internal. Check the host service’s bind address and firewall too: if the service listens only on the host’s loopback interface, it may not accept connections arriving through the bridge gateway.
When should you use host networking?
In host network mode, a container shares the host’s network stack. Port publishing is unnecessary and unsupported in this mode, and Compose service-name DNS does not work. Docker describes host networking as useful for specialized cases such as system-level network monitoring; it is not a general-purpose solution to a mistaken localhost address.
For ordinary Compose applications, use the project bridge network and service-name DNS. That preserves the separation between the host and container networks while giving services a stable name for peer connections.
Quick Recap
How to troubleshoot Docker networking step by step
- Locate the client process. Determine whether the application making the connection runs on the host, inside a container, or inside a Docker Desktop container. The correct meaning of
localhostfollows the client’s network namespace. - For container-to-container traffic, check the network and address. Confirm both containers share a network. Use the target’s Compose service name plus its container port, not its host-published port or a remembered IP address.
- For host-to-container traffic, check the published mapping. Confirm the container is running, the host port maps to the intended container port, and the mapping’s host bind address allows the client’s route.
- For container-to-host traffic, use the platform’s host route. On Docker Desktop, try
host.docker.internal. On Linux, configure and verify a host-gateway mapping if needed, then check the host listener’s bind address and firewall. - After service recreation, reconnect by name. A container’s IP can change when it is recreated. Drop the failed connection, resolve the service name again, and reconnect rather than retaining the former IP.
- Inspect network membership and host mappings. Use
docker network inspect NETWORKto check which containers belong to a network. Inspect the container’s/etc/hostswhen validating injected host mappings.
Which Docker networking mode fits the connection?
| Choice | Good fit | Naming and port behavior | Key limitation |
|---|---|---|---|
| Default bridge | Containers without an explicitly selected network | Containers generally use IP addresses to reach each other | Does not provide the user-defined bridge’s automatic DNS behavior |
| User-defined bridge | Related containers that should communicate on a defined network | Docker DNS resolves container names on that network; peer traffic uses container ports | Other networks are isolated by default |
| Compose project network | Services in a Compose application | Services resolve one another by service name and use container ports | Recreated containers can receive new IPs, so clients must reconnect |
| Host network mode | Specialized cases that need the host network stack | Shares the host stack; port mapping is not used | Compose service-name DNS does not work |
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
