Docker Networking:

 Docker Networking: Bridge, Host, Overlay, and Port Mapping

📅 Published: Feb 2026
⏱️ Estimated Reading Time: 18 minutes
🏷️ Tags: Docker, Container Networking, Bridge Network, Host Network, Overlay Network, Port Mapping

---

Introduction: How Containers Communicate

Containers need to communicate. A web container needs to talk to a database container. An application container needs to receive requests from users. Multiple containers on different servers need to work together as a single application.

Docker provides several networking options to handle these scenarios. Each network type serves a different purpose. Understanding them is essential for designing containerized applications.

This guide covers the three most important Docker network types: bridge, host, and overlay, along with port mapping for external access.

---

Part 1: Docker Networking Basics

Network Drivers

Docker uses pluggable network drivers. Each driver provides a different type of networking.

Driver	Purpose	Use Case
bridge	Default network for standalone containers	Single-host container communication
host	Container uses host's network directly	Performance-sensitive, no isolation needed
overlay	Connect containers across multiple hosts	Swarm, multi-host clusters
macvlan	Assign MAC address to container	Legacy applications expecting physical network
none	No network	Isolated containers

Network Commands

bash

# List networks
docker network ls

# Inspect network
docker network inspect bridge

# Create network
docker network create mynet

# Remove network
docker network rm mynet

# Connect container to network
docker network connect mynet mycontainer

# Disconnect container from network
docker network disconnect mynet mycontainer

---

Part 2: Bridge Network

What is Bridge Network?

Bridge network is the default network type in Docker. When Docker installs, it creates a virtual bridge called docker0. Each container on bridge network gets its own IP address and can communicate with other containers on the same bridge.

Think of bridge network as a virtual switch inside your host. Containers plug into this switch and can talk to each other, but they are isolated from the host's physical network.

Default Bridge vs User-Defined Bridge

Feature	Default Bridge	User-Defined Bridge
DNS resolution	Manual links needed	Automatic service discovery
Isolation	Containers can ping each other by IP	Full isolation
Creation	Automatic	Manual
Removal	Cannot be removed	Can be removed

Default Bridge Network

When you run a container without specifying network, it connects to the default bridge.

bash

# Both containers on default bridge
docker run -d --name web nginx
docker run -d --name db postgres

Containers on default bridge can communicate by IP address, but not by container name.

bash

# Find IP of web container
docker inspect -f '{{.NetworkSettings.IPAddress}}' web

# db container can ping that IP
docker exec db ping 172.17.0.2

User-Defined Bridge Network

User-defined bridges provide automatic DNS resolution.

bash

# Create custom bridge
docker network create myapp

# Run containers on custom bridge
docker run -d --name web --network myapp nginx
docker run -d --name db --network myapp postgres

# Now containers can communicate by name
docker exec db ping web

Communication Between Different Bridges

Containers on different bridges cannot communicate by default. They are isolated.

bash

# Container on bridge A
docker run -d --name app1 --network net-a nginx

# Container on bridge B
docker run -d --name app2 --network net-b nginx

# These containers cannot ping each other

To enable communication, you must:

• Connect one container to both networks

• Or use routing between networks

---

Part 3: Host Network

What is Host Network?

Host network removes network isolation between container and host. The container uses the host's network stack directly. It does not get its own IP address. It shares the host's IP.

When to Use Host Network

Performance-critical applications
Host network eliminates network address translation (NAT) overhead. This can improve throughput and reduce latency.

Applications that need many ports
A container on host network can bind to any port without port mapping. This is useful for applications that need to listen on many ports.

Network monitoring tools
Tools that need to see host network traffic, like packet sniffers, must use host network.

Host Network Example

bash

# Run nginx on host network
docker run -d --network host --name nginx-host nginx

# Nginx now listens on host's port 80 directly
curl localhost:80

Host Network Limitations

• Cannot run multiple containers on the same port

