1. Home
2. web
3. Docker Networking: From Bridge to Overlay Networks

Introduction

Docker containers are designed to be portable and isolated, but they rarely run in isolation. Containers need to communicate with each other, with the host system, and with external services. Understanding Docker’s networking model is essential for building reliable, secure, and performant containerized applications.

Docker provides several built-in network drivers — bridge, host, overlay, macvlan, ipvlan, and none — each suited to different use cases. This guide covers each driver in depth, along with DNS resolution, port mapping, security isolation, and Docker Compose networking patterns.

Understanding Docker Network Drivers

Every container has a virtual network interface (veth pair) connected to the host. Docker uses network namespaces to give each container an isolated network stack with its own IP address, routing tables, and ports.

The docker network command is the control center for managing networks:

# List all networks
docker network ls

# Create a user-defined bridge network
docker network create my-network

# Inspect network details
docker network inspect my-network

# Connect a running container to a network
docker network connect my-network my-container

Here is a comparison of Docker’s built-in network drivers:

Bridge Networks in Practice

The bridge network is Docker’s default driver. When Docker starts, it creates a virtual bridge called docker0 on the host and assigns containers IPs from the 172.17.0.0/16 subnet by default.

The default bridge has limitations: no automatic DNS resolution, and all containers are connected with no isolation. User-defined bridges solve these problems:

docker network create my-app-net

docker run -d --name web --net my-app-net nginx
docker run -d --name api --net my-app-net node:18

Containers on the same user-defined bridge can resolve each other by container name:

# From the api container, this resolves to web's IP
ping web

Port publishing maps a host port to a container port via iptables DNAT rules:

# Map host port 8080 to container port 80
docker run -p 8080:80 nginx

Host and Overlay Networks

Host Network

With --network host, the container shares the host’s network stack directly — no NAT, no virtual interfaces, and minimal latency. This is useful for performance benchmarking or applications that need to monitor host interfaces. However, there is no network isolation: the container can bind to any host port and potentially interfere with other services.

# docker-compose.yml
services:
  benchmark:
    image: tool:latest
    network_mode: "host"

Overlay Networks

Overlay networks enable communication across multiple Docker hosts. In Swarm mode, creating an overlay network automatically distributes it to all nodes:

docker network create -d overlay --attachable my-overlay

Under the hood, overlay networks use VXLAN encapsulation to wrap container packets, allowing them to traverse physical network boundaries. Traffic can be encrypted with IPsec using the --opt encrypted flag. The performance overhead is approximately 50 bytes per packet and 5–10% throughput reduction.

DNS Resolution and Service Discovery

Docker runs an embedded DNS server at 127.0.0.11 inside every container. This server resolves container names to IP addresses on user-defined bridge and overlay networks. The default bridge does not provide DNS resolution — you must use --link (legacy) or switch to a user-defined bridge.

In Swarm mode, Docker DNS provides round-robin resolution for services with multiple replicas:

# Create a service with 3 replicas
docker service create --name api --replicas 3 --network my-overlay my-api:latest

# Other containers resolve "api" to one of the 3 replicas via DNS round-robin

Custom DNS settings can be applied per container:

docker run --dns 8.8.8.8 --dns-search example.com nginx

Port Mapping and Security Isolation

Port mapping translates host ports to container ports. The -p flag accepts the format hostPort:containerPort/protocol:

# Multiple ports, specific interface binding
docker run -p 127.0.0.1:8080:80 -p 443:443 nginx

For network isolation, Docker provides several mechanisms:

• Internal networks (--internal) — containers cannot access the internet.
• No network (--network none) — only loopback, maximum isolation.
• Separate bridges — keep containers on different user-defined bridges based on trust levels.

Docker does not have built-in network policies like Kubernetes. For fine-grained control, use iptables, firewalld, or third-party plugins such as Calico, Weave, or Cilium.

Docker Compose Networking Patterns

Docker Compose creates a user-defined bridge network for each project (<project>_default). You can define multiple custom networks in the Compose file to separate concerns:

services:
  web:
    image: nginx
    networks:
      - frontend
      - backend
  db:
    image: postgres
    networks:
      - backend
  redis:
    image: redis
    networks:
      - backend

networks:
  frontend:
  backend:

This pattern separates the public-facing web tier from the internal data tier. The web service connects to both networks, while db and redis are only accessible on the internal backend network.

For connecting to pre-existing networks (e.g., a shared monitoring network), use external networks:

networks:
  monitoring:
    external: true

When scaling services, each replica gets its own container on the same network. Use depends_on with healthcheck and condition to ensure service readiness, rather than relying on start order alone.

Conclusion

Docker’s networking model provides flexible, secure, and performant options for container communication. Start with user-defined bridge networks for single-host multi-container applications — they offer automatic DNS resolution and better isolation than the default bridge. For multi-host deployments, use overlay networks with Docker Swarm.

When designing your network topology:

1. Prefer DNS-based service discovery over hardcoded IP addresses.
2. Use separate bridge networks to isolate tiers based on trust levels.
3. Choose host networking only when latency or interface access is critical.
4. Leverage Compose network definitions to make your infrastructure declarative and reproducible.

Debug network issues with docker network inspect, docker exec into containers to run ip addr and tcpdump, and check firewall rules for cross-host connectivity problems. With these fundamentals in place, you can build container networks that are both powerful and easy to manage.