Docker Networking Drivers: Bridge, Host, and Overlay

Docker networking drivers determine how a container gets an interface, reaches other containers, and communicates with the host or an external network. Choosing between bridge, host, and overlay networking is therefore an architecture decision, not just a command-line option. This guide explains the packet path, isolation boundary, and operational trade-offs of each driver so developers and platform operators can select and troubleshoot the right network.

What Are Docker Networking Drivers?

Docker networking drivers are implementations that connect containers to virtual or physical network interfaces. The Docker Engine creates a network from a driver, then attaches container interfaces to that network. The driver determines whether traffic stays on one host, shares the host network namespace, or crosses hosts through an encapsulated network.

Docker is a platform for building, distributing, and running containers; its official networking documentation describes the CLI and network model used in this article. Docker’s project homepage provides the broader container platform context, but the important systems distinction is simple: an image packages a process, while a network driver gives that process a path to other endpoints.

The main drivers in this comparison are:

• Bridge: Connects containers on the same Docker host through a software bridge and an isolated subnet.
• Host: Places the container in the host’s network namespace, removing the normal virtual network boundary.
• Overlay: Connects containers across multiple Docker hosts by wrapping their traffic in an underlay network.

Docker also supports none for a container with no configured network and macvlan or ipvlan for cases where containers need a more direct relationship with a physical LAN. Those drivers are useful alternatives, but bridge, host, and overlay cover the most common local-development, high-performance, and multi-host designs.

Why Do Different Drivers Exist?

A single networking mode cannot optimize isolation, simplicity, performance, and multi-host reachability at the same time.

With a default bridge, containers receive private addresses and can communicate without exposing every service directly on the host. This is a useful boundary for a single server, but the network normally stops at that host. A web container and database container can share a network locally, while a second host needs another design.

Host networking removes the virtual Ethernet pair, bridge forwarding, and much of the network namespace isolation. That can reduce overhead and make host-local services easier to access, but the container also sees host ports and interfaces. Two host-networked containers cannot independently bind the same host port.

Overlay networking solves the multi-host problem. It gives containers a logical network that spans participating Docker hosts, then transports their packets over an IP underlay. That convenience adds tunnel headers, endpoint discovery, control-plane state, and a dependency on the hosts’ routing and firewall configuration.

The choice should follow the traffic boundary:

How Docker Networking Works

On Linux, a typical bridge-connected container has its own network namespace and a virtual Ethernet pair. One end of the pair is inside the container; the other connects to a Docker-managed Linux bridge on the host. The bridge forwards local traffic, while the host performs routing and often address translation for external access.

container namespace
  eth0: 172.20.0.2
       |
       | virtual Ethernet pair
       |
Docker bridge: 172.20.0.1
       |
host routing, firewall, and NAT
       |
physical interface -> external network

Published ports add a host-facing path. For example, -p 8080:80 asks Docker to make host port 8080 forward to port 80 in the container. The application does not need to listen on the host’s physical interface, but the host firewall and Docker’s forwarding rules still affect the result.

A user-defined bridge is generally preferable to Docker’s legacy default bridge for application stacks. It provides automatic DNS-based discovery by container name and lets an operator attach only the services that need to communicate. Containers on different user-defined bridges are isolated unless routing or another explicit connection is configured.

Overlay networking uses the same logical idea at a larger scope. A container attaches to a virtual network, and the local Docker networking subsystem identifies the destination container or host. If the destination is remote, the packet is encapsulated and sent through the physical network to the remote endpoint. The VXLAN specification in RFC 7348 documents the Network Virtualization using VXLAN model that is commonly associated with this style of overlay transport.

container A -> local overlay endpoint
            -> outer IP/UDP tunnel packet
            -> routed underlay
            -> remote overlay endpoint
            -> container B

The inner packet retains the logical container network identity while the outer packet supplies the addresses needed to cross the host network. This separation is why overlay failures can come from either layer: the containers may have valid logical routes while the hosts cannot reach each other’s tunnel endpoints.

Bridge, Host, and Overlay Compared

This table compares network attachment, not overall application security. A bridge is not automatically safe if every service publishes a port, and an overlay is not automatically private if host access, credentials, or application authorization is weak.

Key Driver Details and Variants

Bridge networks

Create a named bridge when a service group needs predictable local connectivity:

docker network create --driver bridge app-net

docker run -d --name api --network app-net nginx
docker run --rm --network app-net busybox nslookup api

The second command demonstrates name-based discovery on the user-defined network. Containers can reach one another by network alias, but publishing a port is still needed for traffic arriving through the host:

docker run -d --name web --network app-net -p 8080:80 nginx
curl http://127.0.0.1:8080

Keep the bridge subnet separate from office, VPN, and cloud networks. Overlapping ranges create ambiguous routes and can make an otherwise correct container path unreachable from a client.

Host networks

Host mode is selected when the container must use the host’s network stack:

docker run -d --name metrics --network host prom/prometheus

The container’s process listens on host interfaces, so a service configured for port 9090 may be reachable at the host’s address on that port without a Docker port-publishing rule. This is useful for selected monitoring, packet-processing, or latency-sensitive workloads. It is a poor default for untrusted workloads because a compromised process has a closer relationship with the host network and can collide with host services.

Host mode also behaves differently across operating systems and Docker Desktop environments. Verify the runtime’s documented support and test the actual packet path rather than assuming Linux behavior applies unchanged to a desktop VM.

Overlay networks

An overlay is for a coordinated multi-host environment. With Docker Swarm, an operator can create an attachable overlay for services and selected standalone containers:

docker network create --driver overlay --attachable app-overlay
docker service create --name api --network app-overlay --publish published=8080,target=80 nginx

The hosts must belong to the same Swarm and have the required management and data-plane connectivity. A standalone Docker Engine cannot use an overlay as if it were a local bridge without the supporting cluster control plane. Overlay networks are also distinct from Kubernetes pod networking; a Kubernetes cluster normally uses a Container Network Interface plugin rather than Docker Swarm’s overlay lifecycle.

For stateful services, verify whether the application’s replication, identity, and failure behavior remain correct when network paths cross hosts. An overlay can provide reachability, but it does not provide database consensus, durable storage, or encryption by itself.

Real-World Use Cases

Use a user-defined bridge for a local API, worker, cache, and database stack. It keeps service-to-service traffic on a private subnet and exposes only the reverse proxy or API port.

Use host networking for a carefully reviewed host agent that must observe host interfaces, or for a workload whose packet rate makes virtual forwarding a measured bottleneck. Treat the reduced namespace boundary as a security and operations cost.

Use an overlay for services distributed across Docker hosts where the application needs a stable logical network and service discovery. It is most valuable when host placement changes independently of service identity. If the environment is Kubernetes, use the cluster’s networking model and policy system instead of adding an unrelated Docker overlay.

Use macvlan or ipvlan when a legacy appliance must appear as a peer on an existing Ethernet segment. These modes can fit special network appliances, but they complicate host-to-container communication and physical network planning. They should not be selected merely because a published port feels inconvenient.

Practical Inspection and Troubleshooting

Start by identifying the driver’s actual configuration:

docker network ls
docker network inspect app-net
docker inspect --format '{{json .NetworkSettings.Networks}}' api
docker port web

Then test in layers:

1. Confirm the container is running and attached to the expected network.
2. Check the container’s address, route, and DNS configuration.
3. Resolve the service name from another container on the same network.
4. Test the application port from the correct network namespace.
5. For published ports, test the host address and inspect host firewall rules.
6. For overlays, verify node membership, endpoint state, tunnel reachability, and underlay routes.

Useful commands inside a diagnostic image include:

docker run --rm --network app-net nicolaka/netshoot \
  sh -c 'ip addr; ip route; getent hosts api; nc -vz api 80'

If a bridge service resolves by name but cannot connect, inspect the listening address and port inside the destination container. If a published port fails while local container-to-container traffic works, check the host bind address, firewall, and port collision. If overlay traffic fails only between hosts, compare the underlay MTU and firewall rules; encapsulation reduces the usable payload size and may expose path-MTU problems.

Network attachment is also not authorization. Use application authentication, host firewall rules, Docker network segmentation, and platform policy together. The container networking guide covers broader namespaces, bridges, overlays, and Kubernetes networking, while network virtualization techniques explains the underlay, overlay, and control-plane model in greater depth.

Common Misconceptions

“Bridge networking means the containers are on the physical LAN”

Usually it means the containers are on a private virtual subnet behind the host. They can reach external destinations through host routing or NAT, but they do not automatically receive addresses from the physical LAN.

“Host networking makes an application faster in every case”

It removes some virtual networking work, but the application may be limited by CPU, the physical NIC, encryption, disk, or the remote service. Measure latency and throughput before trading away isolation.

“An overlay encrypts all service traffic”

An overlay encapsulates traffic and connects logical endpoints; transport protection depends on the implementation and configuration. Use TLS or another authenticated encryption mechanism when confidentiality and peer authentication are requirements.

“Docker networking chooses service architecture for me”

The driver supplies connectivity, not retries, load balancing correctness, data consistency, or authorization. Those remain application and platform responsibilities.

Related Articles

• Container Networking Explained covers the networking primitives behind container interfaces and bridges.
• Network Virtualization Explained explains VLANs, VXLAN, VRFs, overlays, and underlay design.
• Docker Containers for Beginners connects networking to images, volumes, registries, and the container lifecycle.
• Containerization vs Virtualization compares the isolation boundaries of containers and virtual machines.