On Docker Desktop, why doesn't `--network host` put a container on the Mac's network?

### What `--network host` means, and where the word "host" points Every container normally gets its own network namespace: its own interfaces, routing table, iptables rules and port space. `--network host` says the opposite — do not create a namespace, put this process straight into the host's. The visible effect on a Linux server is that publishing becomes meaningless and unnecessary: a process that binds `0.0.0.0:8080` is on the machine's real addresses immediately, and `-p` is rejected as pointless. On Docker Desktop the phrase still means exactly that, but "the host" is Docker Desktop's Linux VM, because that is where `dockerd` and the container process live. Your Mac or Windows desktop is a *different* machine on the other side of a virtual boundary. So the container joins the VM's network namespace and binds on the VM's interfaces, and the socket really is open — inside the VM. From your laptop's terminal there is simply no route there, so the connection is refused or hangs, and people conclude that `--network host` is "broken" when it did precisely what it says. ### Why container IPs behave the same way `docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' web` will happily print something like `172.17.0.4`, and on a Linux host you can `curl` that address directly because the bridge interface is attached to that host's stack. Under Desktop the bridge is inside the VM. Your host has no interface on that subnet and no route to it. This trips people up because the value *looks* like a normal LAN address; nothing in the output hints that it is meaningful only on the far side of a VM boundary. ### The two supported crossings **Inward: publish a port.** `docker run -p 8080:8080` makes Desktop listen on the host side, on macOS or Windows, and forward accepted connections into the VM to the container's port. That is why `http://localhost:8080` works in your browser on Desktop even though nothing on macOS is running the server. Bind the container process to `0.0.0.0` rather than `127.0.0.1` inside the container, or the forwarded connection arrives at a port nobody is listening on and you get a connection reset that looks like a Docker fault. **Outward: `host.docker.internal`.** A container that must reach a service running on your laptop — a database you started natively, an IDE debug listener — resolves `host.docker.internal` to an address that routes back out of the VM to the host. `gateway.docker.internal` names the VM's gateway. Neither name exists on a plain Linux engine, so anything that depends on them is Desktop-specific configuration and must not leak into a production Compose file or image. ### A worked example A team ships a C++ email-digest builder as a daemon that links several runtime shared libraries. The daemon binds `0.0.0.0:8493` and is started on a developer Mac with `--network host` because that is what the production Linux runbook says. It logs "listening on 8493" and the health check on the laptop returns connection refused every time. The developer spends a morning suspecting the C++ service's socket setup. The real explanation is one line long: the process is listening on port 8493 *of the VM*. `docker run --rm --network host curlimages/curl -s localhost:8493/health` succeeds, because that curl container is also in the VM's network namespace. The fix on Desktop is `-p 8493:8493` and `http://localhost:8493/health` from the Mac. ### The version wrinkle worth naming Recent Docker Desktop releases (4.34 and later) added an opt-in host-networking capability for Mac and Windows that makes `--network host` bind on the host loopback as well. It is a setting you must turn on, not the historical default, so the safe interview answer is: by default and for years, host networking on Desktop meant the VM's network; check the Desktop version and its network settings before assuming otherwise. Note also that even where it is enabled, this is a Desktop convenience — Compose files and deployment manifests that assume host networking still behave the Linux way in production. ### The general rule When a networking behaviour on Desktop surprises you, replace the word "host" with "the Linux VM" in whatever documentation you are reading and re-read the sentence. Most of the surprises disappear.