Check Docker Port Mappings Without Guessing

An image saying it listens on a port is not proof that port is reachable, and docker port shows you the real, published mapping instead. It lists the host addresses and ports Docker has actually published for a container, or answers about one private port directly. Allow about ten minutes if the container already exists, or fifteen if you need to track it down first.

You need a running Docker daemon and a container you can inspect. These checks are normally unprivileged: do not add sudo unless your local Docker installation specifically requires it. Membership of the Docker group is itself security-sensitive, since it normally grants control of the daemon.

1. Check the installed command

Start with the local help output. This is a read-only command; it does not start, stop or modify a container:

$ docker port --help
Usage:  docker port CONTAINER [PRIVATE_PORT[/PROTO]]

List port mappings or a specific mapping for the container

The local manpage describes docker port as an alias for docker container port; both spellings take the same positional arguments. The installed manpage lists no options at all, so do not add guessed flags such as --all or --protocol.

$ docker version --format '{{.Client.Version}}'
29.8.1

Your version may differ. Keep the local help and manpage next to any automation you build, because command details can change between Docker releases.

2. Identify the container safely

CONTAINER can be a name or an ID. Use docker ps to list running containers rather than guessing a name from memory:

$ docker ps --format 'table {{.ID}}	{{.Names}}	{{.Status}}	{{.Ports}}'
CONTAINER ID   NAMES      STATUS          PORTS
b650456536c7   web-demo   Up 54 minutes   0.0.0.0:8080->80/tcp

Set a shell variable to the exact name from your own output:

$ container_name='web-demo'
$ docker inspect --format '{{.Name}}' "$container_name"
/web-demo

This is read-only. If the name is wrong, Docker just says it cannot find the container. If the daemon is unreachable, fix that service or context problem first; do not respond to a connection error by deleting and recreating a container that was actually working fine.

3. List every published mapping

Omit the private port to ask for every mapping Docker knows about for the container:

$ docker port "$container_name"
80/tcp -> 0.0.0.0:8080

The left side is the container's private port and protocol; the right side is the host address and port. An address of 0.0.0.0 means Docker published the port on every IPv4 interface, which is a very different thing from an address that only local processes can reach. Treat a public host binding as a security boundary worth checking properly, not a detail to skim past.

Docker will happily print more than one line. A container with two mappings might show:

$ docker port web-demo
80/tcp -> 0.0.0.0:8080
443/tcp -> 127.0.0.1:8443

Do not assume the host port matches the private port. The first mapping above exposes private port 80 on host port 8080, while the second exposes private port 443 only on the host's loopback address and port 8443.

4. Query one private port directly

Supply a private port when you want one answer instead of the full list. The protocol is optional:

$ docker port "$container_name" 80
0.0.0.0:8080

Use PRIVATE_PORT/PROTO when the protocol matters, or when the container uses both TCP and UDP:

$ docker port "$container_name" 53/udp
0.0.0.0:5353

Keep the slash form exact: 53/tcp and 53/udp are different mappings. If you leave the protocol off, Docker's lookup rules decide the result for you, so spell it out in scripts and incident notes where it matters.

5. Separate a published port from an intended one

A port mentioned in an image description or an application's own documentation is not proof the host can reach it. docker port reports what is actually mapped for this specific container. If it prints nothing, there may genuinely be no published mapping, even though the process inside is listening on a private port.

Compare it against the container's own port information when the distinction matters:

$ docker ps --filter "name=$container_name" --format '{{.Ports}}'
0.0.0.0:8080->80/tcp

The two commands present the same mapping differently; neither changes it. A successful lookup also does not prove a firewall allows the traffic through, that DNS points at the host, or that the service is actually accepting connections.

6. Diagnose the common failures

If Docker reports no public port for the requested private port, check the protocol and then list everything:

$ docker port "$container_name" 80/udp
Error: No public port '80/udp' published for web-demo
$ docker port "$container_name"
80/tcp -> 0.0.0.0:8080

Here the container has TCP port 80 published, not UDP port 80. Fixing the query does not change the container in any way.

If the command says the container does not exist at all, check the active Docker context along with both running and stopped containers:

$ docker context show
default
$ docker ps -a --format '{{.ID}}	{{.Names}}	{{.Status}}'
b650456536c7	web-demo	Up 54 minutes

A context points the CLI at a particular daemon. Inspect it before switching it; changing context is an environment change and can make every subsequent command affect a different host. Do not run docker context use as a blind repair step.

If there is no mapping at all, this command cannot create one for you. Publishing a new port normally means replacing or recreating the container with the right configuration, which can interrupt service and may lose unpersisted data. Take a configuration backup and follow the deployment system's rollback procedure before making that change. Nothing in this guide alters container state, so there is no undo step needed here.