Check which Docker ports are exposed publicly

A container's listening port is not automatically the same as a publicly reachable host port. Docker publishing creates that connection, and an unspecified host address commonly exposes a port on all host interfaces. This guide is for an administrator of a Linux Docker Engine host. It inspects exposure first and avoids flushing firewall rules or restarting every container.

Inventory the running configuration

docker ps --format 'table {{.Names}}	{{.Ports}}'
docker port example-container
docker inspect --format '{{json .HostConfig.PortBindings}}' example-container
sudo ss -ltnp
sudo ss -lunp

Replace the container name. Docker socket access is powerful; use an already authorized account rather than changing socket permissions. Save outputs privately and redact sensitive names before sharing. TCP and UDP are separate mappings, so checking only TCP misses many game and discovery protocols.

Compare the configured publish address with your intended clients. A host mapping such as 127.0.0.1:8080:80 serves a different purpose from 8080:80. Also check IPv6 bindings and the host-network mode: containers sharing the host network do not use ordinary published-port mappings.

Account for the network model

Inspect the container's network mode and the relevant Docker network configuration. Bridge gateway modes, direct routing and version-specific behaviour affect reachability. Do not treat one loopback example as a universal security guarantee. Older Docker versions also have documented localhost-publishing caveats, so check the version and official port-publishing documentation.

A host firewall frontend alone may not describe Docker exposure accurately. Docker installs networking rules, and its interaction with tools such as UFW requires specific consideration. Do not disable Docker's rule management or flush its chains to test connectivity; that can interrupt unrelated services.

Prepare a narrowly scoped correction

Find the Compose file or deployment definition that created the container. Save it and identify every volume, network and dependency before a recreation. Changing a published bind address normally requires replacing the container instance through its deployment workflow. That operation is not safe to improvise when persistent data has not been identified.

If the service should be reached only by a local reverse proxy, a loopback mapping may fit that design. If legitimate remote clients need it, define their actual access requirements first. Do not close a database port used by another host until an alternative route has been tested. Keep an existing management connection open throughout.

Verify from the right locations

Test the application from its intended client network and, where authorized, from a location that should be denied. A successful localhost request proves only the local path. Record the protocol, destination address, port and time of each test. Check application logs alongside the network result.

If the change breaks a dependency, restore the previous deployment definition and recreate only the affected service using its established procedure. Verify data mounts before and after. Exposure auditing should leave you with a documented reason for each published port, not an unexplained collection of emergency firewall exceptions.

Connect using SSH. Diagnose network timeouts.

Reference: Official documentation. Check the documentation installed on your own operating-system release when an option differs.