Fix "No route to host" on Linux

ping -c 3 192.168.1.20
nc -vz -w 5 192.168.1.20 22
# on the target, if ping works (Fedora / RHEL / openSUSE firewalld):
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

You see this from many programs; the core text is the same:

ssh: connect to host 192.168.1.20 port 22: No route to host
curl: (7) Failed to connect to 192.168.1.20 port 8080 after 3072 ms: No route to host
connect: No route to host
From 192.168.1.10 icmp_seq=1 Destination Host Unreachable

What the error means

The kernel returned EHOSTUNREACH. Despite the wording, your routing table is usually fine. The message appears in two very different situations:

1. The host does not answer on the local network. For an address on your own subnet, the kernel asks "who has 192.168.1.20?" with ARP (or IPv6 neighbour discovery). If nobody answers after a few seconds, the connection fails with No route to host.
2. Something sent back an ICMP "host unreachable" or "prohibited" message. A router that cannot deliver the packet, or a firewall configured to reject, sends this, and Linux turns it into the same error.

Compare with the related messages: if your machine has no route at all you get Network is unreachable; if packets vanish without any reply you get Connection timed out; if the host answers but nothing listens on the port you get Connection refused.

Step 1: tell the two cases apart

ping -c 3 192.168.1.20
ip neigh show 192.168.1.20
ip route get 192.168.1.20

Example output when the host is gone:

From 192.168.1.10 icmp_seq=1 Destination Host Unreachable
192.168.1.20 dev wlan0 FAILED
192.168.1.20 dev wlan0 src 192.168.1.10 uid 1000

FAILED or INCOMPLETE in the neighbour table means nothing answered ARP: go to cause 1. A REACHABLE or STALE entry with a MAC address, and a ping that works, means the host is there and something rejects the connection: go to cause 2.

Cause 1: the host is off or has a different address

This is the most common reason on home and office networks. The machine is asleep, powered off, disconnected from Wi-Fi, or received a new address from DHCP. Find out which addresses are actually in use:

# on the target, if you can reach its console
ip -br addr
# from your machine: list neighbours that answered recently
ip neigh

Your router's DHCP lease list is another quick way to find the current address. Give servers and printers a fixed address so this does not keep happening; see how to set a static IP. Also check the target is on the same network: guest Wi-Fi and many public networks use "client isolation", which blocks devices from reaching each other and produces exactly this error.

Cause 2: a firewall rejects the port (ping works)

firewalld, the default firewall on Fedora, RHEL-family and openSUSE, rejects connections to closed ports with an ICMP "prohibited" reply instead of dropping them. Linux reports that as No route to host. So ping succeeds, but SSH, a web server or NFS on that host fails with this message. Open the service on the target:

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=ssh        # or http, https, nfs ...
sudo firewall-cmd --permanent --add-port=8080/tcp      # for a custom port
sudo firewall-cmd --reload

Hand-written iptables or nftables rules with REJECT --reject-with icmp-host-prohibited (common in some cloud images, for example Oracle Cloud's Ubuntu images) behave the same way:

sudo iptables -S | grep -i reject
sudo nft list ruleset | grep -i reject

ufw drops by default rather than rejecting, so on Ubuntu a closed port usually times out instead. See the firewall guide for both tools. Do not turn the firewall off as a fix; open only the port you need.

Cause 3: wrong subnet, gateway or VPN routes

If the address is on a different network, packets go to your gateway. When the gateway itself is unreachable, or a router further along reports the host as unreachable, you get this error too. Check the route the kernel chose:

ip route get 10.20.0.5
ip route

Things to look for:

• A wrong prefix length on a static address (/16 instead of /24) makes the kernel think a remote host is local, so it tries ARP and fails.
• A VPN that installed a route for the target subnet into its tunnel, where nothing answers.
• Docker or libvirt bridges whose subnet overlaps your LAN (for example a 172.17.0.0/16 or 192.168.122.0/24 bridge that matches a real network). The route via docker0 or virbr0 wins and the real host becomes unreachable. Change the bridge subnet (Docker: "bip" in /etc/docker/daemon.json).

Our Linux networking guide explains reading ip route output.

Cause 4: IPv6 addresses

When a name resolves to an IPv6 address and the target's IPv6 is not configured on that network, you can get No route to host for IPv6 while IPv4 would work. Test with ssh -4, curl -4 or ping -4. If IPv4 works, fix the target's IPv6 or remove the stale AAAA record.

Distro notes

• Fedora, RHEL, Rocky, Alma, openSUSE: firewalld is enabled by default, which makes cause 2 the first suspect when ping works.
• Ubuntu, Debian, Mint: no rejecting firewall by default; ufw drops. Cause 1 or 3 is more likely. NetworkManager handles desktop networking; servers use netplan (Ubuntu) or /etc/network/interfaces (Debian).
• Arch: no firewall unless you add one; check your own nftables rules if you wrote any.
• Raspberry Pi OS and other headless devices: a changed DHCP address after a reboot is the usual cause. Reserve the address on the router.

How to prevent it

• Use fixed addresses or DHCP reservations for anything you connect to by IP.
• When you install a service on a firewalld system, open its port in the same step.
• Pick Docker and VM bridge subnets that do not overlap the networks you use, including office and VPN ranges.
• Keep a quick checklist: ping, ip neigh, nc -vz. Together they tell you in seconds whether the problem is the host, the firewall or the route. The SSH cheat sheet has more connection tests.

Frequently asked questions