Bridge Network

The bridge network is Docker's default and most-used network driver. Lesson 17 introduced it — this lesson goes inside it. Understanding how traffic actually flows between containers on a bridge network is what makes you confident debugging connectivity issues at 11pm when something isn't talking to something else.

Most developers use bridge networks every day without ever thinking about them. The ones who understand what's happening under the hood are the ones who fix networking bugs in minutes instead of hours.

How a Bridge Network Works Internally

A bridge network is a software-defined Layer 2 network — essentially a virtual switch — running entirely inside the Linux kernel on your host machine. When you create a bridge network, Docker creates a virtual network interface on the host (you can see it with ip link show on Linux). Every container attached to that bridge network gets a virtual ethernet interface that connects to this switch.

Containers on the same bridge network can communicate directly with each other through this virtual switch. Traffic between them never leaves the host — it travels through the kernel's network stack, not through any physical network interface. This makes container-to-container communication on the same bridge both fast and isolated from the outside world.

Default Bridge vs Custom Bridge — The Real Difference

Both the default bridge network and user-defined custom bridge networks use the same underlying driver. The differences are in what features each one provides.

Network Aliases — Decoupling From Container Names

By default, a container's DNS hostname on a custom network is its container name. This creates a subtle coupling — if you rename the container or change your naming convention, every other container that references it by name breaks.

Network aliases solve this by giving a container an additional hostname on a specific network — completely independent of the container name. Multiple containers can share the same alias, which also enables simple load balancing between identical containers.

The scenario: You're a platform engineer running two identical payment-processing containers for redundancy. Both should be reachable via the same hostname — payment-processor — so the API doesn't need to know which specific instance it's talking to. Round-robin DNS across both containers gives you basic load balancing for free.

docker network create app-network

# Start two identical payment containers — both with the same alias
docker run -d \
  --name payment-processor-1 \
  --network app-network \
  --network-alias payment-processor \
  payment-api:v2.1.0
# --network-alias payment-processor → this container responds to "payment-processor" on app-network
# The container name is still payment-processor-1 but the alias is what other containers use

docker run -d \
  --name payment-processor-2 \
  --network app-network \
  --network-alias payment-processor \
  payment-api:v2.1.0
# Same alias as the first — both containers now respond to "payment-processor"
# Docker DNS round-robins between them automatically

a3f2c8d91e44b7e1a4c52f889201cd3f
b7e1a4c52f88d3a9e0c1f2b3d4e5f6a7

# From inside another container on app-network:
# nslookup payment-processor
# Server:    127.0.0.11
# Address:   127.0.0.11#53
#
# Name:      payment-processor
# Address:   172.20.0.2   ← payment-processor-1
# Address:   172.20.0.3   ← payment-processor-2
# DNS returns both IPs — clients rotate between them

Configuring a Custom Bridge Network

Custom bridge networks accept configuration at creation time — subnet range, gateway address, and MTU. Most developers never need to touch these defaults, but there are real situations where you do: conflicting subnet ranges with corporate VPNs, specific IP ranges required by security policy, or matching the network configuration of a production environment.

# Create a custom bridge network with explicit subnet and gateway
docker network create \
  --driver bridge \
  --subnet 192.168.10.0/24 \
  --gateway 192.168.10.1 \
  --opt com.docker.network.bridge.name=app-br0 \
  secure-network
# --driver bridge         → explicit driver declaration (bridge is the default)
# --subnet                → IP range for containers on this network
# --gateway               → the gateway IP for the network
# --opt bridge.name       → name the actual Linux bridge interface on the host
# secure-network          → the Docker network name

# Verify the network was created with the right configuration
docker network inspect secure-network

[
  {
    "Name": "secure-network",
    "Driver": "bridge",
    "IPAM": {
      "Config": [
        {
          "Subnet": "192.168.10.0/24",
          "Gateway": "192.168.10.1"
        }
      ]
    },
    "Options": {
      "com.docker.network.bridge.name": "app-br0"
    },
    "Containers": {}
  }
]

Debugging Bridge Network Connectivity

The scenario: Your API container can't connect to the database container. Both are supposed to be on the same custom network but something isn't right. Here's the systematic approach to diagnosing bridge network connectivity issues.

# Step 1 — Check which networks the container is actually on
docker inspect order-api --format '{{json .NetworkSettings.Networks}}'
# --format lets you extract specific fields from the JSON output
# This shows exactly which networks the container is connected to

# Step 2 — Check whether the target container is on the same network
docker network inspect app-network --format '{{json .Containers}}'
# Lists every container currently connected to app-network

# Step 3 — Test connectivity from inside the container
docker exec -it order-api sh
ping db-container          # test DNS resolution and reachability
curl http://db-container:5432  # test if the port is reachable
exit

# Step 4 — If the container isn't on the right network, attach it
docker network connect app-network order-api

# Step 1 output — container is on the wrong network
{"bridge":{"IPAddress":"172.17.0.3","NetworkID":"3f8a2c1b..."}}
# It's on the default bridge, not app-network — that's the bug

# Step 2 output — db-container is on app-network, order-api is not
{"a1b2c3...":{"Name":"db-container","IPv4Address":"172.18.0.2/16"}}

# Step 4 output — connect order-api to the right network
# (no output — silence means success in Docker)

# After connecting — Step 1 again
{"app-network":{"IPAddress":"172.18.0.3","NetworkID":"9e1f3a5b..."}}
# Now on app-network — db-container is reachable by name

Practice Questions

Quiz