• Less isolation (container can affect host networking)

• Only works on Linux hosts (limited support on Docker Desktop for Mac/Windows)

---

Part 4: Overlay Network

What is Overlay Network?

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

Think of overlay network as a virtual network that spans physical machines. Containers on different hosts can communicate as if they were on the same local network.

Overlay Network in Docker Swarm

Overlay networks are primarily used with Docker Swarm. They require Swarm mode to be enabled.

bash

# Initialize Swarm mode
docker swarm init

# Create overlay network
docker network create -d overlay my-overlay

# Deploy services on the network
docker service create --name web --network my-overlay --replicas 3 nginx

Overlay Network Without Swarm

Docker also supports overlay networks without Swarm using etcd, Consul, or ZooKeeper for key-value store.

bash

# Create overlay network with custom key-value store
docker network create -d overlay \
  --subnet=10.10.0.0/16 \
  --gateway=10.10.0.1 \
  --opt encrypted=true \
  my-overlay

Overlay Network Encryption

Overlay networks can be encrypted. Traffic between nodes is encrypted automatically.

bash

docker network create -d overlay --opt encrypted my-encrypted-network

---

Part 5: Port Mapping

Why Port Mapping Is Needed

Containers on bridge network have private IP addresses. They are not accessible from outside the host. Port mapping exposes container ports to the host, making them reachable from the outside world.

Basic Port Mapping

bash

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

# Map multiple ports
docker run -p 80:80 -p 443:443 nginx

# Map to specific host IP
docker run -p 127.0.0.1:8080:80 nginx

# Map to random host port
docker run -p 80 nginx

Port Mapping Syntax

text

-p [host_ip:]host_port:container_port[/protocol]

Example	Meaning
-p 8080:80	Map host port 8080 to container port 80
-p 80:80 -p 443:443	Map multiple ports
-p 127.0.0.1:8080:80	Map only on localhost interface
-p 80	Map container port 80 to random host port
-p 8080:80/udp	Use UDP protocol

Viewing Port Mappings

bash

# Show port mappings for running container
docker port mycontainer

# Inspect for details
docker inspect --format='{{.NetworkSettings.Ports}}' mycontainer

Publishing All Ports

The -P flag publishes all exposed ports to random host ports.

dockerfile

# Dockerfile
EXPOSE 80
EXPOSE 443

bash

docker run -P nginx

Port Mapping on Host Network

When using host network, port mapping is not used. The container binds directly to host ports.

bash

# Host network - binds directly to host port 80
docker run --network host nginx

---

Part 6: Container Communication Patterns

Pattern 1: Web and Database

A web container needs to communicate with a database container.

bash

# Create custom network
docker network create app-network

# Run database
docker run -d --name db --network app-network postgres

# Run web app (connects to database by container name)
docker run -d --name web --network app-network -p 80:80 mywebapp

Pattern 2: Multi-Container Application

A complex application with web, API, cache, and database.

bash

# Create network
docker network create myapp

# Run database
docker run -d --name db --network myapp postgres

# Run cache
docker run -d --name redis --network myapp redis

# Run API (connects to db and redis by name)
docker run -d --name api --network myapp myapi

# Run web (connects to API by name)
docker run -d --name web --network myapp -p 80:80 mywebapp

Pattern 3: Isolated Networks

Some containers should not communicate with each other for security.

bash

# Public network (accessible from outside)
docker network create public

# Private network (internal only)
docker network create private

# Web on public network
docker run -d --name web --network public -p 80:80 nginx

# Database on private network only
docker run -d --name db --network private postgres

# API on both networks (bridge between public and private)
docker run -d --name api --network public --network private myapi

Pattern 4: External Access to Database

A database should not be exposed to the internet, but developers need to connect from their local machines.

bash

# Run database with port mapping
docker run -d --name db -p 5432:5432 postgres

# This exposes database to the network!
# Better approach: use SSH tunnel or VPN

