Fix No Route to Host on Linux

curl https://192.168.56.116 dies with Failed to connect … No route to host while ping 192.168.56.116 still gets replies. That combination usually means the kernel found a route to the IP, but something on the path — often a firewall REJECT on the TCP port — answered with ICMP host unreachable.

Work from the client: confirm the route exists, test the exact TCP port, check neighbors on the same subnet, then inspect REJECT rules on the server.

What no route to host means

Linux maps EHOSTUNREACH to the phrase no route to host on connect(). The name sounds like a missing static route, but the errno also covers:

• ICMP host unreachable or host prohibited from a router or firewall
• Neighbor (ARP) resolution failure on a directly connected subnet
• Local policy routing edge cases where the chosen path cannot forward

Use an IP address first so DNS stays out of the picture. If only hostnames fail, see temporary failure in name resolution.

Check the route to the destination

Ask the kernel which interface and source address it would use for the target:

ip route get 192.168.56.116

192.168.56.116 dev eth0 src 192.168.56.156 uid 0
    cache

The dev line is the interface packets leave from; src is the source address peers and firewalls see. If this points at the wrong NIC after a VPN connect, fix local policy routing before changing the remote server.

For destinations outside local subnets, confirm a default gateway exists:

ip route show default

default via 192.168.56.116 dev eth0 proto static metric 100

When ip route get itself answers RTNETLINK answers: Network is unreachable, stop here and fix routing — the no route to host errors on applications are a consequence of that missing path.

Check gateway reachability

If traffic must leave through a gateway, ping the gateway IP from the same client:

ping -c2 -W2 192.168.56.116

PING 192.168.56.116 (192.168.56.116) 56(84) bytes of data.
64 bytes from 192.168.56.116: icmp_seq=1 ttl=64 time=1.36 ms
64 bytes from 192.168.56.116: icmp_seq=2 ttl=64 time=1.18 ms

--- 192.168.56.116 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Replies mean L3 reachability to that IP works. That does not prove every TCP port is open — firewalls filter by protocol and port.

When the gateway does not answer ping, check link state on the client (ip -br link), cable or VLAN membership, and whether the gateway IP is correct for the subnet mask on that interface.

Check ARP and neighbor resolution

On the same broadcast domain, the kernel must resolve the destination MAC address before TCP can flow. Inspect the neighbor cache:

ip neigh show 192.168.56.116

Healthy entry:

192.168.56.116 dev eth0 lladdr 08:00:27:c4:4f:20 REACHABLE

REACHABLE means ARP succeeded recently. FAILED or INCOMPLETE on a host that should be up points at L2 problems — wrong VLAN, host powered off, duplicate IP, or a switch port issue — and can produce unreachable errors even when ip route get looks fine.

Clear a stale entry only when you suspect a bad MAC was cached, then retry:

sudo ip neigh del 192.168.56.116 dev eth0

The next packet triggers a fresh ARP request.

Trace where connectivity stops

On a one-hop LAN, tracepath confirms the target responds at L3:

tracepath -n 192.168.56.116

1:  192.168.56.116                                        0.111ms reached
     Resume: pmtu 65535 hops 1 back 1

reached on the first hop matches a directly connected host. For multi-hop paths, use traceroute or mtr to see which router returns ICMP unreachable.

TCP failures need a port-level test. Bash can open a socket without extra packages:

timeout 3 bash -c '</dev/tcp/192.168.56.116/443' && echo open || echo failed

When a server firewall REJECTs the client with icmp-host-prohibited, the shell prints:

bash: connect: No route to host
bash: line 1: /dev/tcp/192.168.56.116/443: No route to host
failed

The same target with curl command shows the errno in the verbose log:

curl -v --max-time 3 http://192.168.56.116:443

* connect to 192.168.56.116 port 443 from 192.168.56.156 port 45228 failed: No route to host
* Failed to connect to 192.168.56.116 port 443 after 2 ms: Could not connect to server
curl: (7) Failed to connect to 192.168.56.116 port 443 after 2 ms: Could not connect to server

