Q: Your Docker container is running, but the application is not accessible from the host or network. Where would you start?
A Docker container is reported as Up and running, but external HTTP requests fail with Connection Refused or Timeout. Diagnosing port mappings, 0.0.0.0 vs 127.0.0.1 bindings, and Docker bridge iptables.
Want to master this scenario in a live sandbox? KodeKloud's Docker Certified Associate (DCA) Hands-On Lab Course covers this exact problem with hands-on terminal drills.
🛠️ Production Runbook & Step-by-Step Resolution
Inspect Host Port Publishing vs. Container Expose
Check 'docker ps' PORTS column. An EXPOSE 80 in a Dockerfile does not publish the port to the host. You must explicitly publish it using -p
# Check if port is published:
docker ps --format "table {{.Names}} {{.Status}} {{.Ports}}"
# Output showing '80/tcp' means NOT published to host!
# Output showing '0.0.0.0:8080->80/tcp' means correctly published.Check Interface Binding Inside the Container: 0.0.0.0 vs 127.0.0.1
The most common architectural bug: the application server inside the container binds to 'localhost' (127.0.0.1). Because each container has its own network namespace, 127.0.0.1 only accepts traffic from inside the container. It MUST bind to 0.0.0.0 (all interfaces) to receive traffic forwarded from the host.
docker exec -it <container_name> netstat -tlpn
# Or using ss:
docker exec -it <container_name> ss -tlpn
# Look for 0.0.0.0:<port>, NOT 127.0.0.1:<port>Test Local Connectivity Inside the Container
Determine if the application itself is responsive or crashed on an internal thread lock.
docker exec -it <container_name> curl -v http://localhost:<port>/healthVerify Host Firewall & Docker iptables Forwarding
Linux firewalls (UFW, firewalld) can conflict with Docker's native iptables chains. If UFW has a default DROP forward policy, Docker NAT traffic from external clients will be dropped.
sudo iptables -L DOCKER -n -v
sudo ufw status verboseCheck Container Logs & Resource Exhaustion
Check if the process is stuck in a deadlock, out of memory, or stalled on an unreached database connection.
docker logs <container_name> --tail=50
docker stats <container_name> --no-stream- Start with 'docker ps' to verify port publication: ensure you see '0.0.0.0:host_port->container_port', not just an unpublished '80/tcp'.
- Check the application binding interface inside the container: the app must bind to 0.0.0.0, not 127.0.0.1, to receive bridged traffic.
- Exec into the container and curl localhost:port to isolate whether the app itself is healthy or hung.
- Inspect host iptables and firewall (UFW/firewalld) to ensure the DOCKER chain allows packet forwarding.
- Review container stdout/stderr logs to verify that the application completed its startup sequence and is listening.