What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Containers that share a user-defined bridge network can reach each other directly and find one another by container name, with no port publishing at all. You publish a port with -p only when something outside that network, including your host machine, needs to reach it. Overlay networks extend container communication across Docker hosts in a Swarm, and host, macvlan, ipvlan, and none are specialised choices for particular situations. This guide covers those choices in the order most readers need them, using Docker’s official documentation as of October 2026.
Start with a user-defined bridge on one host
A bridge network connects containers running on a single Docker host. For an application made of several cooperating containers, such as a web service and its database, a user-defined bridge is the right starting point. Membership is scoped to the network, and containers on it can use one another’s container names or network aliases as hostnames. Docker’s documentation recommends user-defined bridges over the default bridge for production scenarios.
- Create the network with
docker network create app-net. Rundocker network lsto confirm thatapp-netappears with the bridge driver. - Start the database on that network:
docker run -d --name db --network app-net redis:7. - Test name resolution from a second container:
docker run --rm --network app-net alpine ping -c 2 db. The expected result is two replies from the address thatdocker network inspect app-netlists fordb. - Attach an existing container to the network with
docker network connect app-net api, and detach it withdocker network disconnect app-net api. The bridge guide shows both commands working on a running container.
The docker network inspect output is the fastest way to check membership and the IP address assigned to each container, and it is the first thing to look at when two containers cannot reach each other.
Container-to-container traffic does not need published ports
Containers on the same bridge reach each other’s ports directly. Publishing is a separate step: it maps a container port to an address and port on the host so that clients outside that network can connect. In the example above, db never needs a -p flag for api to reach it.
#1 Best Overall
| Connection | Publish with -p? |
Why |
|---|---|---|
| Container to container on the same user-defined bridge | No | Containers on the network reach each other’s ports and resolve each other by name. |
| Container on one bridge to a container on another bridge | Generally yes | Docker’s guidance is that publishing is generally needed for access from other bridge networks. |
| Host process, browser, or another machine to a container | Yes | Access from outside the Docker host requires a published port. |
| Containers on different Docker hosts | Not applicable | Requires an overlay network in a Swarm; see the overlay section below. |
Publishing a port to the host
The general form is -p HOST_PORT:CONTAINER_PORT. With -p 8080:80, host port 8080 maps to container port 80 on a bridge network. The address matters as much as the port numbers. If you omit a host address, Docker publishes the port on all host addresses, IPv4 and IPv6 by default. A port is not host-local just because it was published from a container.
| Form | Example | Where the port is reachable |
|---|---|---|
HOST_PORT:CONTAINER_PORT |
-p 8080:80 |
All host addresses, IPv4 and IPv6 by default |
127.0.0.1:HOST_PORT:CONTAINER_PORT |
-p 127.0.0.1:8080:80 |
IPv4 loopback on the Docker host |
[::1]:HOST_PORT:CONTAINER_PORT |
-p [::1]:8080:80 |
IPv6 loopback on the Docker host |
Publish a port for local access only
- Start the container:
docker run -d --name web -p 127.0.0.1:8080:80 nginx. - Check the mapping with
docker ps. The PORTS column should show127.0.0.1:8080->80/tcp. - Test from the Docker host:
curl http://127.0.0.1:8080. A response confirms that the service is reachable locally through the published port.
Docker’s Port publishing and mapping documentation warns that, before Engine 28.0.0, hosts on the same layer-2 segment could reach ports published to localhost. Do not treat loopback publishing as a security boundary on those older releases. If you cannot upgrade, keep published services on a network segment you control.
Docker’s documentation states plainly: “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 deliberately every time.
Recommended Free Tools
Direct routing is a separate, advanced option
Direct routing is not the same as port mapping. Docker does not normally set up routes from remote hosts to container IP addresses. Reaching containers by their IP addresses from outside the host needs appropriate external routing and Docker configuration, and gateway modes change how NAT and access behave. Treat it as a deliberate advanced setup rather than a default.
Choosing a network driver
Choose a driver by where your containers run, how much isolation you need, and whether the containers must have their own network identity. The table compares the drivers on those points.
| Driver | Scope | Prerequisites and constraints | Typical use |
|---|---|---|---|
| User-defined bridge | One Docker host | Create with docker network create; no further setup required |
A multi-container application on one host |
| Default bridge | One Docker host | Used automatically when no network is specified; no built-in name-based discovery | Not recommended for production, according to Docker’s documentation |
| Overlay | Containers across Docker hosts | Hosts must have joined the same Swarm; standalone containers need an attachable overlay | Multi-host Swarm services |
| Host | The host’s own network namespace | Removes network namespace isolation; -p and --publish have no effect |
Performance-sensitive workloads or a large range of ports, accepting reduced isolation |
| Macvlan | The physical network | Each container gets its own MAC address | Migrating from a VM setup, or containers that must appear as physical hosts |
| IPvlan | The physical network | Containers do not get unique MAC addresses | Environments where the number of MAC addresses is restricted |
| None | No external connectivity | The container has no external network connectivity | Workloads that must be fully isolated from networks |
Multi-host and specialised drivers
Overlay for multi-host Swarm networking
An overlay network carries traffic between containers on different Docker hosts. The hosts must have joined the same Swarm. A standalone container, one that is not a Swarm service, can join an overlay only if the overlay was created as attachable. Create one with docker network create --driver overlay --attachable app-overlay. Overlay is the right choice when containers on separate hosts need to communicate. For containers on a single host, a user-defined bridge is simpler.
Host networking
Host networking makes the container share the host’s network namespace. The container has no separate IP address, and -p or --publish has no effect, because the service binds directly to host ports. You accept reduced network isolation in exchange for performance or for a large range of ports. Confirm that the isolation trade-off is acceptable before choosing it.
Free tools Windows power users keep installed
One-click scans. No signup required.
Macvlan
Macvlan gives each container its own MAC address, so it appears on the network as a physical host. It is relevant when you are migrating from a virtual-machine setup, where each workload already has its own network identity, or when containers must be addressable exactly like physical machines.
IPvlan
IPvlan provides similar address-level integration with the physical network, but containers do not receive unique MAC addresses. Consider it where your network restricts how many MAC addresses it can handle.
None
The none driver provides no external connectivity. Use it only when that isolation is intended, such as for a job that should process local data and nothing else.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Name discovery: default bridge, legacy links, and DNS
On the default bridge, containers can reach each other by IP address, but name-based discovery depends on legacy links. Docker characterises links as legacy. Beginning with Engine 29.6, creating linked containers shows a deprecation warning. For new work, put the containers on a shared user-defined network instead of using links.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallContainer DNS and host DNS are separate mechanisms
By default, containers inherit the host’s DNS settings from /etc/resolv.conf. That general setting governs how a container resolves external names. It is distinct from Docker’s container-name discovery on user-defined networks, so troubleshoot the two separately.
Firewall rules and isolation
Docker installs firewall rules to implement bridge isolation, port publishing, and filtering. These rules are part of how the behaviour described above works. Docker warns that disabling its firewall management without replacement rules can break connectivity. Bridge containers may lose internet access because masquerading stops working, and ports can become reachable on the local network. Do not treat turning off Docker’s firewall management as a generic fix. Correct the specific binding or rule that is causing the problem instead.
Quick Recap
Troubleshooting checklist
- Containers cannot reach each other by name. Run
docker network inspect app-netand confirm that both containers are listed. If a container is on the default bridge, move it to a user-defined network withdocker network connect. - A service works on the host but not from another machine. Check the PORTS column in
docker ps. A mapping with127.0.0.1is intentionally local. A mapping with no host address listens on all host addresses. - A localhost-published port is reachable from the local network. Check your Engine version. The localhost-publishing caveat applies to releases before Engine 28.0.0.
- A
-pflag appears to do nothing. Check whether the container uses host networking. Under the host driver, port publishing has no effect. - Containers on different hosts cannot communicate. Confirm that both hosts have joined the same Swarm and that the overlay network is attachable if the containers are standalone.
- Containers lost internet access after firewall changes. Check whether Docker’s firewall management was disabled without replacement rules.
- A linked container shows a deprecation warning. Replace the link with a shared user-defined network. Warnings begin with Engine 29.6.
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.
