"No route to host": usually a firewall saying no, sometimes a machine that isn't there

1. A firewall on the other machine

Practice this in the terminal: on the Rocky tab, the server has firewalld as installed, which allows only a few services.

nc -zv -w 5 app01 8080

ssh app01
sudo firewall-cmd --list-all

ports: is empty, and services: lists only ssh, cockpit and dhcpv6-client. So port 8080 is rejected, while SSH works. That’s the telltale sign: some ports work, and others say No route to host. Open the one you need:

sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload
exit
nc -zv -w 5 app01 8080

Now the answer changes to Connection refused, which is progress: the firewall lets you through, and nothing listens on that address. In this scenario, the app only listens on 127.0.0.1. That’s the next step, explained in “Connection timed out” vs “Connection refused”.

Other firewalls. An iptables or nftables rule with REJECT --reject-with icmp-host-prohibited gives the same result. On Ubuntu, ufw drops by default, which gives a timeout instead. Network firewalls and cloud security groups usually drop as well, so they give timeouts.

2. The machine isn’t there

If ping fails too, and the address is on your local network, then nothing answered when your machine asked who has that address:

ip neigh show 192.168.1.50

FAILED or INCOMPLETE means no reply. The machine is off, has another address, or is on a different network segment or VLAN. Check its address from its console, and look for a typo. A virtual machine whose network adapter is disconnected, or on a different virtual switch, does this too.

3. Your own routes

Now the name fits: your machine doesn’t know where to send packets for that address.

ip route get 203.0.113.20
ip route

No default via line means no gateway, so only the local network is reachable. A VPN can add routes that capture traffic, and send it nowhere. Check the subnet mask too: with a wrong mask, a machine believes a remote address is local, and asks for it on the local network, where nothing answers. The Subnet Calculator shows which addresses a mask includes.

4. Docker networks

Docker creates networks such as 172.17.0.0/16 and 172.18.0.0/16. If your company network, or a VPN, uses the same range, then traffic for those addresses goes into Docker instead, and you get this error for real machines. Check:

ip route | grep -E 'docker|br-'

Move Docker to another range in /etc/docker/daemon.json, with default-address-pools, then restart Docker and recreate the networks.

5. Check the firewall on your own side

Your outgoing rules can reject too. On RHEL, sudo firewall-cmd --list-all on the client, and on any machine, sudo nft list ruleset | grep -i reject shows reject rules.