Docker Networking: Bridge vs Host vs Overlay

Docker provides three main network drivers, and choosing the wrong one is the most common reason containers cannot communicate or performance is unexpectedly poor.

Bridge — the default for single-host communication

• Every Docker installation creates a default bridge network; containers on the same bridge can reach each other by IP, but not by name — user-defined bridge networks enable DNS-based service discovery, which is why you should always create a named bridge and never rely on the default
• Create a user-defined bridge with docker network create app-network; containers on it resolve each other by container name — http://postgres:5432 works from a Spring Boot container if both containers join the same named bridge
• The default bridge network requires you to use --link (deprecated) for name resolution, which is why Docker Compose creates a project-specific network by default

Host — for performance-sensitive workloads

• --network host removes the network namespace boundary; the container uses the host's network stack directly — no NAT, no port mapping overhead, but the container shares the host's IP and port space
• A container on host networking binds ports directly on the host; two containers cannot both bind port 8080 on the same host network
• Appropriate for high-throughput, latency-sensitive workloads where NAT overhead is measurable — avoid it for most application containers because it reduces isolation

Overlay — for multi-host communication

• Overlay networks span multiple Docker hosts using VXLAN encapsulation; they are the foundation of Docker Swarm and Kubernetes pod networking
• Services on a Swarm overlay network communicate using the service name as hostname across any node in the cluster — the routing mesh handles which container on which host receives the request
• A misconfigured overlay is usually a firewall rule issue: UDP port 4789 (VXLAN) and TCP port 7946 (control plane) must be open between all nodes