How do Docker network modes work: bridge, host, overlay, and none?

Picture an office building. Bridge networking gives each team their own private floor with an internal phone system. Teams on the same floor can call each other easily, but reaching the outside world means going through the front desk (a NAT gateway). Host networking removes all office walls so every employee sits in the open lobby with a public phone line. Overlay networking connects multiple office buildings with a secure private tunnel so employees in different buildings can call each other as if they were on the same floor. None networking puts someone in a soundproof room with no phone at all.

Docker networking is built on Linux network namespaces, virtual Ethernet pairs (veth), and iptables rules. When Docker starts, it creates a default bridge network called docker0, which is a virtual Linux bridge device. Every container on the bridge network gets a veth pair: one end goes inside the container's network namespace as eth0, and the other end attaches to the docker0 bridge on the host. Containers on the same bridge can talk via their internal IP addresses. Host network mode skips namespace creation entirely, so the container shares the host's network stack, uses the host's IP address, and can bind directly to host ports without port mapping. Overlay networks use VXLAN encapsulation to create a virtual Layer 2 network that spans multiple Docker hosts, letting containers on different physical machines talk as if they were on the same local network. None mode creates a network namespace but does not set up any network interfaces inside it.

At the Linux kernel level, bridge mode relies on the bridge module and iptables NAT rules. Docker adds MASQUERADE rules in the POSTROUTING chain so outbound container traffic gets translated to the host's IP. Port publishing with -p adds DNAT rules in the PREROUTING chain to forward incoming host-port traffic to a container's internal port. For overlay networks, Docker uses its libnetwork library and the VXLAN protocol, which wraps Layer 2 Ethernet frames inside UDP packets on port 4789. A distributed key-value store (either Swarm's built-in Raft store or an external etcd) keeps track of which container IPs live on which hosts. The overlay driver also creates a separate bridge on each host called the overlay ingress bridge that handles the VXLAN wrapping and unwrapping.

In production, network choice depends on the architecture. Bridge is the default for single-host development and testing. User-defined bridge networks are strongly preferred over the default bridge because they give you automatic DNS resolution by container name. The default bridge only supports the old --link flag for name resolution. Host mode is used when you need maximum network throughput, such as for high-frequency trading systems or network monitoring tools, since it eliminates the overhead of virtual bridges and NAT. Overlay networks are the backbone of Docker Swarm deployments and are also available in Kubernetes via CNI plugins. Production Swarm clusters use overlay networks with the routing mesh, which load-balances incoming requests across all nodes to reach the right container.

A common gotcha is port conflicts in host mode. Since the container shares the host's port space, two containers cannot bind to the same port, and a container might conflict with host services already using that port. On bridge networks, a subtle issue is that containers on different user-defined bridges cannot talk by default. You must explicitly connect a container to multiple networks using docker network connect. Another trap is DNS resolution: containers on the default bridge network do not get automatic DNS, so connecting by container name fails silently, causing confusing connectivity issues. Always create custom bridge networks with docker network create for any multi-container application.