Docker networking is CRAZY!! (you NEED to learn it)

Docker networking stops being “magic” once the default bridge’s mechanics are laid bare: Docker creates a virtual bridge interface (Docker0), attaches each container to it with virtual Ethernet links, assigns container IPs via an internal DHCP-like process, and provides DNS by copying the host’s resolver into containers. That default setup makes containers talk to each other easily, but it also creates a common pain point—services inside containers (like an Nginx web server on port 80) aren’t reachable from the host or LAN unless ports are explicitly exposed. The practical takeaway is that Docker’s networking choices determine both connectivity and isolation, and the “right” network depends on whether the goal is container-to-container communication, host reachability, or direct integration with the physical LAN.

The walkthrough starts with the default bridge network, then shows how Docker run commands automatically drop containers into that network even when no networking flags are provided. After launching BusyBox and an Nginx container, the system reveals new interfaces per container and confirms they share the same Docker0 network and can resolve each other by name through Docker’s DNS. Containers can reach the internet through NAT, but the host-side experience is different: reaching a container’s service requires publishing ports (e.g., mapping host port 80 to container port 80 with -p 80:80). That manual exposure becomes the tradeoff for the default bridge’s isolation.

Next comes the user-defined bridge, which Docker recommends for production-style setups. Creating a custom bridge (e.g., Asgard) is a single command, but the behavior changes in two key ways: containers placed on different user-defined bridges can’t reach each other, and name-based connectivity improves because Docker provides container-to-container DNS within the same user-defined network. The result is cleaner segmentation than the default bridge, plus more predictable service discovery when container IPs change.

From there, the guide pivots to three “direct-to-LAN” approaches that trade off isolation and operational complexity. The host network mode runs a container as if it’s an application on the host—sharing the host’s IP and ports—so port exposure isn’t needed, but isolation disappears. Mac VLAN connects containers directly to the physical network so they receive real LAN IPs (and even their own MAC addresses), enabling direct access without port publishing; however, it can break on switches due to multiple MAC addresses per port and may require enabling promiscuous mode on the host NIC and in VirtualBox. IPVLAN L2 keeps the direct LAN connectivity while avoiding the multiple-MAC problem by making containers share the host’s MAC address, improving compatibility with typical switch security.

Finally, IPVLAN L3 turns the host into a router for container networks: containers live in layer-3-only subnets, avoid broadcast/ARP behavior typical of layer-2 setups, and can be isolated more tightly. In the example, containers in different L3 subnets can reach each other only under specific conditions (shared parent interface), while internet access requires routing knowledge—static routes on the home router point traffic toward the Docker host. The tour closes with overlay networks for multi-host Docker Swarm-style environments and the “none” network for maximum isolation, where containers get no network interfaces beyond loopback. Overall, the core insight is that Docker’s seven network types are not interchangeable—they’re different connectivity models, each optimized for a different balance of reachability, isolation, and operational friction.