How Docker Networking Works
Every Docker container gets its own network namespace with a virtual Ethernet interface. By default, containers attach to a bridge network on the host, which provides isolated internal IP addressing and NAT-based access to the outside world.
Cricket analogy: Every player arriving at the ground gets assigned their own dedicated locker with a private entrance (network namespace), and by default everyone's locker connects through the shared clubhouse corridor (bridge network) with an internal locker number, only reaching the outside world through the main gate with a visitor badge (NAT).
The Default Bridge Network
When you run a container without specifying a network, Docker attaches it to the default bridge network. Containers on this network can reach each other only by IP address — there is no automatic DNS-based service discovery.
Cricket analogy: If you just walk onto a new ground without pre-arranging anything (default bridge), you can only find your teammates by shouting their exact jersey number across the field — there's no PA system announcing names, you just have to know the number.
docker network ls # list all networks (bridge, host, none, plus custom ones)
docker network inspect bridge # see connected containers and subnet
docker run -d --name db postgres:16
docker inspect -f '{{.NetworkSettings.IPAddress}}' dbPublishing Ports to the Host
Containers are isolated from the host network by default. The -p flag on docker run publishes a container port to a host port, setting up a NAT/iptables rule so external traffic can reach the container.
Cricket analogy: A team's inner practice session is closed to the public by default; only when the club explicitly opens a specific gate with a ticket booth (the -p flag) can outside spectators (external traffic) actually get in to watch that one session.
docker run -d --name web -p 8080:80 nginx # host:container
docker run -d --name web2 -p 127.0.0.1:8081:80 nginx # bind only to localhost
docker run -d --name web3 -P nginx # publish all EXPOSEd ports to random host ports-p 8080:80 publishes to all host interfaces (0.0.0.0) by default. On a cloud VM with a public IP, this can unintentionally expose the service to the internet — bind to 127.0.0.1 for local-only access.
User-Defined Bridge Networks and DNS
Creating a custom bridge network enables Docker's embedded DNS server, letting containers resolve each other by container name instead of IP address — the recommended way to let services talk to each other.
Cricket analogy: Setting up a dedicated team radio channel where every player is registered by name (custom bridge network with DNS) means a bowler can call for 'wicketkeeper' directly over the radio instead of memorizing everyone's exact position number, the recommended way for the team to coordinate.
docker network create app-net
docker run -d --name db --network app-net postgres:16
docker run -d --name api --network app-net -e DB_HOST=db myapi:1.0
# Inside 'api', 'db' resolves automatically via Docker's embedded DNS
docker exec api ping -c 2 dbConnecting and Disconnecting Networks
A running container can be attached to additional networks or removed from one without being recreated, which is useful when a container needs to bridge two isolated segments.
Cricket analogy: A star all-rounder can be added to a second training squad's roster mid-season without leaving their original team (attach to additional network), letting them bridge knowledge between two otherwise separate training groups without ever being re-signed.
docker network connect app-net web
docker network disconnect bridge web
docker network rm app-net # only works if no containers are attached- The default
bridgenetwork provides IP connectivity but no automatic DNS name resolution between containers - User-defined bridge networks (docker network create) enable container-name-based DNS resolution
- -p host:container publishes a port; without -p, a container's ports are reachable only within its network
- -p binds to 0.0.0.0 by default; specify an IP like 127.0.0.1:8080:80 to restrict access
- docker network ls / inspect / connect / disconnect / rm manage the lifecycle of networks
- The
hostnetwork driver removes network isolation entirely, sharing the host's network stack directly
Practice what you learned
1. On the default `bridge` network, how do containers typically address each other?
2. What does `docker run -p 8080:80 nginx` do?
3. Which command creates a custom network that supports container name DNS resolution?
4. What is a security risk of `docker run -p 8080:80` on a cloud server with a public IP?
5. Which network driver gives a container the host's own network stack with no isolation?
Was this page helpful?
You May Also Like
Docker Compose Basics
Learn how Docker Compose defines and runs multi-container applications from a single YAML file, replacing long manual docker run commands.
Running and Managing Containers
Learn the core Docker CLI commands to start, inspect, stop, and remove containers, plus how to view logs and execute commands inside a running container.
Docker Architecture Overview
An overview of Docker's client-server architecture, including the Docker daemon, CLI client, images, containers, and registries.
Services and Networking
Understand how Kubernetes Services provide stable networking identities and load balancing for ephemeral, dynamically scheduled Pods.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics