Destination host unreachable
Published 15 September 2026
This reply did not come from the host you pinged. It came from a router that could not forward your packet any further, and the address it came from is the most useful field on the screen.
Read the source address first
C:\> ping 10.50.0.20
Reply from 10.10.0.1: Destination host unreachable.
10.10.0.1 is doing the talking. Your packet reached that
router, the router had nowhere to send it, and it returned an ICMP
unreachable message. That single fact splits the problem in half:
- The source is your own machine's address: your host never got the packet onto the wire. Its routing table has no route, or ARP failed for the next hop. Look locally.
- The source is your default gateway: you got one hop. The gateway has no route to that destination. Look at the gateway's routing.
- The source is a router further away: everything up to that point works. Routing stops there, and you now know precisely where.
On Linux and macOS the same event reads as From 10.10.0.1 icmp_seq=1
Destination Host Unreachable. Same message, same reasoning.
Versus "Request timed out"
They mean opposite things, which is why mistaking one for the other sends people in the wrong direction.
| Message | What happened | Where to look |
|---|---|---|
| Destination host unreachable | Something answered, and said no | Routing, at the device that replied |
| Request timed out | Nothing answered at all | The destination, or a firewall silently dropping |
Unreachable is the more informative failure. You received a reply, from a known address, with a stated reason. A timeout tells you only that silence came back, and silence is frequently normal, because plenty of hosts are configured not to answer ping at all.
Host unreachable versus network unreachable
Both exist, and the distinction is real. Network unreachable (ICMP type 3, code 0) means the router has no route to that network whatsoever. Host unreachable (type 3, code 1) means it knows the network, believes it is directly attached, and cannot find that specific host on it: usually because ARP got no answer.
So host unreachable from your last-hop router is often a layer 2 problem wearing layer 3 clothing: the machine is off, on a different VLAN, or has a different address than you think.
The order worth working in
- Note who replied. That is the device with the problem, or the last one that worked.
- Check your own routing table if the reply came from your own
address:
route print,ip route, ornetstat -rn. - Ping the gateway. If that fails too, the problem is local and nothing beyond it matters yet.
- Check the ARP table for the destination if it is supposed to
be on your own subnet:
arp -a. An incomplete entry is the answer. - Traceroute to see how far you get. Do not be alarmed by asterisks in the middle; they usually mean nothing.
Causes, in rough order of how often they turn out to be true
- The destination is off, or has a different address. Worth eliminating before touching any configuration.
- A missing return route. Your packets arrive; the replies have no way back. Common with a new subnet that was added on one router and not another, and it looks identical to a forward-path problem from your end.
- Wrong subnet mask. A host with the wrong mask believes a remote address is local, ARPs for it, gets nothing, and reports host unreachable from itself. The subnet mask table is the quick check.
- A firewall configured to reject rather than drop. Rejecting politely returns exactly this message. It is deliberate, not broken.
- VLAN or switching problem. Layer 3 configuration is right and the frames are not arriving.
Kodura Network Tools runs ping and traceroute from your iPhone or iPad and reports what the results mean rather than only what they say: including which hop answered and whether a silent hop matters. It also does DNS lookups, TCP port checks and path MTU discovery against the same target, which is the sequence this problem usually needs.
If the application says something different
A program will rarely print "destination host unreachable". It receives the same ICMP message and surfaces it in its own words: most often no route to host, which is the socket error behind it, and which distinguishes this case from a refused connection and from a timeout.