Publish multiple ports from a Docker container
Use repeated port mappings, select host interfaces and protocols, and verify each listener through its real client path.
Repeat -p for each container port you want to publish. Publishing creates an access path; it does not start a listener inside the container or configure TLS for an application.
docker run -d --name web \
-p 8080:80 \
-p 8443:443 \
-p 127.0.0.1:9090:9000 \
myapp:1.2
This example assumes the image actually serves the intended protocols on ports 80, 443, and 9000. The first two mappings use the default host binding, normally all interfaces. The management port is limited to host loopback in the intended configuration. Review host routing and firewall rules before relying on any exposure boundary.
Choose the mapping form
| Example | Meaning |
|---|---|
-p 8080:80 |
Host TCP 8080 to container TCP 80 |
-p 127.0.0.1:8080:80 |
Bind the host-side mapping to loopback |
-p 192.168.1.5:8080:80 |
Bind to that configured host address |
-p 5353:53/udp |
Publish UDP rather than the default TCP |
-p 8000-8010:8000-8010 |
Map corresponding ports in equal-sized ranges |
For a service requiring both TCP and UDP, publish each protocol explicitly. Confirm the host address exists and that the selected port/protocol is available. Older Docker releases have known localhost-publishing limitations; use maintained versions and validate the boundary from the relevant network.
Configure Compose
services:
web:
image: myapp:1.2
ports:
- "8080:80"
- "8443:443"
- "127.0.0.1:9090:9000"
Dockerfile EXPOSE 80 443 describes intended ports; it does not publish them itself. docker run -P publishes exposed ports to automatically allocated host ports. Explicit -p mappings do not require an EXPOSE declaration.
Verify the actual traffic path
docker port web
curl --fail http://127.0.0.1:8080/
Inspect the application's listeners using its own tools or ss if present. A host ss listing alone is not conclusive: Docker can implement publication through forwarding rules rather than a user-space listener that appears as expected in the socket table.
Test HTTPS with the correct hostname and certificate trust, and test non-HTTP protocols with suitable clients. Start from the real client network, not only from inside the container.
FAQ
What if the host port is occupied?
Use another host-side port or identify why the existing listener is there before stopping anything. The container-side port stays the application's actual listening port.
Are large ranges expensive?
They can add forwarding-rule or proxy overhead, depending on the backend and daemon settings. Do not assume every mapping always creates a user-space proxy process. Measure the deployment before choosing host networking, which changes isolation and port-conflict behavior.
For ongoing HTTP verification, Guance HTTP tests can check each authorized entry point's response and latency. Do not expose a private management endpoint merely to make it reachable by a public probe.
See port publishing and container run.
Contact us
Join the community
to join the community
Try Guance
Start online and pay only for what you use.
Get startedChoose a Guance plan