No route to host

Published 15 September 2026

Three errors get treated as one: no route to host, connection refused, and connection timed out. They are produced by three different events and each one points somewhere else. Knowing which you have is most of the diagnosis.

The three, side by side

Error	errno	What it means	Look at
No route to host	EHOSTUNREACH	A router, or your own kernel, said it cannot get there	Routing, ARP, a rejecting firewall
Connection refused	ECONNREFUSED	You reached the host. Nothing is listening on that port	The service, and which port it bound
Connection timed out	ETIMEDOUT	Silence. Nothing answered at all	A dropping firewall, or the host is down

Refused is good news. It proves the network path works end to end: packets reached the host and it answered, just with a rejection. The entire problem is the service.

Timed out is the least informative. Nothing came back, and a silent drop is what a well-configured firewall is supposed to do.

No route to host sits in between. Something along the way actively told you it could not deliver, so unlike a timeout, you have a witness.

Where the message actually comes from

Your application prints it, but it did not decide it. The kernel returned EHOSTUNREACH, for one of three reasons:

An ICMP unreachable arrived from a router on the path. That is the same message ping shows as destination host unreachable, surfaced through a socket instead.
Your own routing table has no route: not even a default. The packet never left.
ARP failed on the local segment. Your host believes the destination is directly attached, asked who has that address, and nobody answered.

Reason three is worth dwelling on, because it is the one that catches experienced people. It usually means a wrong subnet mask: with a /16 where a /24 was intended, a host treats half the world as local and ARPs for addresses that are several routers away. Nothing replies, and you get no route to host for a destination that is perfectly reachable through the gateway you are ignoring. The subnet mask table settles it quickly.

Working it out

ip route get 10.50.0.20        # which route would be used, if any
ping -c 3 <default gateway>     # is the first hop alive
arp -n | grep 10.50.0.20        # incomplete entry = ARP failed
ip -br addr                     # confirm your own address and prefix

ip route get is the fastest of these and the most commonly skipped. It tells you exactly what the kernel would do with a packet for that address (which interface, which gateway, which source address) or says plainly that there is no route.

The firewall case that looks like routing

A packet filter can produce this deliberately. On Linux:

iptables -A INPUT -j REJECT --reject-with icmp-host-unreachable

That rule makes a perfectly reachable host report no route to host. Nothing is wrong with routing; a firewall is being polite about refusing you.

The tell is inconsistency: reachable from one source address and not another, or reachable on one port and not another. Genuine routing failures do not care which port you asked for. If TCP 443 is refused this way while TCP 22 works, it is a filter.

The check that separates all three cases

Try two different ports on the same host. The pattern is diagnostic:

Both say no route to host: routing or ARP. Port-independent, so it is below the transport layer.
One refused, one not: the path is fine. It is the service.
One works, one says no route: a firewall rejecting selectively.
Both time out: silent drop, or the host is down.

Kodura Network Tools runs that comparison for you: a TCP port check against several ports at once, plus ping and traceroute against the same target, so you can see whether the failure is port-specific in one pass. It runs on iPhone and iPad, which is useful when the machine that is failing is not the one in your hand. To check the same host from the public internet instead, the open port checker does it here.

Download on the App Store

If it is intermittent rather than absolute

No route to host is normally deterministic: it fails the same way every time. If instead the connection establishes and then stalls, this is not your error: that shape points at path MTU, where small packets pass and large ones vanish. See SSH connects, then hangs. If the established flow ends with an RST, use the packet direction and timing in TCP connection reset to find the device that aborted it.