Docker Networking Gids: Bridge, Host en Overlay Netwerken

Docker networking is one of the most critical aspects of containerized application architecture. Understanding how containers communicate with each other, with the host system, and with external networks is essential for building reliable, secure, and scalable applications. This comprehensive guide covers every Docker network type, docker-compose networking patterns, and troubleshooting strategies you need to master container networking.

Docker Networking Overview

Docker creates isolated network environments for containers. By default, Docker provides several network drivers, each designed for different use cases. When you install Docker, it automatically creates three networks: bridge, host, and none.

# List all Docker networks
$ docker network ls

NETWORK ID     NAME      DRIVER    SCOPE
a1b2c3d4e5f6   bridge    bridge    local
f6e5d4c3b2a1   host      host      local
1a2b3c4d5e6f   none      null      local

Docker Network Types

Bridge Network (Default)

The bridge network is the default network driver for containers. When you run a container without specifying a network, it connects to the default bridge network. Containers on the same bridge network can communicate with each other via IP addresses. User-defined bridge networks additionally support automatic DNS resolution between containers using container names.

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

# Run containers on the custom network
$ docker run -d --name web --network my-app-network nginx:alpine
$ docker run -d --name api --network my-app-network node:20-alpine

# Containers can now reach each other by name
$ docker exec web ping api
PING api (172.18.0.3): 56 data bytes
64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.089 ms

# User-defined bridge vs default bridge
# Default bridge: containers communicate only via IP addresses
# User-defined bridge: automatic DNS resolution by container name

# Create bridge with custom subnet
$ docker network create \
  --driver bridge \
  --subnet 172.20.0.0/16 \
  --gateway 172.20.0.1 \
  custom-bridge

Host Network

The host network mode removes network isolation between the container and the Docker host. The container shares the host machine network stack directly. This means the container does not get its own IP address, and port mapping is not needed. Use host networking when you need maximum network performance or when a container needs to handle a large range of ports.

# Run container with host networking
$ docker run -d --network host nginx:alpine

# No port mapping needed — container uses host ports directly
# The nginx server is accessible at localhost:80

# Check: container shares host's network interfaces
$ docker exec <container-id> ip addr
# Shows the same interfaces as the host machine

# Warning: Only one container can bind to a given host port
# Host networking is only supported on Linux (not macOS/Windows)

Overlay Network

Overlay networks connect multiple Docker daemons together and enable swarm services to communicate with each other. They are essential for multi-host networking in Docker Swarm or Kubernetes environments. Overlay networks use VXLAN technology to create a distributed network among multiple Docker daemon hosts.

# Initialize Docker Swarm (required for overlay networks)
$ docker swarm init

# Create an overlay network
$ docker network create \
  --driver overlay \
  --attachable \
  my-overlay-network

# Create a service on the overlay network
$ docker service create \
  --name web \
  --network my-overlay-network \
  --replicas 3 \
  nginx:alpine

# Create encrypted overlay network for sensitive data
$ docker network create \
  --driver overlay \
  --opt encrypted \
  secure-overlay

Macvlan Network

Macvlan networks allow you to assign a MAC address to a container, making it appear as a physical device on your network. The Docker daemon routes traffic to containers by their MAC addresses. This is useful when you need containers to appear as physical hosts on the network, particularly for legacy applications.

# Create a Macvlan network
$ docker network create \
  --driver macvlan \
  --subnet 192.168.1.0/24 \
  --gateway 192.168.1.1 \
  -o parent=eth0 \
  my-macvlan

# Run container with its own IP on the LAN
$ docker run -d \
  --network my-macvlan \
  --ip 192.168.1.100 \
  --name legacy-app \
  my-app:latest

# The container appears as 192.168.1.100 on the physical network

None Network

The none network disables all networking for a container. The container only has a loopback interface. Use this for containers that do not need network access, improving security by complete network isolation.

# Run container with no networking
$ docker run -d --network none alpine sleep 3600

# Only loopback interface is available
$ docker exec <container-id> ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
    inet 127.0.0.1/8 scope host lo

