Compare Docker's `bridge`, `host` and `none` network drivers: what does each do to a container's networking, and when would you choose each?
answer
- bridge = own netns + veth + NAT + published ports
- host = shares host netns, -p ignored, no isolation
- none = loopback only
- separate bridges do not forward between each other
- host semantics are Linux-specific
basics
~20 sbridge gives the container its own network namespace on a virtual switch with NAT for outbound traffic and published ports for inbound - the default. host puts the container directly in the host's network namespace: no isolation, no NAT, no port publishing. none gives a namespace with only loopback: no external networking at all.
solid answer
~60 s**bridge** is the default single-host driver. The container gets its own network namespace and a veth pair into a Linux bridge (`docker0` for the default network, a separate bridge per user-defined network). Outbound traffic is masqueraded to the host's IP; inbound requires publishing a port, which installs a destination-NAT rule. Containers on the same user-defined bridge reach each other directly and by name. **host** removes the network isolation entirely: the container shares the host's network namespace, so it sees the host's interfaces and binds ports directly on the host. `-p` is meaningless, there is no NAT overhead, and port conflicts with the host and other host-mode containers become real. These are Linux semantics. **none** creates a network namespace with only a loopback interface. Nothing in, nothing out. It is for batch or compute jobs that must not touch the network, and as a base for attaching a custom interface yourself. Rule of thumb: bridge unless you have a measured reason; host for raw throughput or host-level network access; none to deny networking outright.
code
bash · 6 linesdocker run -d --name web -p 8080:80 nginx:alpine # bridge (default) + published port
docker run -d --name proxy --network host nginx:alpine # binds :80 on the host itself
docker run --rm --network none alpine ip addr # only 'lo' exists
docker run --rm --network none alpine ping -c1 1.1.1.1
# ping: sendto: Network unreachablego deeper
Name the three drivers and their one-line behaviour: isolated network with NAT, shares the host's network, or no network at all.
Explain the mechanism - namespace plus veth into a bridge, masquerade for outbound, destination NAT for published ports - and why -p is meaningless in host mode.
Argue the tradeoffs: isolation and port independence versus NAT and connection-tracking overhead and real client IPs, plus which workloads justify host mode.
Set the default as policy (bridge on user-defined networks) and require a measured justification before granting host mode's loss of isolation across a fleet.
## The common substrate A container's networking is a Linux **network namespace**: its own interfaces, routing table, loopback and firewall rules. The network driver decides what is put into that namespace - or whether a separate namespace is used at all. ## bridge The default. Docker creates a Linux bridge (a software switch) on the host - `docker0` for the built-in `bridge` network, and a dedicated bridge per user-defined network. Each container gets a **veth pair**: one end appears inside the container as `eth0` with an IP from the network's subnet, the other end is plugged into the bridge. - **Outbound**: a masquerade rule rewrites the source address to the host's, so the container reaches the internet through the host. - **Inbound**: nothing is reachable from outside until you publish a port, which installs a destination-NAT rule from a host port to the container's IP and port. - **Container to container**: containers on the same bridge talk directly over it, using each other's internal ports, and on a user-defined network they can use each other's names. - **Isolation**: separate bridges do not forward between each other, so networks segment traffic. Costs: NAT and connection tracking add per-connection overhead, and the extra hop plus (in some configurations) a userland proxy for published ports adds latency. For the overwhelming majority of workloads this is irrelevant. ## host With `--network host` no new network namespace is created; the container's processes see exactly the host's interfaces, IPs and routing table. A server that binds `:8080` is listening on the host's `:8080` directly. - **No NAT, no veth, no port mapping** - the lowest-overhead option, and the simplest way to see clients' real source addresses. - **No isolation** - the container can reach services bound to the host's loopback, can observe or alter host networking if it has the capabilities, and collides with any other listener on the same port. - **`-p` is ignored** (Docker warns), and container-name based discovery does not apply because the container is not on a Docker network. Typical uses: high-throughput proxies and load balancers, network monitoring or packet-capture agents, services needing large or dynamic port ranges, and protocols that rely on multicast or broadcast discovery. Note this is Linux behaviour; on Docker Desktop the daemon runs in a VM, so "the host" is that VM. ## none `--network none` creates a namespace containing only `lo`. The container can talk to itself and nothing else. Use it for untrusted or purely computational workloads (an offline data transform, a build step that must not fetch anything), or as a blank slate when an external tool will attach an interface to the namespace afterwards. It is a genuine control: no network interface means no network path out, whatever the process does. ## Choosing Start from bridge on a user-defined network - it gives isolation, name-based discovery and explicit port exposure, and it is what everyone reading your compose file expects. Move to host only when you can name the reason (measured NAT overhead, need for host-level visibility, dynamic port ranges) and accept losing isolation and port independence. Reach for none when the correct amount of networking is zero. Multi-host and layer-2 scenarios are what the overlay and macvlan drivers exist for.
- What happens if you pass `-p 8080:80` together with `--network host`?The publish flag is ignored and Docker prints a warning. Port publishing works by installing NAT rules that redirect a host port to a container IP inside its own namespace; in host mode there is no separate namespace and no container IP, so the process is already bound directly on the host's port.
- Does `--network none` mean the container cannot communicate at all?It cannot communicate over the network beyond its own loopback - there is no interface to send on. It can still interact through other channels the host grants it: mounted volumes, shared IPC or PID namespaces, or a Unix socket bind-mounted into it. Networking is denied, not all communication.
bridge is an office with a receptionist forwarding calls; host is moving your desk phone onto the company's main line; none is a room with no phone jack.
saying these in an interview costs you the question
- Thinking `-p` still publishes ports when `--network host` is used
- Claiming host mode is always meaningfully faster, without measuring
- Assuming host mode still gives container-name based discovery
- Believing containers on two different user-defined bridges can reach each other by default
- Describing `none` as 'no isolation' rather than 'no networking'