Container port published but not reachable from outside
When a published container port answers on the host itself but not from outside, the container mapping is usually fine. Something on the host is dropping the inbound connection. The most common culprit on a hardened box is the host firewall: a default-drop nftables/iptables policy blocks the port unless you explicitly allow it. Confirm the mapping, then check the firewall.
What it means
Publishing a port (`-p 8080:80`) tells the container runtime to forward host:8080 to the container. But inbound packets still traverse the host's firewall first. A default-deny input policy (the right posture for a server) drops anything you didn't explicitly permit, so the forwarded port is unreachable from other hosts until a rule admits it.
Most common causes
- Host firewall default-drops the port. An nftables/iptables input chain with a drop policy blocks the published port unless a rule allows it. This is the usual reason it works locally but not remotely.
- Port not actually published. No `-p`/`ports:` mapping, or mapped to a different host port than you're testing. Confirm the mapping with `docker ps`.
- App bound to localhost only. If the service inside binds 127.0.0.1, only the container itself can reach it. It must listen on 0.0.0.0.
- Upstream firewall / security group. A cloud security group or network firewall in front of the host can drop the port before it ever reaches the box.
How to fix it
- Confirm the mapping with `docker ps` and that it works from the host itself (`curl localhost:<port>`).
- Check the host firewall: does the input chain default-drop, and is the published port permitted?
- Add a rule allowing the port (scoped to the sources that should reach it), keeping the default-drop posture.
- Confirm the service binds 0.0.0.0, and check any cloud security group in front of the host.