Container Networking

In bridge mode — Docker’s default — every container gets a network namespace (Network Namespaces) with an eth0 that is one end of a veth pair. The host end joins the docker0 bridge, which owns 172.17.0.1/16 and acts as the containers’ default gateway. Containers on the same bridge reach each other by IP directly over the bridge, at L2, with no NAT. Traffic to anywhere else hits the host routing table, is forwarded out of the physical NIC, and on the way is masqueraded: the source address is rewritten to the host’s IP because 172.17.0.0/16 is not routable outside. Outbound container traffic is ordinary NAT: Many Private Hosts Behind One Public Address, with the host kernel as the NAT box and its conntrack table remembering each flow.

So a container’s outbound HTTP request to the internet crosses: container socket → netns routing → veth → bridge → host routing (ip_forward=1) → nftables POSTROUTING MASQUERADE → host NIC. Every one of those is a place to look when "the container has no network": is ip_forward on, is the masquerade rule present, does the bridge have an address, did the veth join it.

-p 8080:80 does not make the container listen on the host’s port 8080. It installs a destination NAT rule in the host kernel: packets arriving at the host addressed to :8080 (from any interface but the bridge) get their destination rewritten to 172.17.0.2:80 and are forwarded over the bridge. The container’s nginx is listening on 80 in its own namespace and sees a connection to 172.17.0.2:80 from the original client’s address. Replies are un-rewritten by conntrack on the way back. The host process table has nothing on 8080 except, in Docker’s case, a small `docker-proxy` user-space listener that exists to handle the one case iptables cannot: connections from the host itself to localhost:8080, because packets to 127.0.0.1 do not traverse the forwarding path.

This is why ss -ltn on the host may show docker-proxy on 8080 and not nginx, why the container’s logs show real client IPs (it is DNAT, not a proxy), and why -p 127.0.0.1:8080:80 — binding the rule to loopback — is the way to keep a published port off the public interface. Note the firewall consequence: DNAT happens in PREROUTING, before the host’s INPUT chain, so host firewall rules on INPUT do not apply to published ports; the packets take the FORWARD path, which Docker manages with its own chains and which has bypassed many a carefully written host firewall.

bridge is the default described above: isolated namespace, private IP, NAT out, DNAT in. host skips the namespace entirely: the container shares the host’s network stack, binds ports directly on the host’s interfaces, sees the host’s routes and firewall — no veth, no NAT, no port publishing, best throughput, no isolation, one port 80 for everyone. none is a namespace with only loopback. container:<id> joins another container’s namespace, which is what a Kubernetes pod is: several containers sharing one namespace and therefore localhost (Kubernetes Networking, Just Enough).

overlay networks span hosts. Each host runs a bridge for the network; frames between containers on different hosts are encapsulated — Docker Swarm and Flannel use VXLAN, Ethernet frames inside UDP on port 4789 — and sent host to host, then decapsulated onto the far bridge. It is the same Encapsulation: Data, Segment, Packet, Frame trick as a VPNs and Tunnels without the encryption, with the same MTU tax (VXLAN costs 50 bytes, so an overlay eth0 typically shows an MTU of 1450), and a distributed key-value store telling each host which container IP lives where.

User-defined bridge networks (docker network create app) behave like the default bridge plus two things that matter: automatic DNS for container names, and isolation from containers on other networks. Rootless container runtimes cannot create veth pairs or NAT rules on the host and instead use a user-space network stack (slirp4netns, pasta), which is slower and has its own port-forwarding rules; if a rootless container "has network but is slow", that is why.

On a user-defined network the runtime writes nameserver 127.0.0.11 into the container’s /etc/resolv.conf. That address is an embedded resolver in the Docker daemon, reached through NAT rules inside the namespace; it answers container and service names on the same network (db, api) with their container IPs and forwards everything else to the host’s resolvers. On the legacy default bridge there is no name resolution between containers — only IPs and the deprecated --link. Compose puts every service on a user-defined network, which is why postgres://db:5432 works in Compose and not with plain docker run on the default bridge.

localhost is 127.0.0.1 on the loopback of whichever namespace you are in. Inside the container it is the container: a database published on the host’s 5432 is not reachable at localhost:5432 from inside, and a service the container runs is not on the host’s localhost unless published. From a container, the host is reachable at the bridge gateway (172.17.0.1) on Linux, or at the special name host.docker.internal on Docker Desktop (and on Linux with --add-host=host.docker.internal:host-gateway).

On macOS and Windows there is no Linux kernel to hold the namespaces, so Docker Desktop runs a small Linux VM and every container lives inside it. docker0, the veths and the DNAT rules exist in the VM; published ports are forwarded a second time from the Mac to the VM by the desktop app. Consequences: --network host historically meant the VM’s network, not the Mac’s (newer Docker Desktop versions add an opt-in host-networking bridge); tcpdump on the Mac does not see container traffic; the extra hop costs latency and throughput; and there is a second NAT layer whose source addresses are the VM’s. Any container networking explanation that starts with "on the host…" assumes Linux.