What is the difference between Docker Bridge and Host networking?

Bridge creates a virtual private network on the host with NAT and namespace isolation, making it safer. Host networking gives containers direct access to the host's network stack — no NAT overhead means higher throughput but no network isolation between container and host.

Why should I use a user-defined bridge instead of the default bridge?

User-defined bridges provide automatic DNS resolution so containers can reach each other by name. The default bridge requires you to use IP addresses directly, has no DNS, and cannot connect/disconnect containers at runtime.

Can I use Overlay networking on a single VPS?

Overlay networking requires Docker Swarm mode and is designed for multi-host clusters. On a single VPS, a user-defined bridge network is the correct and simpler choice.

How do I check which network a container is connected to?

Run docker network inspect and look at the Containers section. It lists every container currently attached to that network along with its assigned IP address.

Docker Networking Explained: Bridge, Host, Overlay

Docker Networking is one of the most confusing aspects for beginners. Why can some containers communicate while others can't? Why can't a container reach the internet? Why does a mapped port work from the host but not from another container? This guide covers every Docker Network driver with practical examples to help you choose the right one for each scenario.

How Docker Networking Works

Docker has its own network stack separate from the host. Each container can connect to multiple networks simultaneously. Docker manages this through Network Drivers that define communication behavior.

Key principle: Containers on the same network can communicate directly using container names (automatic DNS). Containers on different networks must use port mapping or be connected to a shared network.

Docker Network Driver Types

DEFAULT

Bridge

Virtual private network on a single host. Containers in the same group can communicate. Most commonly used.

PERFORMANCE

Host

Container shares the host's network stack directly. No NAT, highest throughput, but no isolation.

MULTI-HOST

Overlay

Connects containers across multiple hosts. Used with Docker Swarm or Kubernetes.

ADVANCED

Macvlan

Container gets a real IP on the LAN — appears as a physical machine. Ideal for legacy network integration.

Bridge Network — The Default

When you run a container without specifying a network, Docker uses the default bridge network automatically. However, this default bridge does not support DNS resolution between containers. Use a user-defined bridge instead.

# Create a user-defined bridge network (recommended)
docker network create my-app-net

# Run containers on the same network
docker run -d --name db --network my-app-net mysql:8
docker run -d --name app --network my-app-net myapp:latest

# "app" can now reach "db" by name immediately
# e.g. DB_HOST=db in environment variables

Benefits of User-defined Bridge

Automatic DNS — containers resolve each other by name (no IP needed)
Isolation — separate networks per application
Runtime flexibility — connect/disconnect containers at runtime
Control — define custom subnet and gateway

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

# List all networks
docker network ls

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

Host Network — Maximum Performance

The container uses the host's network interface directly with no virtual network layer, resulting in lowest latency and highest throughput. Ideal for monitoring agents or network-intensive applications.

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

# Nginx listens on port 80 directly on the host
# No need for -p 80:80

Note: Host networking only works on Linux. On Mac/Windows (Docker Desktop), performance is similar to bridge because there's still a VM layer underneath.

Overlay Network — Across Multiple Hosts

Used with Docker Swarm or Kubernetes so containers on different nodes communicate as if on the same network. Data is encapsulated using VXLAN protocol.

# Initialize Swarm first
docker swarm init

# Create overlay network
docker network create \
  --driver overlay \
  --attachable \
  swarm-net

# Deploy service in the overlay network
docker service create \
  --name webapp \
  --network swarm-net \
  --replicas 3 \
  nginx

None Network — Complete Isolation

Container has no network interfaces at all (except loopback). Use for batch jobs that require no network, or when you need maximum isolation.

# Run container with no network
docker run --network none alpine sh

Docker Network Driver Comparison

Driver	Use Case	DNS	Multi-host	Performance
bridge	Default, Local Dev, Single Host	✅ (user-defined)	❌	Good
host	High Performance, Monitoring	Host DNS	❌	Best
overlay	Swarm, Multi-host	✅	✅	Good (VXLAN overhead)
macvlan	Legacy Network, Physical IP	❌	❌	Very good
none	Batch Job, Max Isolation	❌	❌	N/A

