Quick Summary
- Bridge mode (default) creates an isolated virtual network on the host with NAT for outbound traffic
- Host mode removes network isolation -- the container shares the host's network stack directly
- Overlay mode creates a virtual network spanning multiple Docker hosts for Swarm or multi-host setups
Why Docker Networking Matters
When you run a container, Docker does not just isolate the filesystem and processes -- it also isolates the network. Each container gets its own network namespace with its own IP address, routing table, and network interfaces. This isolation is powerful: containers cannot accidentally interfere with each other's network connections, and you can run multiple containers that all listen on port 80 without conflicts.
But isolation creates a challenge: how do containers communicate with each other and with the outside world? Docker solves this with network drivers -- pluggable modules that define how containers connect to networks. The three most important drivers are bridge (the default, for single-host communication), host (for maximum performance), and overlay (for multi-host communication in Docker Swarm or similar orchestrators).
Understanding these drivers is essential for anyone deploying containerized applications. Choosing the wrong driver can cause containers to be unable to communicate, expose services unintentionally, or create performance bottlenecks. The right choice depends on your deployment model: single host, multi-host cluster, or cloud-native architecture.
Interactive: Network Mode Comparison
Click each mode to see how the network architecture changes. Notice how containers connect to the host and to each other differently in each mode.
The Three Network Drivers
Bridge Network (Default)
When you run a container without specifying a network, Docker attaches it to the default bridge network (docker0). Docker creates a virtual Ethernet bridge on the host, and each container gets a virtual Ethernet interface (veth pair) connected to this bridge. Containers on the same bridge can communicate using their container IP addresses. To reach the outside world, Docker uses iptables NAT rules to masquerade container traffic behind the host's IP. External access to containers requires explicit port mapping (-p 8080:80), which creates iptables DNAT rules forwarding host ports to container ports.
Host Network
With --network host, the container shares the host's network namespace entirely. There is no network isolation -- the container uses the host's IP address, the host's routing table, and binds directly to the host's network interfaces. If the container listens on port 80, it is accessible on the host's port 80 with zero overhead. This eliminates the performance cost of NAT and veth pairs, making it ideal for network-sensitive applications (like load balancers or monitoring tools). The tradeoff: no isolation means port conflicts are possible, and the container can see all host network traffic.
Overlay Network
Overlay networks create a virtual Layer 2 network that spans multiple Docker hosts. They use VXLAN tunneling to encapsulate container traffic inside UDP packets, allowing containers on different physical machines to communicate as if they were on the same local network. Docker Swarm creates overlay networks automatically for services. Each container gets an IP from the overlay subnet, and Docker handles the encapsulation, routing, and encryption transparently. Overlay networks are essential for multi-host deployments but add slight latency due to encapsulation overhead.
User-Defined Bridge Networks
Docker's default bridge network (docker0) has limitations: containers can only communicate by IP address, not by name. User-defined bridge networks solve this with automatic DNS resolution -- containers can reach each other by container name. Create one with docker network create my-net, then attach containers with --network my-net. User-defined bridges also provide better isolation (containers on different bridges cannot communicate) and allow you to configure subnet ranges, gateways, and other network parameters.
In docker-compose, every project automatically gets its own user-defined bridge network. This means containers defined in the same docker-compose.yml can communicate by service name. If you define a service called "db" and another called "web," the web container can connect to the database at hostname "db" -- no IP addresses needed. This is one of docker-compose's most valuable features for development environments.
Port Mapping and Exposure
-p 8080:80
Maps host port 8080 to container port 80. External clients connect to host:8080, and Docker forwards the traffic to the container's port 80. This is the standard way to expose services in bridge mode.
-p 0.0.0.0:8080:80
Explicitly binds to all interfaces. By default, -p binds to 0.0.0.0 (all interfaces). You can restrict it to localhost with -p 127.0.0.1:8080:80 to prevent external access -- important for development databases.
EXPOSE vs. -p
EXPOSE in a Dockerfile is documentation only -- it does NOT publish the port. Only the -p flag at runtime actually creates the port mapping. EXPOSE tells operators which ports the application uses but does not affect networking.
Container DNS
Docker runs an embedded DNS server at 127.0.0.11 inside every container on user-defined networks. This DNS server resolves container names and service names to their current IP addresses. When a container restarts with a new IP, the DNS records are updated automatically. This built-in service discovery is simple but effective for single-host deployments. For multi-host setups, Docker Swarm's DNS resolves service names to the virtual IPs of Swarm services, load-balancing across all replicas.
Common Docker Networking Mistakes
Using Default Bridge for Production
The default bridge lacks DNS resolution, has weaker isolation, and shares a single network with all containers. Always create user-defined bridge networks for production workloads. It takes one extra command and solves multiple problems.
Exposing Ports to 0.0.0.0
Publishing ports without restricting the bind address exposes services to the entire network. Bind development databases and admin interfaces to 127.0.0.1 (-p 127.0.0.1:5432:5432) to prevent unauthorized access from other machines.
Hardcoding Container IPs
Container IPs change when containers restart. Applications that hardcode IPs will break. Always use container names or service names for inter-container communication on user-defined networks, and let Docker DNS handle resolution.
Frequently asked questions about Docker networking
What is Docker networking?
Docker networking is the set of Linux primitives — network namespaces, virtual ethernet pairs, bridges, and iptables rules — that Docker uses to give each container its own isolated network stack while still allowing it to reach other containers and the outside world.
What is a Docker bridge network?
A bridge network is the default Docker network mode. Docker creates a virtual Linux bridge (docker0), attaches each container to it via a veth pair, and uses iptables NAT rules to let containers reach the outside world. Containers on the same bridge can talk to each other directly.
What is the difference between bridge, host, and overlay modes?
Bridge gives each container its own namespace on a virtual switch (default). Host removes isolation — the container shares the host's network stack directly. Overlay spans multiple Docker hosts using VXLAN encapsulation, so containers on different machines can talk as if they were on the same L2 segment.
How does Docker publish a port?
When you run docker run -p 8080:80, Docker installs an iptables DNAT rule that rewrites incoming traffic to the host's port 8080 so it lands on port 80 inside the container. The host's port becomes the public-facing entrypoint to the container service.
Can containers on different hosts talk to each other?
Not by default with bridge mode — bridges are per-host. To connect containers across hosts you use an overlay network (Docker Swarm or Kubernetes CNI), which tunnels container traffic through VXLAN, IP-in-IP, or similar encapsulation so containers everywhere appear to share one logical network.
Try container networking
You just learned how Docker uses namespaces, bridges, and NAT to network containers. Now build the same shape on a canvas: hosts on a private subnet, a switch, a router and NAT. Trace packets between them, then press Go Live to run it as real namespaces and bridges and test it with ping, ip route and iptables -t nat -L.