Master Docker Container Networking: Bridge, Host, None, and Custom Networks

Docker built‑in network drivers

After installing the Docker engine, three default network drivers are created automatically: bridge, none, and host. Each container can be attached to one of these drivers using the --network flag when running docker run.

Default bridge network (docker0)

The default bridge driver creates a virtual bridge called docker0 on the host. Containers that do not specify a network are connected to this bridge, receiving an IP address from the 172.17.0.0/16 subnet.

$ docker network ls
NETWORK ID   NAME      DRIVER    SCOPE
557d70cd18ab bridge    bridge    local
27015fb1d01 host      host      local
... (other entries)

Running docker network inspect bridge reveals details such as the subnet, gateway, and attached containers:

{
  "Name": "bridge",
  "Id": "4784e193...",
  "IPAM": {
    "Config": [{"Subnet": "172.17.0.0/16", "Gateway": "172.17.0.1"}]
  },
  "Containers": {
    "ea30f1c...": {"Name": "container1", "IPv4Address": "172.17.0.2/16"},
    "ecc3bdf...": {"Name": "container2", "IPv4Address": "172.17.0.3/16"}
  }
}

Containers on the default bridge can communicate via IP addresses, but Docker does not provide automatic name‑based service discovery on this network.

No network mode ( none )

Containers attached to the none driver have no network interfaces and cannot communicate with other containers or the outside world.

Host network mode ( host )

Using the host driver connects the container directly to the host’s network stack, exposing the same ports as the host. This removes network isolation and is generally discouraged for most applications.

User‑defined bridge network

Because the default bridge has limitations (e.g., ports are not published automatically and name‑based resolution requires --link), Docker recommends creating custom bridge networks.

$ docker network create -d bridge tinywan_bridge

The command creates a new bridge named tinywan_bridge with the same driver as the default bridge. Listing networks shows the new entry:

$ docker network ls
NETWORK ID   NAME            DRIVER    SCOPE
4784e193...  bridge          bridge    local
e8e19c07...  host            host      local
...          tinywan_bridge  bridge    local

Running containers on the custom network

Start two Ubuntu containers attached to the default bridge:

$ docker run -itd --name container1 ubuntu
$ docker run -itd --name container2 ubuntu

Inspect the custom bridge to see the containers attached after they are started with --network=tinywan_bridge:

$ docker run -d --net=tinywan_bridge --name db redis:5.0-alpine
$ docker network inspect tinywan_bridge

Connecting an existing container to the custom network is also possible:

$ docker network connect tinywan_bridge web

Verifying connectivity

Obtain a container’s IP address with:

$ docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' db
172.17.0.2

Enter the container shell and ping the other container by name:

$ docker exec -it web bash
# ping db
PING db (192.168.192.2): 56 data bytes
...

The ping succeeds, demonstrating that containers on the same user‑defined bridge can resolve each other by name and communicate via both IP and hostname.

Key takeaways

The default bridge network provides basic connectivity but lacks automatic service discovery.

The none driver isolates containers completely.

The host driver removes isolation and shares the host’s network stack.

Creating a user‑defined bridge network enables port publishing, name‑based resolution, and better isolation for multi‑container applications.

References

Docker documentation – User‑defined networks

Docker learning notes – Network

Docker CLI reference for

docker network create