Docker Compose and Networks

Docker Compose automatically creates a bridge network. All services in the same Compose file share that network by default.

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

  db:
    image: mysql:8
    networks:
      - backend  # db is only on backend — web can reach it, outside cannot

networks:
  frontend:
  backend:
    internal: true  # internal: true — cuts off internet access for extra security

Common Network Commands

# List all networks
docker network ls

# Inspect network (see connected containers)
docker network inspect <network-name>

# Connect container to an additional network at runtime
docker network connect my-net my-container

# Disconnect container from network
docker network disconnect my-net my-container

# Remove unused networks
docker network prune

Troubleshooting: Containers Cannot Communicate

Different networks: Use docker network inspect to confirm both containers are on the same network
Default bridge in use: Default bridge has no DNS — migrate to a user-defined bridge
Host firewall: Check iptables or ufw for blocking rules
Port not exposed: Use EXPOSE in Dockerfile or --expose so other containers can reach the port

# Test connectivity between containers
docker exec -it app ping db
docker exec -it app curl http://db:8080/health

Securing Docker Networks on Your VPS

Correct network configuration is a critical part of hardening a Docker-based VPS. Follow these security best practices to minimize your attack surface:

Use internal networks for databases: Set internal: true in Compose to cut off internet access for containers that don't need it (MySQL, Redis, etc.)
Restrict port binding to localhost: Use 127.0.0.1:3306:3306 instead of 3306:3306 to prevent the database port from being exposed to the internet
Only expose necessary ports: Expose only the ports that genuinely need external access
Audit iptables regularly: Docker modifies iptables automatically — these rules can bypass ufw policies you've set at the OS level

# Restrict MySQL to localhost only
docker run -d \
  -p 127.0.0.1:3306:3306 \
  --name db \
  --network backend-net \
  -e MYSQL_ROOT_PASSWORD=secret \
  mysql:8

# Check which ports are listening on the host
ss -tlnp | grep LISTEN

# Inspect Docker-generated iptables rules
sudo iptables -L DOCKER -n --line-numbers

Macvlan Network — Integrating Legacy Systems

Macvlan is the right choice when a container needs a real IP address on your LAN, making it appear as a separate physical machine. Common use cases include:

Legacy applications with hardcoded IP requirements
Applications that need multicast or broadcast traffic
Network monitoring tools that require a real interface
DHCP servers that must reside on the real LAN segment

# Identify your host's network interface first
ip link show  # look for eth0, ens3, or similar

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

# Run a container with a real LAN IP address
docker run -d \
  --name legacy-app \
  --network macvlan-net \
  --ip 192.168.1.100 \
  nginx

Macvlan limitation: The host cannot communicate directly with containers on the same Macvlan network due to a Linux kernel restriction. You need to create a Macvlan sub-interface on the host to enable host-to-container traffic.

Docker Network Driver Selection Reference

Use this quick-reference table to choose the right network driver for each scenario:

Scenario	Driver	Why
Web app + database on one VPS	User-defined Bridge	Automatic DNS, good isolation
Monitoring agent	Host	Needs direct access to host network stats
Microservices across multiple VPS nodes	Overlay	Transparent cross-node communication via Swarm
Legacy system requiring real LAN IP	Macvlan	Container gets a real IP on the physical network

Scaling with Docker Swarm Overlay Networks

When a single VPS can no longer handle your workload, Docker Swarm lets you distribute containers across multiple nodes. Overlay networks connect them transparently regardless of which physical machine they run on:

# Join a worker node to the Swarm (run on each worker)
docker swarm join --token <TOKEN> <MANAGER-IP>:2377

# Check the status of all nodes (run on the manager)
docker node ls

# Scale a service up to 5 replicas
docker service scale webapp=5

# Check service replica status
docker service ps webapp

Docker-Ready VPS from AsiaGB

AsiaGB VPS supports Docker and Docker Compose out of the box. Full root access to configure networking as needed. Starting at ฿500/month.

View VPS Plans

View all affordable VPS Thailand plans →

Docker Networking Explained: Bridge, Host, Overlay and More