Networking and access | Docker: run and diagnose containers

Concept and mechanism

A port described by EXPOSE is not automatically published on the host. In ordinary bridge mode, publication connects a host address and port to a container port. The address on which the application listens inside the container is a separate decision. An application limited to its own loopback may not accept traffic arriving at the container interface. When access fails, identify the client origin, network namespace, destination port, and actual listener. Do not confuse localhost inside a container with localhost on the host. This lesson assumes Linux containers using bridge networking without special host or routed modes.

Guided application

In a fictional application, the API and database share a user-defined bridge. The API uses the service name and internal port; publishing the database on the host is unnecessary for this communication. For a tool intended only for the host, specify the loopback address instead of accepting broad publication by default. Check installed version and network rules: the documentation notes a same-L2-segment access limitation in releases older than 28.0.0. During diagnosis, successful DNS resolution does not establish listener availability; a successful TCP connection does not establish authentication or a functional result either. Test the next layer with a specific observation.

IN PRACTICE

API and db on one bridge: db:5432 identifies the internal destination; localhost identifies the API itself.

Common pitfalls

EXPOSE as publication; localhost without context; publishing the database to fix DNS.

Related topics: Processes and images · Build and distribution · Data and mounts

Take this idea with you

Identify every network boundary before changing exposure.

Create account

Reference: User-defined bridge networking · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped