Docker Networking

Docker networking lets containers talk to each other, to the Docker host, and to external networks. The first network mode to understand is bridge networking, because it is the default for normal standalone containers.

This note focuses on the default bridge, docker0, container eth0, and outbound connectivity.

Mental Model

On a native Linux Docker host, Docker creates a bridge interface commonly called docker0. A container attached to a bridge network gets its own network namespace and an interface that usually appears as eth0 inside the container.

flowchart LR
    Container["Container network namespace"] --> Eth0["eth0 inside container"]
    Eth0 --- Veth["veth pair"]
    Veth --- Docker0["docker0 bridge on Docker host"]
    Docker0 --> Host["Host network stack"]
    Host --> External["LAN or internet"]

Read it like this:

1. The container sees its own eth0.
2. That eth0 is connected to the host through a virtual Ethernet pair.
3. The host side connects to a Docker bridge.
4. The bridge connects container traffic into the host network stack.
5. For outbound traffic, Docker can route and NAT traffic through the host.

Note: On Docker Desktop for macOS or Windows, the Linux Docker engine runs inside a VM. You may not see docker0 directly on the macOS or Windows host because it exists inside Docker’s Linux environment.

Network Drivers

Docker supports multiple network drivers. For beginner container work, these are the ones to recognize first:

Driver	Use
bridge	Default local container networking on one Docker host
host	Container shares the host network namespace; Linux-focused use case
none	Container has no external network connectivity except loopback
overlay	Multi-host networking, commonly with Swarm or orchestrated setups
macvlan / ipvlan	Put containers more directly onto a physical network

Bridge networking is the normal starting point.

Default Bridge Network

Docker creates a default network named bridge.

docker network ls
docker network inspect bridge

If you run a container without specifying --network, Docker connects it to the default bridge network.

docker run -d --name web nginx

This is equivalent to using the default bridge:

docker run -d --name web --network bridge nginx

The default bridge is useful for quick local testing, but it is not the best choice for application stacks. User-defined bridge networks are usually better because containers can resolve each other by container name or network alias.

docker network create app-net
docker run -d --name web --network app-net nginx

Tip: Use the default bridge for quick experiments. Use a user-defined bridge for multi-container local applications.

docker0

On native Linux, docker0 is the Linux bridge interface Docker uses for the default bridge network.

Docker host
 
+----------------------------------+
| host network stack               |
|                                  |
|  docker0 bridge                  |
|      |                           |
|      +-- container A veth        |
|      +-- container B veth        |
+----------------------------------+

The bridge acts like a small virtual switch on the Docker host. Containers attached to it can send packets through it.

Useful host-side inspection commands on Linux:

ip addr show docker0
ip link show type bridge
docker network inspect bridge

Bridge Mode and eth0

Inside a container, the network interface is usually named eth0.

docker run --rm alpine ip addr show eth0
docker run --rm alpine ip route

The container sees something like this conceptually:

container
 
eth0  -> container IP address on bridge subnet
route -> default gateway on bridge network

The container does not need to know about docker0 directly. From the container’s point of view, it has eth0, an IP address, and a default route.

Bridge Mode: Outbound Connectivity

Bridge mode allows a container to initiate outbound connections through the Docker host when the host has network access and Docker’s forwarding/NAT rules allow it.

Example:

docker run --rm alpine wget -qO- http://example.com

The path is:

flowchart LR
    App["App process in container"] --> Eth0["container eth0"]
    Eth0 --> Bridge["Docker bridge"]
    Bridge --> Host["Docker host routing and NAT"]
    Host --> Internet["External service"]
    Internet --> Host
    Host --> Bridge
    Bridge --> Eth0

Step by step:

1. The app sends traffic to an external address.
2. The container’s default route sends the packet out through eth0.
3. The packet reaches the bridge network on the Docker host.
4. The host forwards the packet outward.
5. Docker uses NAT/masquerading so the external service sees traffic from the host side.
6. Return traffic is mapped back to the right container.

Outbound connectivity is different from inbound connectivity.

Direction	Bridge Networking Behavior
Container to internet	Usually works through host routing/NAT
Internet to container	Not directly reachable by default
Host to container service	Use port publishing, such as -p 8080:80
Container to container on same default bridge	Usually possible by IP; name resolution is limited
Container to container on same user-defined bridge	Works, including name resolution

To expose a container service outside the bridge network, publish a port:

docker run -d --name web -p 8080:80 nginx

Without -p, the service can listen inside the container but is not automatically exposed outside the Docker host.

Default Bridge vs User-Defined Bridge

Feature	Default bridge	User-Defined Bridge
Created automatically	Yes	You create it
Good for quick testing	Yes	Yes
Good for app stacks	Limited	Better
Container name DNS	Limited on default bridge	Built in
Isolation per app	Weak if everything uses default bridge	Better because each app can get its own network
Connect/disconnect running containers	More limited	Supported with docker network connect / disconnect

Example user-defined bridge:

docker network create app-net
docker run -d --name api --network app-net nginx
docker run --rm --network app-net alpine wget -qO- http://api

The second container can use api as a hostname because both containers are on the same user-defined bridge network.

Commands to Know

Command	Use
docker network ls	List Docker networks
docker network inspect bridge	Inspect the default bridge network
docker network create app-net	Create a user-defined bridge
docker run --network app-net ...	Attach a new container to a network
docker network connect app-net CONTAINER	Attach a running container to a network
docker network disconnect app-net CONTAINER	Detach a running container from a network
docker run -p 8080:80 nginx	Publish container port 80 on host port 8080

TL;DR

• Docker bridge networking gives containers isolated networking on a Docker host.
• The default bridge network is named bridge.
• On native Linux, the default bridge commonly appears as docker0.
• Inside a bridge-connected container, the interface commonly appears as eth0.
• Outbound container traffic usually works through host routing and NAT.
• Inbound traffic to a container needs port publishing, such as -p 8080:80.
• Use user-defined bridge networks for local multi-container apps because name resolution and isolation are better.

Resources

Docker networking overview Official overview of Docker network drivers, port publishing, IP allocation, and container network attachment.

Docker bridge network driver Official explanation of bridge networks, default bridge behavior, user-defined bridges, and port publishing.

docker network CLI reference Official reference for Docker network commands.