Docker Compose Networking

Docker Compose sets up a single network for your application by default. Each container can reach other containers using the service name as a hostname. Understanding Compose networking is essential for building multi-container applications.

# docker-compose.yml — Default networking
# All services share a network named <project>_default
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
  api:
    image: node:20-alpine
    # Can reach web service at http://web:80
    # Can reach db service at postgres://db:5432
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret

Custom Networks in Compose

# docker-compose.yml — Custom networks for isolation
services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    networks:
      - frontend

  api:
    build: ./api
    networks:
      - frontend
      - backend
    depends_on:
      - db
      - redis

  db:
    image: postgres:16
    volumes:
      - pg-data:/var/lib/postgresql/data
    networks:
      - backend

  redis:
    image: redis:7-alpine
    networks:
      - backend

  admin:
    image: adminer
    ports:
      - "8080:8080"
    networks:
      - backend

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

volumes:
  pg-data:

Network Isolation Patterns

You can use multiple networks to isolate services. For example, a frontend network for your web server and API, and a backend network for your API and database. The web server cannot directly access the database.

# Three-tier architecture with network isolation
#
#  Internet
#     |
#  [nginx]     <-- frontend network
#     |
#   [api]      <-- frontend + backend network
#     |
#   [db]       <-- backend network (internal)
#
# nginx can reach api, but NOT db
# api can reach both nginx and db
# db is completely isolated from external access

DNS and Service Discovery

Docker provides built-in DNS resolution for user-defined networks. Containers can resolve each other by name, making service discovery seamless. The embedded DNS server runs at 127.0.0.11 inside each container.

DNS Resolution Rules

# DNS resolution in user-defined networks
# 1. Container name → IP address
$ docker exec web nslookup api
Server:    127.0.0.11
Address:   127.0.0.11#53
Name:      api
Address:   172.18.0.3

# 2. Service name in Compose → all container IPs (round-robin)
$ docker exec web nslookup api
# Returns IPs of all 'api' service replicas

# 3. Network aliases
$ docker run -d \
  --network my-network \
  --network-alias database \
  --network-alias db \
  --name postgres-primary \
  postgres:16

# Container is reachable as: postgres-primary, database, or db

# 4. Check DNS configuration inside a container
$ docker exec web cat /etc/resolv.conf
nameserver 127.0.0.11
options ndots:0

Connecting Containers Across Networks

You can connect a running container to multiple networks simultaneously. This allows a container to act as a bridge between isolated network segments.

# Connect a running container to an additional network
$ docker network connect backend api-container

# Connect with a specific IP address
$ docker network connect --ip 172.20.0.10 backend api-container

# Disconnect from a network
$ docker network disconnect frontend api-container

# A container connected to multiple networks can route between them
# This is useful for "gateway" containers

Inspecting Networks

Docker provides several commands to inspect and debug network configurations. These commands are essential for troubleshooting connectivity issues.

# List all networks
$ docker network ls

# Inspect a network (shows connected containers, config)
$ docker network inspect my-app-network

# Find which networks a container is connected to
$ docker inspect --format='{{json .NetworkSettings.Networks}}' my-container

# Check container IP address
$ docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' my-container

# Check port mappings
$ docker port my-container

# Test connectivity between containers
$ docker exec web ping -c 3 api
$ docker exec web wget -qO- http://api:3000/health

# Debug with a temporary network tools container
$ docker run --rm -it --network my-app-network \
  nicolaka/netshoot bash

Troubleshooting Docker Networking

Container Cannot Reach Another Container

If containers cannot communicate, verify they are on the same network. Containers on the default bridge network cannot resolve each other by name. Use a user-defined bridge network for name resolution.

# Check if containers are on the same network
$ docker network inspect bridge --format='{{range .Containers}}{{.Name}} {{end}}'

# Solution: Use a user-defined network
$ docker network create app-net
$ docker run -d --name web --network app-net nginx
$ docker run -d --name api --network app-net node:20-alpine

# Now name resolution works
$ docker exec web ping api  # Works!

Port Conflicts

