Linux · medium · Networking, DNS & SSH

"Connection refused" against "No route to host" against a timeout

Three different failures that people treat as one. Each names a different layer, and knowing which is which removes most of the guessing.

What you see

A service will not connect. The exact wording of the error is the diagnosis and is usually skipped over.

What is actually wrong

Refused means something answered and said no — the host is up, nothing is listening on that port, or a REJECT rule. No route to host is an ICMP unreachable, usually a firewall rejecting or a genuine routing problem. A timeout means nothing answered at all — a DROP rule or a machine that is not there.

Codes and articles

Connection refusedNo route to hostECONNREFUSEDEHOSTUNREACHConnection timed outETIMEDOUT

Fixes (3)

Find out what is not listening

Root shell on the server15 minuteslow riskreversible

Connection refused. The host is reachable — that is already established by the error itself.

See what is listening and on which address.
Shell
```
sudo ss -tlnp
```
The address column is the point. A service bound to 127.0.0.1 accepts local connections and refuses every remote one, which produces exactly this error and looks like a firewall problem.
If it is bound to loopback only, change the bind address in the service's configuration to 0.0.0.0 or the specific interface address, and restart it.
Confirm the service is running at all.
Shell
```
systemctl status nginx --no-pager -l
```

Check for a REJECT rule, which also produces a refusal.

Shell

sudo nft list ruleset 2>/dev/null | grep -i rejectsudo iptables -L -n -v | grep -i reject

Test locally to separate the service from the network.
Shell
```
curl -sv http://127.0.0.1:8080/ 2>&1 | head -20
```

Confirm it workedss shows the service listening on the expected address and the client connects.

Shell

sudo ss -tlnp | grep :8080

If you need to undo itRestore the previous bind address in the service configuration.

Follow the packet until it stops

Both ends25 minuteslow riskreversible

A timeout. Nothing answered, so the question is where it was dropped.

Establish whether the packet arrives at all.
Shell
```
sudo tcpdump -ni any port 8080 -c 20
```
This settles it in one step. Packets arriving with no reply is a server or firewall problem on this machine; no packets at all is somewhere in between, and the two need completely different investigations.

Trace the path if nothing arrives.

Shell

mtr -rwzbc 20 10.0.0.20traceroute -T -p 8080 10.0.0.20

Check the local firewall for DROP rules.

Shell

sudo nft list ruleset | head -60sudo firewall-cmd --list-all 2>/dev/null

Check for asymmetric routing on a multi-homed machine — a reply leaving by a different interface is silently dropped by reverse path filtering.
Shell
```
ip route get 10.0.0.20sysctl net.ipv4.conf.all.rp_filter
```
Check MTU if it connects and then stalls on larger transfers.
Shell
```
ping -M do -s 1472 10.0.0.20 -c 3
```

Confirm it workedtcpdump shows the handshake completing on both ends.

If you need to undo itNothing was changed by these diagnostics.

Resolve the routing or the rejection

Root shell20 minutesmedium riskreversible

No route to host — an unreachable message came back from somewhere.

Check the local routing table and which route would be used.
Shell
```
ip route showip route get 10.0.0.20
```
If there is no default route, add one — or fix the interface configuration that should have provided it.
Shell
```
sudo ip route add default via 10.0.0.1 dev eth0
```
Check ARP resolution on the local segment. An incomplete entry means the host is not answering at layer 2.
Shell
```
ip neigh show
```
An incomplete ARP entry for a machine on the same subnet points at the switch, the VLAN or a duplicate address — none of which are visible from higher-level tools.
Check for an explicit reject route, which a VPN client can leave behind.
Shell
```
ip route show | grep -E 'unreachable|prohibit|blackhole'
```
Check the far end's firewall is rejecting rather than dropping — a firewalld zone set to reject produces this error rather than a timeout.
Shell
```
sudo firewall-cmd --get-active-zonessudo firewall-cmd --list-all
```

Confirm it workedip route get returns the expected path and the connection succeeds.

If you need to undo itRoutes added with ip route are not persistent and vanish at reboot; remove with ip route del.

Related faults

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.