Docker Networking: Bridges, Hosts, and Overlays

Docker Docker 8 min read 1651 words Beginner ExcellentWiki Editorial Team

Docker networking lets containers talk to each other and to the outside world. Understanding the available network drivers and when to use each is essential for building reliable multi-container applications.

This guide covers Docker networking from bridge to overlay, with practical examples and best practices.

Network Types

Network	Isolation	Use Case
bridge	Per-host	Default, single-host containers
host	None	Performance-critical, single-container
overlay	Multi-host	Swarm services, multi-host clusters
macvlan	Per-container MAC	Legacy apps needing direct network access
none	Complete	Isolated containers

Bridge Networks

Bridge networks are the default. Docker creates a bridge network automatically, and containers connect to it unless specified otherwise.

Default Bridge

docker run -d --name web nginx
docker run -d --name db postgres

# Containers on the default bridge can communicate
# But only by IP address (not hostname)
docker exec web ping db  # Won't resolve

User-Defined Bridge

User-defined bridges provide automatic DNS resolution (containers can resolve each other by name):

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

# Run containers on the custom network
docker run -d --name web --network app-network nginx
docker run -d --name db --network app-network postgres

# Now containers can reach each other by name
docker exec web ping db  # Resolves to db's IP

# Connect a running container to a network
docker network connect app-network existing-container

Custom Bridge Configuration

# Create bridge with custom subnet and gateway
docker network create \
  --driver bridge \
  --subnet 172.20.0.0/16 \
  --gateway 172.20.0.1 \
  --ip-range 172.20.10.0/24 \
  custom-bridge

# Assign a specific IP to a container
docker run -d --name web \
  --network custom-bridge \
  --ip 172.20.10.50 \
  nginx

Host Network

The host network driver removes network isolation between the container and the Docker host. The container uses the host’s network directly.

docker run -d --name nginx --network host nginx
# Accessible on host's port 80, no port mapping needed

Pros: Best performance, no NAT overhead.
Cons: No port isolation, containers compete for ports on the host.

Use when: You need maximum network performance and don’t need port isolation (e.g., a single high-throughput service).

Overlay Networks

Overlay networks connect containers across multiple Docker hosts. They are essential for Docker Swarm and multi-host deployments.

Setup with Docker Swarm

# Initialize a swarm
docker swarm init

# Create an overlay network
docker network create \
  --driver overlay \
  --attachable \
  --subnet 10.0.0.0/24 \
  my-overlay

# Deploy services that can communicate across hosts
docker service create \
  --name web \
  --network my-overlay \
  --replicas 3 \
  nginx

docker service create \
  --name api \
  --network my-overlay \
  --replicas 2 \
  my-api

# The web service can reach the api service by name
# across any Swarm node

Overlay Encryption

# Create an encrypted overlay network
docker network create \
  --driver overlay \
  --opt encrypted \
  secure-overlay

All traffic on an encrypted overlay is encrypted using IPSEC. Use this for sensitive data crossing network boundaries.

Macvlan Networks

Macvlan assigns a real MAC address to each container, making them appear as physical devices on the network:

docker network create \
  --driver macvlan \
  --subnet 192.168.1.0/24 \
  --gateway 192.168.1.1 \
  -o parent=eth0 \
  macvlan-net

docker run --network macvlan --ip 192.168.1.100 nginx

Macvlan is useful for legacy applications that require direct network access or for monitoring tools that need to observe network traffic. The downside is that many host NICs don’t allow multiple MAC addresses on the same bridged network.

Port Publishing

# Publish port 80 on a random host port
docker run -d -P nginx

# Publish specific ports
docker run -d -p 8080:80 nginx
docker run -d -p 192.168.1.100:8080:80 nginx  # Bind to specific interface

# Publish UDP port
docker run -d -p 5353:53/udp dns-server

# Publish range of ports
docker run -d -p 8000-8010:8000-8010 app

DNS and Service Discovery

Docker provides built-in DNS resolution on user-defined networks:

# docker-compose.yml
services:
  api:
    image: my-api
    networks:
      - backend

  db:
    image: postgres
    networks:
      - backend

  frontend:
    image: nginx
    networks:
      - frontend

networks:
  backend:
  frontend:

The API service can reach the database using the hostname db (the service name). Docker Compose also adds db:5432 as an alias.

Custom DNS

