The service runs, but from the outside the port is dead. This is the single most common technical ticket, and in most cases the fix takes one command. Walk this checklist top to bottom and you will find the broken link.

First, understand what "closed" means

A connection to a port dies in one of three places: the application is not listening, the server firewall drops the packet, or the client side never reaches the server at all. The checklist below separates them.

Step 1: is anything listening?

ss -tlnp | grep :8080

No output means the application simply is not listening on that port. Check its config and logs; the firewall is innocent.

Output like 127.0.0.1:8080 means the app listens only on localhost and will never accept outside connections. Change its bind address to 0.0.0.0 (or the server IP) in the application config and restart it.

Step 2: test from the server itself

curl -v http://127.0.0.1:8080/

If this fails, the problem is the application, full stop. If it works locally but not from outside, continue.

Step 3: which firewall is actually active?

Modern distributions ship different tools, and often two at once. Check them all; the one with rules wins:

sudo ufw status verbose            # Ubuntu/Debian
sudo firewall-cmd --list-all       # AlmaLinux/Rocky
sudo iptables -L -n | head -30
sudo nft list ruleset | head -30

Step 4: open the port in the right tool

# ufw
sudo ufw allow 8080/tcp

# firewalld
sudo firewall-cmd --add-port=8080/tcp --permanent
sudo firewall-cmd --reload

Step 5: verify from a different network

nc -vz your.server.ip 8080

Test from a machine outside the server, ideally from a different network than your office Wi-Fi: corporate networks love to block unusual ports on their side.

Classic traps we see in tickets

  • Docker publishes ports itself: a container without -p 8080:8080 is reachable from nowhere, whatever the firewall says.
  • The app was restarted, but the old process still holds the port. ss -tlnp shows the PID; make sure it is the process you think it is.
  • Port 25 outbound is a special case on most hosting platforms, including ours: it is restricted by default as an anti-spam measure. If you need to send mail, use a relay on port 2525/587 or write to support.
  • Testing "from outside" through a VPN that routes you back through the same network proves nothing. Use a mobile connection for a clean check.
Walked the whole list and the port is still dead from outside while alive locally? Now it is a ticket for support: attach the outputs of steps 1 and 3, and we will take it from there.