Docker Deep Dive
by Sergey Okinchuk
Publishing PortsConnecting Containers and Network Isolation
Chapter 7: Networking
Topic 43

host, none, and container Modes

ModesNamespaces

The user-defined bridge is one network mode; Docker offers three more, and each one changes how a container's network namespace is set up. host mode skips the namespace entirely and shares the host's network stack. none gives the container a namespace with no connectivity at all. container: mode makes one container share another's namespace outright.

Each trades isolation for a specific reason, and you reach for one only when you have that reason. --network host in particular carries a platform quirk that surprises Docker Desktop users badly enough to be worth calling out before anything else.

The four network modes
bridge
The default — own namespace, a veth into a bridge, NAT for egress. Isolated.
host
Shares the host's network namespace directly — no -p, no NAT, no isolation.
none
A namespace with only loopback — no external connectivity at all.
container:
Shares another container's namespace — same interfaces, same IP, same localhost.

bridge (the Default)

This is the standard mode from topics 39 and 40: the container gets its own net namespace, a veth into a bridge, and NAT for egress. Everything else in this chapter assumes it, and it is the right default for almost every workload. The three modes below are departures you make on purpose, not improvements on the default.

host Mode

--network host skips creating a network namespace, so the container shares the host's interfaces directly. A server inside binds the host's ports with no NAT and no -p — publishing is meaningless and ignored, because there is no namespace boundary to forward across. That removes the small NAT overhead, which can matter on a high-throughput Linux server, but it also removes network isolation: the container can bind any host port and see every host interface. You are handing the container the host's network, full stop.

The Docker Desktop host Quirk

host mode shares the Linux host's stack — and on macOS and Windows the Linux host is the hidden Docker Desktop VM, not your laptop. So --network host does not bind ports on the Mac itself the way it does on a Linux server, and a container that "works with host networking" on a Linux box behaves differently on Desktop. This is one of the sharpest examples of the hidden-VM gap from Chapter 1: the same flag, two different behaviors, depending on whether there is a real Linux host or a VM standing in for one.

none Mode

--network none gives the container a network namespace with only loopback and no external connectivity at all. It is for a batch job that must do no networking — a data-processing step that should be physically unable to phone home — or as a locked-down base you attach a network to later with docker network connect (topic 44). Its attack surface, from the network's point of view, is nothing.

container: Mode

--network container:web makes the new container share web's exact network namespace: same interfaces, same IP, same localhost. The two reach each other over 127.0.0.1, because they genuinely share one loopback. This is precisely how a Kubernetes pod's containers share a network — the pod is built on this primitive — and it is how a sidecar debug container attaches to a target's exact network view to capture its traffic or hit a service it could not otherwise see.

bridge vs host vs none vs container:

bridge (default) — own namespace, veth, NAT, -p to publish. The right default for almost everything.

host — shares the host's stack: no isolation, -p ignored, binds host ports directly. For the rare case NAT overhead or full-interface access matters, Linux only — and remember the shared stack on Docker Desktop is the VM, not the Mac.

none — a namespace with only loopback and no connectivity. For jobs that must not network at all.

container:<name> — shares another container's namespace and IP, reachable over 127.0.0.1. For sidecars and the Kubernetes pod model. Stay on bridge unless a specific mode is required.

Common Mistakes
  • Using --network host to "fix" connectivity and silently dropping all network isolation — the container now binds host ports directly and sees every host interface, which is a real exposure, not a convenience.
  • Expecting --network host on Docker Desktop to bind ports on the Mac or Windows machine — it shares the Linux VM's stack, so the behavior differs from a Linux server and ports do not land where you expect.
  • Passing -p with --network host and assuming it does something — publishing is ignored in host mode because there is no namespace boundary to forward across.
  • Forgetting that container: mode means a shared IP and shared localhost — two such containers cannot both bind the same port, and they reach each other over loopback, which surprises people expecting separate addresses.
Best Practices
  • Stay on the default bridge — a user-defined one — unless a measured reason like NAT overhead on a high-throughput Linux host, or needing every host interface, justifies host mode.
  • Reserve host mode for Linux hosts where you accept the loss of isolation, and remember it behaves differently under Docker Desktop's VM.
  • Use none mode for batch or compute jobs that must do no networking, shrinking their network attack surface to nothing.
  • Use container: mode for debug sidecars that need the target's exact network view, mirroring how a Kubernetes pod shares a namespace.
Comparable tools Kubernetes builds the pod on container:-style namespace sharing and offers hostNetwork: true as the host-mode analog Podman supports the same --network host/none/container: modes ip netns the namespace-sharing primitive from topic 03 underneath it all

Knowledge Check

What does --network host do to the container's network namespace?

  • It skips the namespace entirely, so the container shares the host's interfaces directly
  • It gives the container a second, nested network namespace layered on top of the host's own
  • It encrypts the container's network namespace so the host kernel cannot inspect its traffic
  • It strips the namespace down to a loopback interface only, with no external connectivity at all

Why is -p meaningless in host mode?

  • There is no namespace boundary to forward across — the server binds host ports directly
  • Docker rejects the entire run command outright if you try to combine -p with host mode
  • In host mode every port binds to 127.0.0.1 only, so a published mapping can never reach them
  • host mode disables TCP entirely, leaving only UDP traffic, which -p simply cannot map

Why does --network host behave differently on Docker Desktop than on a Linux server?

  • It shares the Linux host's stack, which on macOS/Windows is the hidden Desktop VM, not the laptop
  • Docker Desktop ships a noticeably older Docker Engine version that implements host mode in a different way
  • host mode is disabled on Docker Desktop and silently falls back to ordinary bridge networking
  • Docker Desktop's commercial license forbids host networking on both macOS and Windows

How does container: mode relate to the Kubernetes pod model?

  • A pod's containers share one network namespace, IP, and localhost — exactly what container: mode does
  • In a pod each container is given a fully isolated network namespace, unlike container: mode
  • The pod model is entirely unrelated; it relies on overlay networks rather than shared namespaces
  • A pod gives each container its own distinct IP address on a bridge, which is what container: mode produces

You got correct