If a port is already in use on the host, Docker will fail to start the container. Check for conflicting ports and either stop the conflicting service or map to a different host port.

# Error: port is already allocated
# Find what is using the port
$ lsof -i :8080
$ ss -tlnp | grep 8080

# Solution 1: Map to a different host port
$ docker run -d -p 8081:80 nginx

# Solution 2: Stop the conflicting service
$ sudo systemctl stop apache2

DNS Resolution Failures

DNS issues inside containers can be caused by incorrect DNS configuration on the host. You can specify custom DNS servers for containers.

# Specify custom DNS servers
$ docker run -d --dns 8.8.8.8 --dns 8.8.4.4 my-app

# Or in docker-compose.yml
services:
  web:
    image: nginx
    dns:
      - 8.8.8.8
      - 8.8.4.4

Network Performance Issues

If you experience slow network performance, consider using host networking for performance-critical services. Also check MTU settings and ensure they are consistent across your network infrastructure.

# Check MTU settings
$ docker network inspect bridge | grep -i mtu

# Set custom MTU for a network
$ docker network create --opt com.docker.network.driver.mtu=1400 my-network

# Use host networking for maximum performance
$ docker run --network host my-performance-app

Network Security Best Practices

Follow these best practices to secure your Docker networking setup:

• Use user-defined bridge networks instead of the default bridge network for better isolation and DNS resolution.
• Use internal networks (internal: true) for services that should not have external access.
• Limit published ports to only what is necessary. Bind to 127.0.0.1 for services that should only be accessible locally.
• Use encrypted overlay networks for sensitive data in multi-host deployments.
• Implement network policies to control traffic flow between containers.
• Regularly audit your network configurations with docker network inspect.

# Bind to localhost only (not accessible from outside)
$ docker run -d -p 127.0.0.1:5432:5432 postgres:16

# Create internal network (no outbound internet)
$ docker network create --internal isolated-net

# In docker-compose.yml
networks:
  database:
    internal: true  # Containers cannot reach the internet

Advanced Networking Topics

Custom IPAM Configuration

You can configure custom IP address management (IPAM) for your Docker networks, including specifying subnet ranges, gateways, and IP ranges.

# Custom IPAM configuration
$ docker network create \
  --driver bridge \
  --subnet 10.10.0.0/16 \
  --ip-range 10.10.1.0/24 \
  --gateway 10.10.0.1 \
  --aux-address "dns=10.10.0.2" \
  custom-ipam-net

# In docker-compose.yml
networks:
  app-net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.28.0.0/16
          ip_range: 172.28.5.0/24
          gateway: 172.28.0.1

IPv6 Support

Docker supports IPv6 networking. Enable it in the Docker daemon configuration and create networks with IPv6 enabled.

# Enable IPv6 in Docker daemon (/etc/docker/daemon.json)
{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1::/64"
}

# Create a dual-stack network
$ docker network create \
  --ipv6 \
  --subnet 172.20.0.0/16 \
  --subnet 2001:db8:2::/64 \
  dual-stack-net

Built-in Load Balancing

Docker Swarm provides built-in load balancing for services. When you publish a port for a service, Docker creates an ingress overlay network and uses round-robin DNS for load distribution.

# Docker Swarm built-in load balancing
$ docker service create \
  --name web \
  --replicas 5 \
  --publish published=80,target=80 \
  --network my-overlay \
  nginx:alpine

# Requests to port 80 on ANY swarm node
# are load-balanced across all 5 replicas
# using ingress routing mesh

# Scale the service
$ docker service scale web=10

Network Driver Comparison

Conclusion

Docker networking is a fundamental skill for any developer working with containers. The bridge network handles most single-host scenarios, while overlay networks are essential for multi-host deployments. Use host networking sparingly for performance-critical applications, and leverage macvlan when containers need to appear as physical network devices. Always prioritize network isolation and security, use user-defined networks over the default bridge, and implement proper network segmentation in your docker-compose configurations. Master these networking concepts, and you will be well-equipped to build robust, scalable containerized applications.

FAQ