Docker Networking Explained: Bridge, Host, Overlay, and Macvlan Modes

Docker networking is one of the most important concepts to understand for containerized applications. The right network configuration ensures your containers can communicate securely and efficiently. This guide explains each Docker network driver and when to use it.

Default Docker Networks

# List networks
docker network ls

# Default networks:
# bridge  - Default for standalone containers
# host    - Shares host networking
# none    - No networking

Bridge Network (Default)

The bridge network creates an isolated network namespace for containers:

# Create custom bridge network
docker network create --driver bridge my-app-network

# Run containers on the network
docker run -d --name web --network my-app-network nginx
docker run -d --name api --network my-app-network node-api

# Containers can reach each other by name
docker exec web ping api
docker exec api curl http://web:80

Host Network

The host network removes network isolation between container and host:

# Container shares host network stack
docker run -d --network host nginx

# No port mapping needed - container binds directly to host ports
# Best for: High-performance applications where network overhead matters

Overlay Network

Overlay networks span multiple Docker hosts in a Swarm cluster:

# Create overlay network (requires Swarm mode)
docker network create --driver overlay --attachable my-overlay

# Services can communicate across hosts
docker service create --name web --network my-overlay nginx
docker service create --name api --network my-overlay node-api

Macvlan Network

Macvlan assigns a MAC address to each container, making it appear as a physical device:

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

docker run -d --network my-macvlan --ip 192.168.1.100 nginx

Docker Compose Networking

# docker-compose.yml
services:
  web:
    image: nginx
    networks:
      - frontend
      - backend
    ports:
      - "80:80"

  api:
    image: node:20
    networks:
      - backend

  db:
    image: postgres:16
    networks:
      - backend

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true  # No external access

DNS and Service Discovery

Custom bridge networks provide automatic DNS resolution:

# Containers on the same custom network resolve each other by name
docker network create app-net
docker run -d --name database --network app-net postgres
docker run -d --name webapp --network app-net myapp

# Inside webapp, "database" resolves to the container IP
# Connection string: postgresql://database:5432/mydb

Network Troubleshooting

# Inspect network details
docker network inspect my-app-network

# Check container networking
docker exec container-name ip addr
docker exec container-name cat /etc/resolv.conf

# Test connectivity
docker exec container-name ping other-container
docker exec container-name curl -v http://service:port

# View port mappings
docker port container-name

Best Practices

1. Always use custom bridge networks instead of the default bridge
2. Use internal networks for services that should not have external access
3. Separate frontend and backend networks for security
4. Use DNS names instead of IP addresses for container communication
5. Limit exposed ports to only what is necessary

Understanding Docker networking is essential for building secure, scalable containerized applications. Choose the right network driver for your use case and follow security best practices to keep your containers safe.