The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Docker networking comes down to three decisions: which containers can reach each other, how they find one another by name, and which ports become reachable from outside their network. For a typical application on one host, the starting point is a user-defined bridge network. Containers attached to it reach each other directly and resolve each other by container name or alias. Publishing a port is a separate decision, made only when something outside that network needs access. When only the Docker host itself should connect, bind the published port to 127.0.0.1.
Start with a user-defined bridge on one host
A bridge network connects containers running on a single Docker host. If you start a container without naming a network, Docker attaches it to the default bridge. Docker’s documentation recommends user-defined bridges for production scenarios, and a user-defined bridge is the simplest way to get name-based discovery, which the default bridge does not provide.
The sequence below builds a two-container application on a network you control.
-
Create the network:
docker network create app-netDocker prints the new network’s ID. Confirm it with
docker network ls, whereapp-netappears with thebridgedriver.Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.#1 Best Overall
-
Start the containers on that network. The images are examples; substitute your own:
docker run -d --name web --network app-net nginx docker run -d --name cache --network app-net redis -
Check membership:
docker network inspect app-netBoth containers should appear under the
Containerskey, each with an IPv4 address from the network’s subnet. -
Test name resolution from inside
web:docker exec web getent hosts cacheThe command should return the address of the
cachecontainer.
Attaching and detaching running containers
Membership can change without recreating a container. docker network connect app-net worker attaches a running container to the network, and docker network disconnect app-net worker detaches it. Docker’s bridge network guide shows this same connect and disconnect workflow. Run docker network inspect app-net afterward to confirm the change.
Free tools Windows power users keep installed
One-click scans. No signup required.
Container-to-container traffic does not need published ports
Containers on the same bridge reach each other’s ports directly. In the example above, web can open a connection to cache on port 6379 even though nothing was published. Membership controls container-to-container reachability; publishing controls exposure to everything else.
Publishing is generally needed in two cases: traffic from outside the Docker host, and traffic from containers on other bridge networks. Docker’s bridge documentation describes access from the host and from other containers on the same network without -p. Whether the host can reach container IP addresses directly depends on your platform. Docker Desktop runs the Engine inside a virtual machine, so test that path before relying on it.
Publishing a port to the host
The publish flag takes the form -p HOST_PORT:CONTAINER_PORT. The example -p 8080:80 maps port 8080 on the host to port 80 in the container. To control which host address listens, add it in front: -p HOST_IP:HOST_PORT:CONTAINER_PORT.
Which host addresses listen
| Publish form | Where the host listens | Typical use |
|---|---|---|
-p 8080:80 |
All host addresses, IPv4 and IPv6 by default | Service that other machines must reach |
-p 127.0.0.1:8080:80 |
IPv4 loopback only | Access from the Docker host itself over IPv4 |
-p [::1]:8080:80 |
IPv6 loopback only | Access from the Docker host itself over IPv6 |
-p 10.0.0.5:8080:80 (example address) |
Only the host address you name | Reachable on one network interface |
A port published without a host address is not host-local. Docker listens on every host address, so a service running on the same machine can still be reachable from the network.
Recommended Free Tools
The localhost caveat depends on Engine version
Docker’s documentation notes that before Engine 28.0.0, hosts on the same layer-2 segment could reach ports published to localhost. On an older Engine, do not treat 127.0.0.1 publishing as protection against other machines on your local network. Check your version with docker version, where the Server section reports the Engine version. Then either upgrade, or restrict access with firewall rules of your own.
Publishing is insecure by default
Docker’s Port publishing and mapping documentation states: “Publishing container ports is insecure by default.” Published ports are available beyond the Docker host unless the binding is restricted, so choose the host address before you choose the port.
Direct routing is not ordinary publishing
Ordinary publishing creates a mapping on the host. Direct routing is different: Docker does not normally set up routes from remote hosts to container IP addresses. Making container addresses routable requires matching external routing and Docker configuration, and gateway modes change how NAT and access behave. Treat direct routing as an advanced option, not a default.
Choosing a network driver
The table compares drivers on the dimensions that usually decide the choice. Where Docker’s driver documentation does not address a dimension, the cell reads “not stated.”
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Driver | Topology | Isolation | Address identity | Name discovery | Prerequisites and notes |
|---|---|---|---|---|---|
| User-defined bridge | One Docker host | Membership determines which containers can talk | Container IP on the bridge | Container name and network alias | Recommended starting point for a group of containers on one host |
| Default bridge | One Docker host | Shared by containers started without another network | Container IP on the bridge | IP addressing or legacy links only | Used automatically when no network is named; Docker recommends user-defined bridges for production |
| Overlay | Multiple hosts in one Swarm | Not stated | Not stated | Not stated | Hosts must join the same Swarm; standalone containers need an attachable overlay |
| Host | Host’s network namespace | No network namespace isolation | Shares the host’s addresses; no separate container IP | Not stated | -p and --publish have no effect |
| Macvlan | Host physical network interface | Not stated | Own MAC address per container | Not stated | Relevant when migrating from a VM setup |
| IPvlan | Host physical network interface | Not stated | Address-level integration without unique MAC addresses | Not stated | Consider where MAC address counts are restricted |
| None | No external connectivity | Isolated from external networks | Not stated | Not stated | Use only when that isolation is wanted |
Multi-host networking with overlay in Swarm
Overlay networks let containers on different Docker hosts communicate. The hosts must belong to the same Swarm. Swarm services can attach to an overlay network directly. Standalone containers can join only if the overlay was created as attachable. Run the create command on a manager node:
docker swarm init # on the first manager node, if no Swarm exists yet
docker network create --driver overlay --attachable app-overlay
docker run -d --name api --network app-overlay nginxWithout --attachable, the same overlay network is limited to Swarm services. Docker’s Swarm networking documentation covers the service-level details.
Specialized choices: host, macvlan, and ipvlan
These drivers solve narrower problems. Each one changes what the container looks like on the network, so pick one only when the default bridge model does not fit.
Host networking
With --network host, the container shares the host’s network namespace and has no separate container IP address. Publishing flags such as -p have no effect, because the container already uses the host’s ports directly.
docker run -d --network host nginxChoose host networking when network performance matters or the application needs a large range of ports. You give up network isolation to get it.
Macvlan
Macvlan gives each container its own MAC address, so it appears on the physical network as a separate device. This matters when you migrate workloads from a VM setup, where each machine already had its own address on the LAN, or when other systems expect containers to look like physical hosts. Because macvlan attaches to a physical interface, plan the interface, subnet, and address assignments before you create the network.
IPvlan
IPvlan also integrates containers at the address level, but containers do not receive unique MAC addresses. Consider it where MAC address counts are restricted.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Name discovery, the default bridge, and legacy links
Two separate mechanisms are involved here: Docker’s name discovery on user-defined networks, and the host’s general DNS configuration.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsThe default bridge
Containers on the default bridge can reach each other by IP address, but Docker does not provide name-based discovery there. To make names work, move the containers to a user-defined network. Legacy links exist as a workaround, but Docker treats them as deprecated.
Legacy links
The --link option predates user-defined networks. Beginning with Engine 29.6, Docker shows a deprecation warning when you create linked containers. Replace links with a user-defined network and, where a second name is useful, a network alias:
docker run -d --name cache --network app-net --network-alias redis redisOther containers on app-net can then reach the cache as cache or redis.
Container DNS and host DNS
By default, containers inherit DNS settings from the host’s /etc/resolv.conf. That setting governs how containers resolve external hostnames. It is separate from container-name discovery on user-defined networks, where cache resolves through Docker’s own network and a public hostname resolves through the inherited settings.
Firewall rules and isolation
Docker installs firewall rules to implement bridge isolation, port publishing, and filtering. Turning off Docker’s firewall management is not a fix for connectivity problems. Docker’s firewall documentation warns that, without replacement rules, bridge containers can lose internet access through masquerading, and ports can become reachable on the local network.
If you need custom rules, write replacement rules that cover masquerading and port exposure before you disable Docker’s management, then test outbound access from a container.
Quick Recap
Troubleshooting common symptoms
| Symptom | Likely cause | Check |
|---|---|---|
| Containers cannot reach each other by name | Containers are on the default bridge, or on different networks | docker network inspect app-net should list both containers |
| Service works from the host but not from another machine | Published to 127.0.0.1 or [::1] |
docker ps shows the mapping as 127.0.0.1:8080->80/tcp |
| Service is reachable from another machine when you expected host-only access | Published without a host address | docker ps shows entries beginning 0.0.0.0: and [::]: |
| Published port has no effect | Container uses host networking | docker inspect -f '{{.HostConfig.NetworkMode}}' web returns host |
| Containers on different hosts cannot communicate | Hosts are not in the same Swarm, or the overlay is not attachable for standalone containers | docker network ls shows the overlay with scope swarm |
| Warning when creating linked containers | Legacy --link on Engine 29.6 or later |
Replace the link with a user-defined network and network alias |
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
