Docker networking: drivers, DNS, and published ports

Understand user-defined bridge networks, service discovery, port publishing, host networking, and practical checks for container connectivity.

Guance Editorial Team 2026-10-27 4 min read Updated 2026-10-27

Best practices

Illustration of application infrastructure and operations

Docker connects containers through networks managed by network drivers. On a single host, a user-defined bridge is a common starting point: containers on that network can resolve each other by name, while published ports provide an explicit path through the host.

The built-in default bridge does not provide the same automatic name resolution as a user-defined bridge. Keep that distinction in mind when a name works in Compose but fails in a manually launched container.

Compare the common drivers

Driver	Typical use
`bridge`	Single-host container networking; user-defined networks provide a useful boundary between applications
`host`	Shares the Linux Docker host's network namespace; platform-specific support and restrictions apply
`none`	Leaves loopback but removes ordinary external network connectivity; does not isolate files, processes, or the kernel
`overlay`	Cross-host networking with Docker Swarm
`macvlan`	Gives containers identities on an existing layer-2 network for compatible environments

These are common choices, not an exhaustive list; Docker also supports options such as ipvlan. Containers on the same bridge generally can communicate, so “bridge isolation” should not be read as isolation between every member of that bridge.

Create and inspect a network

docker network create appnet
docker run -d --name web --network appnet nginx
# First set POSTGRES_PASSWORD securely in this local learning environment.
docker run -d --name db --network appnet -e POSTGRES_PASSWORD postgres:16

docker exec web getent hosts db
docker network inspect appnet
# Attach an existing container to another network:
docker network connect appnet another-container

Images do not necessarily contain ping, getent, or a shell. Use tools available in the image or an appropriate diagnostic environment. A successful ping only tests one aspect of connectivity; it does not establish that the intended TCP service is accepting requests.

The password environment variable is a limited local example. Use a suitable secrets mechanism for maintained deployments.

Publish a service through the host

# Default host-address binding:
docker run -p 8080:80 nginx

# Separate example: bind the published port to host loopback.
docker run -p 127.0.0.1:8080:80 nginx

These are alternatives, not commands to run together on the same occupied port. Without a host IP, a published port normally binds to all host interfaces. Loopback binding is appropriate when only the local host should reach a development service.

Docker forwarding rules can interact with or bypass expected UFW filtering. Review the actual firewall backend: DOCKER-USER applies to Docker's iptables backend, not as a drop-in rule chain for its native nftables backend. Docker Engine versions before 28.0.0 had a same-layer-2 reachability issue affecting loopback-published ports; use an updated version and verify access from outside the host.

Organize Compose networks

Compose creates a default project network, with service names available for discovery among connected services. A database need not publish a host port for an application on the same network to reach it.

Separate frontend and backend networks when the architecture benefits from it, and attach services only where needed. Omitting ports does not automatically make a network egress-isolated; use the relevant network configuration, such as internal, and verify the required communication paths.

Troubleshoot in order

Confirm that the client and target share an intended network or have a valid routed path.
Resolve the service name from the client environment.
Check the backend's address and port. A listener bound only to its container's loopback is not reachable from another container.
For access through the host, verify published ports and firewall rules. Containers on a shared network use container ports directly and do not require host publishing.

Frequently asked questions

What if a container's IP changes?

Prefer service or container names on a user-defined network, and let clients reconnect and resolve again after replacement. Static IPs have specialized uses, but should not be a default workaround for ordinary service discovery.

What are the drawbacks of host networking?

On Linux Engine, ports can collide with host processes and the container shares the host's network namespace. Port-publishing flags do not apply. Docker Desktop 4.34 and later offer opt-in host networking with layer-4 and interface-access limitations; it is not identical to unrestricted Linux host networking. Measure performance for the actual workload rather than assuming a guaranteed improvement.

How can containers communicate across hosts?

Swarm overlay networking is one supported approach. Kubernetes networking follows its CNI-based design. Other routed, published-port, macvlan, or ipvlan designs may fit particular networks; overlay and macvlan are not the only possible paths. Choose a topology with explicit routing, discovery, and access controls.