Note the client source port line — firewall rules often match source IP, not only destination.

Check firewall REJECT rules

On RHEL-family systems, firewalld can REJECT blocked TCP with ICMP unreachable responses. The client then reports no route to host even though ping and ip route get succeed.

On the server, list the active zone:

sudo firewall-cmd --list-all

Look under services, ports, and rich rules for what is allowed. Rich rules that REJECT a client source are easy to miss:

rich rules:
	rule family="ipv4" source address="192.168.56.156" port port="443" protocol="tcp" reject type="icmp-host-prohibited"

That pattern blocks HTTPS from one client IP while SSH from the same host may still work on port 22.

Allow the service permanently on the server zone:

sudo firewall-cmd --permanent --add-service=https

Reload firewalld so the rule is active:

sudo firewall-cmd --reload

Or remove a mistaken REJECT rule:

sudo firewall-cmd --permanent --remove-rich-rule='rule family="ipv4" source address="192.168.56.156" port port="443" protocol="tcp" reject type="icmp-host-prohibited"'

Apply the removal:

sudo firewall-cmd --reload

On any distro, search nftables or iptables for REJECT targets:

sudo nft list ruleset | grep -i reject

reject-with icmp host-prohibited and icmp-host-unreachable commonly map to no route to host on the client. DROP rules tend to cause timeouts instead.

Ports not allowed in the zone may be rejected before traffic reaches the application. Opening the port in the firewall is not the same as running a service — compare with connection refused below.

Verify the fix

Re-run the same TCP check that failed:

timeout 3 bash -c '</dev/tcp/192.168.56.116/443' && echo open || echo failed

After the REJECT rule was removed and HTTPS allowed, the socket opens when a listener is present, or fails with connection refused when the port is open at the firewall but nothing listens.

Confirm neighbors and routing are still healthy:

ip neigh show 192.168.56.116

192.168.56.116 dev eth0 lladdr 08:00:27:c4:4f:20 REACHABLE

The routing decision should still name the same outbound interface:

ip route get 192.168.56.116

192.168.56.116 dev eth0 src 192.168.56.156 uid 0
    cache

For SSH-specific verification (sshd, ListenAddress, keys), continue with Fix SSH no route to host once TCP port 22 connects.

No route to host vs connection refused

Both errors appear before application data flows, but the fix differs:

Demonstration on the same server IP: with the firewall allowing port 59999 but no process listening, the client sees refused:

timeout 3 bash -c '</dev/tcp/192.168.56.116/59999' 2>&1

bash: connect: Connection refused
bash: line 1: /dev/tcp/192.168.56.116/59999: Connection refused

With the port blocked by REJECT instead, the same client IP gets no route to host on port 443 — fix the firewall rule, not the application daemon.

Troubleshooting

References

• ip-route(8) — routing table and ip route get
• ip-neighbour(8) — ARP and neighbor cache
• firewalld.richlanguage(5) — REJECT types including icmp-host-prohibited
• errno(3) — EHOSTUNREACH and ECONNREFUSED
• RFC 792 — ICMP — destination unreachable messages

Summary

No route to host is an EHOSTUNREACH error at the socket layer. It does not always mean your routing table is empty — on many Linux servers the message appears when a firewall REJECTs TCP with ICMP host prohibited while ICMP echo still passes.

Start with ip route get and a port-specific test (bash /dev/tcp, nc, or curl -v). If the route looks correct and ping works, read ip neigh for ARP problems, then inspect firewalld rich rules or nftables REJECT entries that match your client source IP and destination port.

Connection refused on the same IP means the packet reached the host and nothing accepted the socket — open the service or fix the listener. Network is unreachable means the kernel never found a route — fix gateways first. Once TCP connects for SSH, hand off to Fix SSH no route to host for sshd and authentication checks.