Fix No Route to Host Error on Linux

If you see “No route to host” on Linux, it means your computer cannot find a network path to the destination IP address. This usually happens because of a wrong IP address, a down network interface, a firewall dropping packets, or a missing route. The fix is to check your network configuration, verify the destination is reachable, and adjust your firewall or routing rules.

What Exactly Does “No Route to Host” Mean?

When you try to connect to another machine (e.g., with ssh, ping, or curl), your Linux system sends packets through its network stack. The kernel looks up the destination IP in its routing table. If no route matches, the kernel immediately returns an error. The error is often reported as No route to host by user-space tools, but the underlying errno is EHOSTUNREACH (numeric 113).

This is different from Network is unreachable (ENETUNREACH), which means there is no route to the entire subnet, not just the specific host. It is also different from Connection timed out, which means packets are being sent but no reply comes back (likely due to a firewall or a down remote host).

Quick Fixes to Try First

Start with these simple checks. They resolve most cases:

Ping the destination – ping 192.168.1.10. If you get replies, the route exists and the host is up. If you get “No route to host”, continue.
Check your IP address – ip addr show. Make sure your interface has an IP address and is up (state UP). If it’s DOWN, bring it up with sudo ip link set dev eth0 up.
Check the routing table – ip route show. You should see a default route (default via …) or a specific route to the destination subnet. If not, add one: sudo ip route add default via 192.168.1.1.
Test with traceroute – traceroute -n 8.8.8.8 shows where the path stops. If it stops at your gateway, the problem is upstream.

Check Your Firewall (iptables/nftables)

Linux firewalls can generate “No route to host” when they drop packets with REJECT (not DROP). A REJECT rule sends back an ICMP host-unreachable message, which the local system reports as “No route to host”. This is common with ufw or firewalld.

To see if your firewall is rejecting outbound traffic:

List current rules: sudo iptables -L -n -v (or sudo nft list ruleset).
Look for REJECT rules with --reject-with icmp-host-unreachable.
Temporarily disable the firewall to test: sudo ufw disable or sudo systemctl stop firewalld. If the error disappears, adjust your firewall rules.
Allow the specific port or IP: sudo ufw allow from 192.168.1.0/24.

Remember to re-enable your firewall after testing.

Verify the Destination IP and Subnet

Sometimes the destination is simply not reachable because it’s on a different subnet and there is no route. For example, if your machine is on 192.168.1.0/24 and you try to reach 10.0.0.5, you need a route to that subnet via a router. Without it, the kernel says “No route to host”.

Check your subnet mask: ip addr show. If you are using a /24 mask (255.255.255.0), you can only reach addresses in the same range directly. For other subnets, you need a gateway. If you have a gateway, it should be listed in your routes. If not, add a static route:

sudo ip route add 10.0.0.0/24 via 192.168.1.1

Inspect ARP and Neighbor Tables

On a local network, your machine needs to resolve the destination IP to a MAC address using ARP (IPv4) or NDP (IPv6). If the ARP resolution fails, you get “No route to host” because the kernel cannot send the frame. Check with:

ip neigh show

If the entry for the destination shows FAILED or INCOMPLETE, the remote host is not responding to ARP. Possible reasons:

The remote host is down or has a different IP.
You are on a VLAN or wireless network that isolates clients.
The remote host has a firewall that blocks ICMP (but ARP is not ICMP, so it should still work).

To clear a stale neighbor entry: sudo ip neigh del 192.168.1.10 dev eth0 and try again.

Common Misconception: It’s Always the Remote Firewall

Many users assume “No route to host” means the remote machine’s firewall is blocking them. While that can happen (if the remote sends a REJECT), more often the error is local. The kernel checks its own routing table first. If there is no route, it never even sends a packet. So before blaming the remote, verify your local routes and firewall.

Another misconception: “No route to host” is the same as “Connection refused”. They are different. Connection refused (ECONNREFUSED) means the remote host is reachable but no service is listening on that port. No route to host means the packet cannot even be delivered to the network.

Advanced: Routing Tables and Policy Routing

If you have multiple network interfaces or use policy routing (ip rules), the route lookup may be more complex. The kernel uses the routing table selected by the ip rule list. If you have rules that direct traffic to a different table, that table might not have the needed route. Check:

ip rule show
ip route show table all

If you see a rule that sends traffic to a custom table, make sure that table has a default route or a specific route. You can add a route to a specific table:

sudo ip route add default via 192.168.1.1 table 100

Also check if the interface has rp_filter (reverse path filtering) enabled. If it is strict, and the return path is asymmetric, the kernel may drop packets, leading to timeouts rather than “No route to host”, but it’s worth checking: sysctl net.ipv4.conf.all.rp_filter.

Frequently Asked Questions

Q: Why do I get “No route to host” when pinging my own IP?
If you ping your own IP and get this error, your loopback interface or your network interface may be down. Check ip addr show lo – it should have 127.0.0.1/8 and state UNKNOWN (which is normal for loopback). If it’s down, bring it up with sudo ip link set lo up. Also check that your main interface has an IP.

Q: Can a VPN cause “No route to host”?
Yes. When a VPN is active, it often adds routes that send all traffic through the tunnel. If the VPN tunnel is down or misconfigured, those routes point to a non-existent interface, causing the error. Disconnect the VPN and see if the issue persists. If it does, check the VPN configuration.

Q: How do I fix “No route to host” for SSH?
First, try to ping the SSH server. If ping works, the route is fine, and the issue is likely a firewall on the server blocking port 22. If ping fails, follow the steps above: check local routes, firewall, and ARP. Also verify the SSH server is running and listening on the expected IP.

Q: Does IPv6 cause this error?
Yes, you can get “No route to host” for IPv6 addresses if there is no IPv6 route. Use ip -6 route show to check. If you have no IPv6 connectivity, but the destination has an IPv6 address, your system may try IPv6 first and fail. You can force IPv4 with ping -4 or curl -4.

Q: Why does it work after I restart the network service?
Restarting the network service (e.g., systemctl restart networking) re-applies all configuration files. If a temporary misconfiguration or a stale route was the issue, restarting clears it. To make the fix permanent, edit your network configuration files (e.g., /etc/network/interfaces or Netplan YAML) to include the correct routes and DNS.

When to Use a Static Route vs. Default Gateway

If you need to reach a specific subnet that is not your local one, you have two options: add a default gateway (which sends all unknown traffic to that gateway) or add a static route for that subnet only. A default gateway is simpler but may not be correct if you have multiple uplinks. A static route is more precise:

sudo ip route add 10.0.0.0/8 via 192.168.1.254

To make it permanent, add it to your network configuration. On Debian/Ubuntu, edit /etc/network/interfaces and add up ip route add ... under the interface. On RHEL, create a route file in /etc/sysconfig/network-scripts/. On Netplan, add a routes: section.

If none of these steps resolve the error, check for network hardware issues (cable, Wi-Fi signal) and verify the remote host is actually running. You can also use tcpdump -i any icmp to see if any packets are leaving your machine. Remember that “No route to host” is a local routing problem, so focus on your own network stack first.

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →