Docker Networking Basics for a Docker Media Server

Docker containers are isolated entities — each one behaves almost like a single-purpose computer on the network. To allow them to communicate with each other and with external devices or services, Docker Engine configures and manages network access on their behalf. Understanding how Docker networking works is essential before you start wiring together a multi-container media server stack. Get this wrong and things become confusing fast.

This article explains Docker networking at a practical level: the terminology you will encounter, the three built-in network modes, and the CLI commands you need to inspect and reason about your container network topology.

Key Networking Terms

Before diving into modes and commands, it helps to define the terms you will see throughout any Docker networking discussion.

• Host network — your physical LAN. It consists of IP addresses (e.g. 192.168.1.x), subnet masks (e.g. 255.255.255.0), and is typically managed by your router. Every physical device on your network sits here.
• Docker network — a virtual network managed by Docker Engine. By default it runs on a separate address range (commonly 172.17.0.x) and a different subnet mask (255.255.0.0). Its scope and behaviour depend on the network mode you choose.
• Port — a number that identifies a specific service on a host. Web servers traditionally listen on port 80 (HTTP) or 443 (HTTPS). Media server apps are commonly reached over custom ports such as http://192.168.1.100:8096. The number after the colon is the port.
• Port forwarding (port mapping) — redirecting traffic arriving at a given IP-address/port combination to a different address/port. In Docker, this is how you make a containerised service reachable from your host network. Docker maps a port on the host to a port inside the container, bridging the two networks.

Docker Networking Modes

Docker ships with three built-in network drivers. Each involves different trade-offs between isolation, simplicity, and flexibility.

Bridge Mode (Default)

Bridge is the default network mode. When Docker Engine starts, it creates a virtual network interface called docker0 that acts as a software bridge between the isolated Docker network and your physical (host) network. Each new container receives an IP address on the Docker subnet (e.g. 172.17.0.2, 172.17.0.3, and so on).

Containers on the same host in bridge mode can communicate with each other directly by IP address with no extra configuration. However, for a container to be reachable from outside the Docker network — such as from your phone, TV, or another machine on your LAN — you must explicitly map a host port to the container port when you start the container.

You can verify the bridge interface is present by checking your network configuration. On Linux, the docker0 interface appears alongside your physical adapters:

ip addr show docker0

On Windows (with Docker Desktop), run the following from a Command Prompt to see the virtual DockerNAT adapter alongside your physical NIC:

ipconfig /all

The DockerNAT adapter typically uses its own address range (e.g. 10.0.75.x) separate from your LAN range.

On a Synology NAS running the Docker package, open Docker from the Package Center and select Network from the sidebar. Expand the bridge entry to see the subnet in use. On a QNAP NAS running Container Station, navigate to Preferences → Network to find the equivalent information.

Summary: Bridge mode gives you network isolation with explicit, controllable port mappings. It requires slightly more configuration up front but is the right default for most media server deployments.

Host Mode

In host mode, Docker does not create a separate network for the container. Instead, the container shares the host machine’s network stack directly — it binds to the same IP address and ports as the host OS. There is no NAT layer and no port mapping required.

This can simplify configuration and may improve network performance for certain workloads, but it removes the isolation that bridge mode provides. A port conflict between a container and a host service becomes possible, and the container can reach any service on the host network without restriction.

Note: Host mode networking on Docker Desktop for macOS and Windows behaves differently from Linux — on those platforms the Docker daemon runs inside a lightweight VM, so true host-mode networking against the Mac or Windows host is not directly available in the same way.

None Mode

The none driver gives the container a private network namespace with only a loopback interface (lo). The container has no external network connectivity whatsoever. This is useful for containers that perform purely local computation and must be completely network-isolated, but it is rarely used in media server scenarios.

Viewing and Inspecting Docker Networks

Docker provides straightforward CLI commands to list and inspect the networks available on your host.

List All Networks

docker network ls

A fresh Docker installation shows three default networks — bridge, host, and none — each with a unique ID and its associated driver. These default networks are required by Docker and cannot be removed, though you can create additional user-defined networks alongside them.

Inspect a Specific Network

docker network inspect bridge

This returns a JSON object containing the subnet, gateway, and — once containers are running — the IP address assigned to each connected container. For example, if you have two containers named Container1 and Container2 running on the default bridge network, the output will list both with their respective internal IP addresses (such as 172.17.0.2 and 172.17.0.3). This is a quick way to find a container’s internal IP when you need it.

Replace bridge with host or none to inspect those networks, or use the name of any user-defined network you have created.

Selecting a Network When Running a Container

When you start a container with docker run, use the --network flag to choose which network it joins:

# Use host networking
docker run --network=host my-image

# Use the default bridge (this is the implicit default if --network is omitted)
docker run --network=bridge my-image

# Use no networking
docker run --network=none my-imageCode language: PHP (php)

If you omit --network entirely, Docker assigns the container to the default bridge network automatically.

Port Mapping in Practice

When running in bridge mode, use the -p flag to publish a container port on the host:

# Map host port 8096 to container port 8096
docker run -p 8096:8096 my-media-server-imageCode language: CSS (css)

The format is HOST_PORT:CONTAINER_PORT. After this mapping is in place, any device on your LAN can reach the containerised service at http://<host-ip>:8096, even though the container itself lives on the separate Docker subnet.

You can publish multiple ports in a single docker run command by repeating the -p flag:

docker run -p 8096:8096 -p 8920:8920 my-media-server-imageCode language: CSS (css)

Choosing the Right Mode for a Media Server

For most home media server setups, bridge mode with explicit port mappings is the recommended starting point. It matches Docker’s defaults, keeps containers reasonably isolated, and gives you fine-grained control over which ports are exposed. The trade-off — a few extra -p flags per container — is minimal.

Host mode is worth considering if a containerised application relies on network protocols that are difficult to port-map (such as multicast-based service discovery), or if you are troubleshooting connectivity issues and want to eliminate NAT as a variable. Be aware of the reduced isolation it implies.

None mode has no practical use in a media server context.

Once you are comfortable with these basics, Docker’s user-defined bridge networks — created with docker network create — offer additional benefits such as automatic DNS resolution between containers by name. That topic builds naturally on what is covered here.