# Override container's DNS servers
docker run -d --dns 8.8.8.8 --dns 8.8.4.4 nginx

# Add custom DNS search domains
docker run -d --dns-search example.com nginx

# Disable DNS resolution
docker run -d --dns none nginx

Network Troubleshooting

# List networks
docker network ls

# Inspect a network
docker network inspect app-network

# Show container's network settings
docker inspect web --format '{{json .NetworkSettings}}'

# Check DNS resolution
docker exec web cat /etc/resolv.conf

# Test connectivity
docker exec web ping db
docker exec web curl http://api:3000/health

# Trace network path
docker exec web traceroute db

# View network traffic
docker run -it --network container:web nicolaka/netshoot

Security Best Practices

# 1. Use user-defined bridge networks
docker network create secure-net

# 2. Isolate containers by function
docker network create frontend
docker network create backend
docker network create database

# 3. Only connect containers to needed networks
docker run -d --name api \
  --network frontend \
  --network backend \
  my-api  # API needs both networks

docker run -d --name db \
  --network backend \
  postgres  # DB only needs backend

# 4. Use internal networks (no external access)
docker network create --internal secure-internal

# 5. Restrict container capabilities
docker run -d --cap-drop=NET_RAW --network secure-net app

FAQ

What is the difference between bridge and overlay networks?

Bridge networks connect containers on a single Docker host. Overlay networks span multiple hosts, encapsulating traffic in VXLAN tunnels. Use bridge for local development and overlay for multi-host production clusters.

How do I make a container accessible from another host?

Publish the container’s port using -p flag. The port becomes accessible on the host’s IP address. For multi-host communication, consider overlay networks or a reverse proxy.

Why can’t my container connect to the internet?

Check if the host has internet access and if the container’s DNS is configured correctly (/etc/resolv.conf). Corporate firewalls may block Docker’s DNS resolver. Use --dns to specify a custom DNS server.

How do I prevent containers from communicating with each other?

Place them on separate networks. Use docker network create --internal for networks with no external access. For additional isolation, use --icc=false on the Docker daemon.

What is the Docker DNS resolver?

Docker runs a built-in DNS resolver on 127.0.0.11 inside each container on user-defined networks. It resolves service names and container names to IP addresses, and forwards external queries to the host’s DNS servers.

Related: Check our Docker Security guide.

Docker Network Modes In Depth

Docker provides five network modes: bridge, host, none, overlay, and macvlan. Bridge mode (default) creates a virtual network interface docker0 and NATs traffic. Host mode (--net=host) shares the host’s network stack — best performance but no isolation. None mode (--net=none) disables networking entirely, suitable for security-sensitive batch jobs. Overlay mode enables multi-host networking in swarm mode, encrypting traffic between nodes with IPsec. Macvlan assigns a MAC address to the container, making it appear as a physical device on the network, useful for legacy applications. Custom bridge networks (docker network create --driver bridge mynet) provide DNS resolution by container name. The default bridge lacks this DNS feature. Network isolation with --internal flag creates a network without external access. Connect containers to multiple networks: docker network connect mynet2 mycontainer.

Network Security

Network segmentation is critical for security. Use separate networks for frontend, backend, and database tiers. The database network should allow only the backend service. User-defined bridge networks block inter-container traffic by default except on the same network. Encrypt overlay traffic with --opt encrypted on the network. Restrict outbound traffic with iptables rules on the host or use a sidecar proxy. Avoid --net=host in production unless absolutely necessary.

Advanced Networking: IPv6 and Dual-Stack

Docker supports IPv6 natively, but it must be enabled at the daemon level. Edit /etc/docker/daemon.json to set "ipv6": true and "fixed-cidr-v6": "2001:db8:1::/64". After enabling, all Docker networks default to dual-stack (IPv4 + IPv6). For user-defined networks, specify --ipv6 --subnet 2001:db8:2::/64. Containers on dual-stack networks can communicate over either protocol. Use --ip6 to assign a specific IPv6 address when running a container. For overlay networks, IPv6 must be enabled on the underlying host network and the Docker daemon. Service discovery works identically for IPv6 — container names resolve to both A and AAAA records. Test IPv6 connectivity with docker run --rm alpine ping6 -c 4 google.com. For production dual-stack deployments, verify that both your reverse proxy and DNS infrastructure handle AAAA records correctly.

For a comprehensive overview, read our article on Docker Beginners Guide.