TroubleByteSearch
SOURCE VERIFIEDSource review Sep 7, 2026No hands-on test claimed2 sources

Docker published port is not reachable

Docker containers are isolated by default, so a service is not reachable from outside the host until the correct container port is published with `-p` or `--publish`; a Dockerfile `EXPOSE` instruction alone does not create a host mapping. A localhost-only host bind can also intentionally prevent remote access.

AuthorshipWritten and source-reviewed by Mihailo Ivanjac
Record created Sep 7, 2026Last source review Sep 7, 2026Source review only
SymptomA containerized service is running, but the published host port cannot be reached locally or from another machine as expected.
Problem familyServers · Docker
Highest step riskCaution
Editorial statePublic launch · indexed
Affected scope
Docker EngineBridge networksdocker run -pDocker Compose ports
Start here

Verify the published port mapping

Check `docker ps` or Compose output for the actual host-to-container mapping. Confirm the application listens on the container port, then verify whether the publish bind is all interfaces or only 127.0.0.1 and whether the host firewall allows the intended access.

  1. Run `docker ps` or inspect the Compose service ports.
  2. Confirm the mapping uses the intended HOST_PORT:CONTAINER_PORT pair.
  3. Inside the container, verify the application is listening on the container-side port.
  4. Test the host port locally before testing from another machine.

Why this branch first: Docker documents that bridge-network services require an explicit published port for access outside the host.

TroubleByte diagnostic diagram for a Docker published port that is not reachable from the host or network.
Docker published-port diagnostic pathTroubleByte · Original TroubleByte editorial diagram
Visual diagnosis

TroubleByte diagnostic path

01
Container

Verify the process listens internally.

02
Publish

Confirm HOST_PORT:CONTAINER_PORT.

03
Bind

Check localhost-only vs external bind.

04
Firewall

Allow only the intended path and retest.

Original TroubleByte diagnostic map. It summarizes the cited troubleshooting order; it is not a vendor screenshot.

Diagnosis

What this usually means

There are three different scopes to keep separate: the process listening inside the container, Docker’s published HOST_PORT:CONTAINER_PORT mapping, and the host/network firewall path. If the mapping is bound to 127.0.0.1, remote clients are intentionally excluded.

What the evidence establishes

What we verified from the source material

Docker’s documentation explains that bridge-network containers are isolated until ports are published, defines HOST_PORT:CONTAINER_PORT mapping, and states that publishing specifically to 127.0.0.1 or ::1 limits access to the Docker host.

Before you change anything

Prerequisites and checks

Prepare first

  • Identify the exact container port the application listens on.
  • Record the Docker publish mapping before recreating the container.
  • Know whether the desired client is local to the Docker host or remote.

Checks that prevent the wrong fix

  • Confirm the service is listening on the expected port inside the container.
  • Inspect the exact host IP, host port and container port shown by Docker.
  • Determine whether the client is on the Docker host or a remote machine.
Scope

Applies to

✓ Docker Engine✓ Bridge networks✓ docker run -p✓ Docker Compose ports
Troubleshooting path

Solutions, in order

01
SAFE · START HERE

Verify the published port mapping

  1. Run `docker ps` or inspect the Compose service ports.
  2. Confirm the mapping uses the intended HOST_PORT:CONTAINER_PORT pair.
  3. Inside the container, verify the application is listening on the container-side port.
  4. Test the host port locally before testing from another machine.

Why this can work: Docker documents that bridge-network services require an explicit published port for access outside the host.

02
CAUTION

Check host bind address and firewall scope

  1. If the mapping begins with 127.0.0.1 or ::1, recognize that it is intentionally local-only.
  2. For remote access, bind to the intended host interface or default all-interface publish only when that exposure is appropriate.
  3. Check the host firewall for the specific published port.
  4. Retest without disabling unrelated firewall protections.

Why this can work: Docker documents that a localhost host-IP publish is only accessible from the Docker host, while default publishing binds to all host addresses.

Verification

How to know the fix actually worked

  1. A local request to the published host port reaches the container service.
  2. If remote access is intended, a remote client reaches the same service through the intended host interface and firewall rule.

Do not count a temporary disappearance of the symptom as a confirmed fix if the problem normally returns after a restart, reconnect or several minutes of use.

Stop conditions

When not to keep changing things

  • If the app is not listening inside the container, stop changing Docker firewall rules and fix the service bind/listen configuration first.

Escalation: If Docker shows the correct mapping and the process is listening but remote traffic is still blocked, inspect the host firewall/routing path. Avoid disabling the firewall globally just to test one published port.

Evidence

Sources used for this record

Primary · checked Sep 7, 2026Docker — Publishing and exposing portsFirst-party documentation used to verify the troubleshooting scope and steps.Corroborating · checked Sep 7, 2026Docker — Port publishing and mappingFirst-party documentation used to verify the troubleshooting scope and steps.
Who reviewed this

Mihailo Ivanjac

This record was written and source-reviewed by Mihailo Ivanjac. Source review means the cited documentation was checked against the troubleshooting order on this page; it does not imply a hands-on reproduction unless the page explicitly says so.

Author profile and editorial scope →
Community troubleshooting

Discuss this exact problem

Share what happened on your system, ask a focused follow-up question, or add evidence that may help someone with the same symptom. Community posts are separate from TroubleByte editorial verification.

Before posting Do not include passwords, API keys, recovery codes, private IP addresses or other secrets. TroubleByte automatically attaches only coarse OS, browser and device-class context. Your full Browser & System Info report is not uploaded automatically.
Start a discussion
Posts are public. Guest identity is pseudonymous and browser-specific.

Loading community discussions…
Keep diagnosing

Related Servers problems

DockerDocker container keeps restarting in a loopA Docker container that repeatedly returns to a running/restarting state can be caused by its main process exiting while a restart policy relaunches it. First inspect the container state, restart count and policy; also note that Docker only activates a restart policy after the container has started successfully for at least 10 seconds.DockerDocker container DNS resolution not workingDocker containers normally inherit or proxy DNS based on the network they use. Default-bridge containers receive resolver settings derived from the host, while custom networks use Docker’s embedded DNS. Loopback resolvers such as 127.0.0.1 on the host are a common mismatch because that address means the container itself inside its network namespace.DockerDocker: no space left on deviceDocker can consume substantial storage through images, stopped containers, build cache and volumes. A no-space error may also come from the host filesystem or inode exhaustion. Docker provides docker system df to measure daemon usage and conservative prune commands that only remove categories you explicitly choose.
Change log

Revision history

Show 1 recorded revision

2026-09-07 — Created for the v0.8 content-scale pass from current first-party documentation; held noindex for editorial review.