Fix: Connection refused and Connection timed out, what each one means

These two errors look similar but say opposite things. Reading them correctly saves a lot of random restarting.

curl: (7) Failed to connect to 192.0.2.10 port 8080: Connection refused
ssh: connect to host 192.0.2.10 port 22: Connection timed out
nc: connect to 192.0.2.10 port 5432 (tcp) failed: No route to host

Connection refused: the host is there, the port is not

Your packets reached the machine and its kernel replied “nothing is listening on that port” (a TCP RST). This is good news: name resolution, routing and usually the firewall are fine. Causes, in order of likelihood:

1. The service is not running. On the server: systemctl status myapp, docker ps.
2. It is running but on a different port. On the server: sudo ss -ltnp and compare with what you are connecting to.
3. It listens only on 127.0.0.1, so it answers local connections but refuses remote ones. The same ss output shows this. Databases do this by default; change the bind address in the service config (for example listen_addresses in PostgreSQL, bind-address in MySQL) only if remote access is really intended, and then restrict it with the firewall.
4. You are connecting to the wrong host: a typo in the address, or the name resolves to an old address. dig +short name.
5. Some firewalls are configured to reject instead of drop, which produces the same message. On the server, sudo ufw status verbose or sudo firewall-cmd --list-all.

Connection timed out: nothing came back

Your packets went out and nothing at all returned, not even a refusal. After a while the client gives up. Something between you and the service silently dropped the traffic, or the address does not lead anywhere. Check from the outside in:

1. Is the address right and reachable at all? ping 192.0.2.10. Many hosts block ping, so a failed ping is not proof, but a successful one rules out routing.
2. Is it just this port? nc -zv 192.0.2.10 22 against a port you know is open (SSH). If SSH connects and 8080 times out, a firewall is dropping 8080.
3. On the server, is the port open in the host firewall? sudo ufw status / sudo firewall-cmd --list-all. Cloud servers also have a security group or network firewall in the provider’s console that must allow the port; this is the single most common cause on fresh cloud machines.
4. Is the service listening on 0.0.0.0 and not only on localhost? A localhost-only listener plus a firewall that drops gives a timeout too.
5. Is the route broken? traceroute 192.0.2.10 (or mtr) shows where replies stop. Inside a company network, a VPN that is not connected is a classic cause.

No route to host and Network is unreachable

No route to host usually means the last router knew the address was on its local network and nobody answered the ARP request: the machine is off, or the address is wrong. On a Linux server it can also come from firewalld, whose default reject rule answers with an ICMP “host prohibited” message. Network is unreachable means your own machine has no route for that address: you are offline, or you are trying to reach an IPv6 address without IPv6 connectivity (try curl -4).

Quick table

• refused: fix the service or its bind address on the server.
• timed out: fix the firewall, security group or address; the service itself may be fine.
• no route to host: wrong address, machine down, or firewalld reject.
• network unreachable: fix your own connectivity or route.
• name or service not known / could not resolve host: DNS, not the connection at all.

The port-check script in this topic turns these checks into one command you can run against a list of host:port pairs.

Official documentation

• tcp(7)
• connect(2): the ECONNREFUSED and ETIMEDOUT errors
• curl manual