"Connection timed out" vs "Connection refused": what each one tells you, and how to fix it

1. Test from the client, with a short timeout

Without a limit, a timed-out connection hangs for about two minutes (the kernel retries the first packet several times). Give your test tools a few seconds instead:

curl -m 5 http://app01:8080/health
nc -zv -w 5 app01 8080

Then test a port you know works — SSH is usually open:

nc -zv -w 5 app01 22

If port 22 answers and 8080 times out, the machine is up and the network is fine: something drops traffic to that port only. That’s a firewall rule, almost always.

2. Check the service on the server

Log in to the server and look at what really listens:

ssh app01
ss -tln | grep 8080
curl -s http://localhost:8080/health

LISTEN 0      4096       127.0.0.1:8080       0.0.0.0:*

Two things to read here. The service runs, and it answers locally — so the app itself is fine. And it listens on 127.0.0.1: only programs on the same machine can reach it. Keep that in mind; it will come back in section 4. (Use sudo ss -tlnp to also see which process holds the port.)

3. Timed out: the firewall drops it

Ubuntu / Debian — ufw. With ufw active, everything that isn’t allowed is dropped: the client waits and times out.

ssh app01
sudo ufw status
sudo ufw allow 8080/tcp

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

Better still, allow only who needs it: sudo ufw allow from 10.0.0.0/24 to any port 8080 proto tcp.

RHEL / Rocky / AlmaLinux — firewalld. The default public zone rejects what isn’t allowed, so the client gets No route to host instead of a timeout:

ssh app01
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

--permanent alone changes the saved configuration but not the running one, and a rule added without --permanent works only until the next reload or reboot. Add it with --permanent, then --reload — as above.

Is the port one that should be reachable from outside at all? Databases, Redis or the Docker API should not — the Port Lookup tells you, port by port.

4. Refused: nothing listens on that address

After opening the firewall, try again from the client:

ssh app01 sudo ufw allow 8080/tcp
curl -m 5 http://app01:8080/health

curl: (7) Failed to connect to app01 port 8080 after 0 ms: Couldn't connect to server

Progress: the packets now reach the machine, and the machine answers — “refused”. Remember section 2: the app listens on 127.0.0.1, so connections that arrive on the network interface find nothing there. Make it listen on all addresses (0.0.0.0), or on the server’s private address. Where that’s set depends on the app: a --bind/--host option, listen in nginx, listen_addresses in PostgreSQL, bind in Redis. Here it’s a config file:

ssh app01 cat /etc/myapp/config.env
ssh app01
sudo sed -i "s/^BIND_ADDRESS=.*/BIND_ADDRESS=0.0.0.0/" /etc/myapp/config.env
sudo systemctl restart myapp && ss -tln | grep 8080
exit
curl -m 5 http://app01:8080/health

ss now shows 0.0.0.0:8080, and the request from the laptop gets its answer.

Other reasons for “refused”: the service isn’t running at all (systemctl status, see Job for … failed), it listens on a different port than you think, or you’re connecting to the wrong machine (an old DNS record, a typo in the IP). The same applies to databases: see MySQL, SQL Server and MongoDB.

5. Inside containers

The same rules apply one level down. A container that publishes -p 127.0.0.1:8080:80 is reachable only from the host itself; an app inside a container that listens on 127.0.0.1 is unreachable even through a published port — it must listen on 0.0.0.0 in the container. And from inside a container, localhost is the container, not the host: see connecting from a container to localhost.