Container Networking

The bridge network: what `docker run` actually does

When the Docker daemon starts, it creates a Linux bridge called docker0 with its own private subnet. Every container gets a veth pair whose host end plugs into that bridge — instead of dangling loose the way the manual example on the Linux Networking page did.

Press "Next" to run the first command.

Port publishing: `-p 8080:80`

A container's bridge IP (like 172.17.0.2) isn't reachable from outside the host — it's private, same as any other NAT-hidden address. Publishing a port adds an iptables DNAT rule that rewrites the destination for you.

Request arrives at

host:8080

→

iptables DNAT rewrites to

172.17.0.2:80

→

Delivered to

nginx inside the container

$ docker run -d -p 8080:80 nginx

# Docker adds a rule roughly equivalent to:

$ iptables -t nat -A DOCKER -p tcp --dport 8080 -j DNAT --to-destination 172.17.0.2:80

Container DNS: resolving containers by name

On a user-defined network, Docker runs an embedded DNS server at 127.0.0.11 inside every container on it, so web can reach db just by resolving the name db — no hardcoded IPs, even though container IPs can change on restart.

Network type	Containers resolve each other by name?
Default bridge (`bridge`)	No — this is a common surprise. Only IP-to-IP works, for legacy compatibility reasons.
User-defined bridge (`docker network create mynet`)	Yes — automatic, via the embedded 127.0.0.11 resolver.

Network driver comparison

Driver	What it does	Typical use
bridge	Private network namespace + veth pair to a bridge (the default, and everything demonstrated above)	Most single-host container workloads
host	No namespace isolation at all — the container shares the host's network stack directly	Maximum performance when isolation isn't the goal
none	Only a loopback interface, no external connectivity	Fully isolated batch jobs
overlay	A virtual network spanning multiple hosts, tunneling container traffic between them (typically via VXLAN)	Multi-host Swarm/cluster deployments
macvlan	Gives a container its own MAC address, making it look like a physical device directly on the LAN	Legacy apps that expect to own a real network identity

Common gotchas

The default bridge network has no name-based DNS. If containers need to find each other by name, put them on a user-defined network — don't rely on the default one Docker creates automatically.
host networking skips isolation, not just performance overhead. A container using it binds directly to the host's ports — two containers both wanting port 80 will conflict, exactly like two ordinary processes would.
Containers on different user-defined networks can't reach each other unless explicitly connected to both — networks are an isolation boundary by design, not just an organizational label.
Overlay networks eat into your MTU budget. VXLAN encapsulation adds its own header overhead, so the usable payload per packet shrinks — a container-to-container path that ignores this can hit silent fragmentation issues.