---

Part 7: Network Troubleshooting

Check Container Network Configuration

bash

# Inspect network details
docker inspect mycontainer | jq '.[0].NetworkSettings'

# Get IP address
docker inspect -f '{{.NetworkSettings.IPAddress}}' mycontainer

# Get all network details
docker inspect mycontainer | jq '.[0].NetworkSettings.Networks'

Test Connectivity Between Containers

bash

# Enter container and ping another
docker exec -it web ping db

# Use curl to test HTTP connectivity
docker exec web curl http://db:8080/health

# Check DNS resolution
docker exec web nslookup db

Common Network Issues

Container cannot ping another container

Check:

• Are containers on same network?

• Does the network allow communication?

• Is there a firewall rule blocking?

bash

# Check networks
docker inspect web | jq '.[0].NetworkSettings.Networks'
docker inspect db | jq '.[0].NetworkSettings.Networks'

Port already in use

text

Error: Bind for 0.0.0.0:80 failed: port is already allocated

Fix:

bash

# Find container using the port
docker ps | grep 80

# Stop or change port mapping
docker run -p 8080:80 nginx

Container cannot reach internet

Check:

• Is the container on bridge network? (default has internet access)

• Does host have internet?

• Is there a proxy configuration needed?

bash

# Test internet from container
docker exec web curl google.com

---

Real-World Scenarios

Scenario 1: Local Development Environment

A developer needs to run a web application with a database locally.

bash

# Create network
docker network create dev

# Run database
docker run -d --name postgres \
  --network dev \
  -e POSTGRES_PASSWORD=secret \
  -v postgres-data:/var/lib/postgresql/data \
  postgres

# Run application with hot reload
docker run -d --name app \
  --network dev \
  -p 3000:3000 \
  -v $(pwd):/app \
  node:18 npm run dev

# Run Redis for caching
docker run -d --name redis \
  --network dev \
  redis

Scenario 2: Production Web Application

A production web application with load balancing across multiple containers.

bash

# Create overlay network for multi-host
docker network create -d overlay prod

# Run load balancer
docker service create --name lb \
  --network prod \
  --publish 80:80 \
  traefik

# Run web service (replicas across hosts)
docker service create --name web \
  --network prod \
  --replicas 5 \
  mywebapp

# Run database with persistent storage
docker service create --name db \
  --network prod \
  --mount type=volume,source=db-data,target=/var/lib/postgresql/data \
  postgres

Scenario 3: Isolated Test Environment

A CI/CD pipeline needs isolated test environments that do not interfere with each other.

bash

# Create unique network for each test run
TEST_ID=$(uuidgen)
docker network create test-$TEST_ID

# Run database in isolated network
docker run -d --name db \
  --network test-$TEST_ID \
  postgres

# Run application in same network
docker run --rm \
  --network test-$TEST_ID \
  -e DATABASE_URL=postgres://db \
  myapp npm test

# Clean up
docker rm -f db
docker network rm test-$TEST_ID

---

Summary

Network Type	Use Case	Key Feature
bridge	Single-host container communication	Default, automatic DNS (user-defined)
host	Performance-critical, no isolation needed	No network overhead
overlay	Multi-host clusters	Cross-host communication
port mapping	External access	Expose containers to outside

Understanding Docker networking is essential for building containerized applications. Choose the right network type based on your needs:

• Use bridge networks for most single-host applications

• Use host networks for performance-sensitive workloads

• Use overlay networks for multi-host clusters

• Use port mapping to expose services

---

Practice Questions

1. What is the difference between default bridge and user-defined bridge networks?

2. How do containers on a user-defined bridge network find each other?

3. When would you use host network instead of bridge?

4. What command maps host port 8080 to container port 3000?

5. How do you create a network that allows containers on different hosts to communicate?

---

Learn More

Practice Docker networking with hands-on exercises in our interactive labs:
https://devops.trainwithsky.com/