Host, overlay, macvlan and none

host

The container shares the host network namespace: no IP of its own, no NAT. If nginx listens on port 80, that is the host's port 80, so -p is ignored (Docker prints a warning). Best network performance, but ports clash easily. Fully supported on Linux; Docker Desktop has only limited support.

docker run -d --name web-host --network host nginx:1.27

overlay

A virtual network across several Docker hosts (VXLAN encapsulation), so containers/swarm services on different hosts talk as if on one LAN. It needs Swarm: run docker swarm init first, otherwise you get This node is not a swarm manager. Add --attachable so plain containers (docker run) can join too; --opt encrypted encrypts the traffic.

docker network create -d overlay --attachable app-overlay

macvlan

Plugs containers straight into the physical network through a parent interface (for example eth0); each container gets its own MAC and IP on the LAN. Good for legacy apps or traffic-monitoring apps. By default, a macvlan container cannot talk to the host itself over the parent interface.

docker network create -d macvlan --subnet 192.0.2.0/24 \
  --gateway 192.0.2.1 -o parent=eth0 lan-net

none

Networking is fully off; only loopback lo remains. Use it for data-processing jobs that need no network.

flowchart LR
  H["host: shares the host network"] --- O["overlay: many hosts via VXLAN"]
  O --- M["macvlan: own MAC on the LAN"]
  M --- N["none: loopback only"]

ipvlan

ipvlan is close to macvlan, but all containers share the parent interface's MAC address and get their own IPs. It works where switches limit the number of MAC addresses per port. In L3 mode the host routes between container subnets instead of bridging them.

What overlay needs from the network

Swarm overlay networks rely on a few ports between nodes:

If containers on different hosts cannot reach each other, a firewall or security group blocking these ports is the usual cause. VXLAN adds about 50 bytes of headers, so a path with a small MTU can drop large packets; lowering the network's MTU fixes that.

Limits in the cloud

macvlan and ipvlan need the network to accept extra MAC or IP addresses from one VM. Most cloud VPCs only deliver traffic to addresses they assigned, so these drivers mostly suit on-premises servers and labs. In the cloud, use bridge networks with published ports, or the provider's own container networking.

Choosing host networking carefully

Host networking is useful for network tools, monitoring agents, and very high packet rates. The cost is that the container can bind any host port and sees every interface, so it weakens isolation. Kubernetes has the same idea as hostNetwork: true on a pod, normally reserved for system components.

When none is the right answer

--network none suits jobs that transform files and must not exfiltrate data, or untrusted code you only want to run in a sandbox. Data can still move in and out through mounted volumes.

docker network inspect app-overlay shows peers, subnet, and which containers are attached on each node.