How to Fix “No Route to Host” Connection Error on Linux
When you’re trying to connect to a service on Linux, “No route to host” is one of the last things you want to hear. It’s a broad message that means your computer can’t reach the target server, whether a local server daemon running on your system or a remote server that you can’t access for whatever reason. Here we show you how to fix the “no route to host” connection error in Linux.
Why Am I Getting the “No Route to Host” error?
There are many reasons why you could be getting that error. Networking in Linux is a somewhat complicated stack that’s pretty intricate, and as a result, it’s tough to determine exactly where the issue is.
Host Is Offline/Service Isn’t Running
It may seem painfully obvious, but you should first check that the server that you’re trying to connect to is even online. It might have been taken down for maintenance or be experiencing issues.
The service itself might not have been started. If it’s your server, you can check to see if the service has been started and is running properly. To do that with Systemd, run the following command.
You may be trying to connect on the incorrect port. Many system administrators choose to run commonly targeted services like SSH on different ports to help thwart would-be attackers.
If the server isn’t your own, check the available documentation or contact their support services.
For your own server, you can try using NMAP to figure out where you started your service.
If you think you used a really obscure port, you can use the -p- flag to scan them all. It will take a while though.
Iptables Is Blocking the Connection
You may have accidentally configured iptables to block connections on that port. You would receive the same message whether you configured iptables on the server or your desktop, so it’s worth checking both. To see your iptables rules, run the following command.
Your DNS Is Improperly Configured
If all else fails, you should try to ping the IP address that you’re looking to connect to. It could be that your computer isn’t connecting to a DNS server properly.
If the ping works but connecting a domain name doesn’t, you’re looking at a DNS issue.
Systemd users can run systemd-resolve —status to check the DNS servers that your system is using. It’s broken down by interface, so make sure to check the one that you’re actually trying to connect through.
In most cases your computer will discover the relevant DNS information over DHCP. If you’re using a static IP or something on your network is configured differently, you may have to set your DNS manually.
Open “/etc/systemd/resolved.conf.” In that file, uncomment the DNS line and add either the IP of your router or another known DNS server. The default fallback DNS for Systemd is Google’s DNS servers listed under FallbackDNS .
If you’re using OpenRC or another Systemd alternative, you can find your DNS information in “/etc/resolv.conf.”
If there’s nothing there, enter the IP address of your router or any other known DNS server that you’d prefer to use.
After, either restart networking or your entire computer.
The GUI Way
If you’re using a graphical desktop with Network Manager, you can edit your connection information that way. Open the applet or go through your system settings. Select your connection and find the “IPv4” tab. Switch the connection to “Manual” and manually enter in the IP address of your computer and the IP of your router as the gateway. Then, in the DNS field below, enter your router’s IP or the IP of another DNS server.
Incorrect Network or Host Configuration
There are several other configuration options that may be incorrect. Any of them would make it impossible for your computer to connect to the server.
First, make sure that your computer’s network configuration is correct. Double-check the configuration files themselves and, of course, see if you can connect to the Internet another way.
If you’re using a specific hostname to connect or you’ve set up specific hosts on either the server or the client, you need to make sure both machines can connect to each other. Check the configurations of “/etc/hosts,” “/etc/hosts.allow,” and “/etc/hosts.deny.”
Finally, check your server configuration. Something may be improperly configured on the server, preventing clients from connecting properly.
Hopefully, using these tips has allowed you to fix whatever issues were happening that caused the “No Route to Host” error. Meanwhile, you can learn how to control your Wi-Fi network in Linux or check if your firewall is blocking any incoming and outgoing connection.
John is a young technical professional with a passion for educating users on the best ways to use their technology. He holds technical certifications covering topics ranging from computer hardware to cybersecurity to Linux system administration.
Our latest tutorials delivered straight to your inbox
Error no route to host connection
This issue happens when a network request is attempted to a remote host, and an error is thrown containing the phrase No route to host , or the error code EHOSTUNREACH .
Check RunBook Match
This runbook is limited to Linux hosts, although some steps may help trigger productive investigations on other OSes.
Initial Steps Overview
1) Gather information
1.1) Determine the host
Determine the host (or IP) you are trying to reach.
From here, this host will be referred to as [HOST|IP] .
1.2) Determine the IP
Once you have the hostname, then you can determine the IP address by running:
which outputs, eg:
You can take the first address returned as the IP to use, eg for the above output, 22.214.171.124 would be the IP.
If you can find out the ‘correct’ IP that you are trying to reach by some means independent from your machine, do so. This might involve contacting another user, or figuring out the IP address by introspecting on the host.
1.3) Determine the port
Determine the port you are trying to reach.
If this is a ‘standard’ web request, then the port is either 80 (for http requests) or 443 (for https requests).
If the web request hits a non-standard port, then you will see :[NUMBER] in the URL, eg:
would mean you are trying to contact port 8443 .
This will be referred to subsequently as [PORT] .
1.4) Determine the frequency of the problem
Try and work out if the problem happens every time, or is intermittent.
If it’s intermittent, consider whether there are multiple hosts that could be ultimately reached by the request (eg behind a load balancer), and whether one of these hosts is faulty.
2) Is host up?
Check whether the host you are trying to reach is up.
2.1) Use nmap
If you see output that begins like this:
then you have nmap installed. If you don’t then you will need to install it. Wait for the command to return.
If you see a message in output like:
then this is a DNS lookup failure. See the DNS Lookup Failure runbook.
If you see output that mentions Host is up , like this:
then the host you are trying to contact is up.
2.2) Use ping
If you can not install nmap , then you can try to ping the host:
2.3) Use nmap on the IP
If you are certain of the IP you are trying to connect to, you can try using nmap to access that host directly as per step 2.1. If the output differs from that of step 2.1, then you may have an issue with DNS lookup for the host not returning the correct IP address.
If you do, then this is likely due to a DNS server local to your network being misconfigured. Correcting this is outside the scope of this runbook, and will likely require you to contact the person responsible for that DNS server.
3) Is the port open?
There are two ways of determining this — from the client host and from the remote host.
3.1) From client
Run this command, and check the output:
If the command hangs with output like:
then you can only say that the connection is not being explicitly rejected by the remote host. Where the connection is being stopped/dropped is impossible to say. It could be:
by a local firewall
by an intervening host/firewall
by the remote host’s firewall
If the request returns with a message like:
then the request reached a remote host, and was explicitly refused.
If you connect, with a response like this:
Then the issue appears to be resolved. If your application is still having the same problem, then check the IP address it is trying to reach matches the IP address above.
3.2) From remote host
There are several ways to determine whether a given port is open on your host.
If the output looks like this:
then the port is open on all network interfaces (that’s what 0.0.0.0 means). If you see another set of numbers in place of the 0.0.0.0:[PORT] , then . Similarly, if you see something else in place of the 0.0.0.0:* (the ‘Foreign Address’), then the port may not be accessible only to clients from specific IP addresses. For example, if you see 127.0.0.1:* then it is only accessible from the localhost (using any port).
Which produces similar output:
You can try connecting direct to the port using telnet, as per step 3.1. However be aware that this just proves that you can connect from the same host (see notes on interfaces in this section above).
the port appears to be open from the point of view of the remote host
the port appears to be closed from the point of view of the client
this suggests that there is an intervening firewall that is blocking requests from reaching the server.
The firewall may be on the remote host.
4) Check IPTables / NetFilter
First, if you want to (optionally) know whether you are using IPTables or NetFilter, go here.
To determine your IPTables/NetFilter rules and whether they affect your port or host, run as root:
If any lines match, then IPTables may be blocking or redirecting your attempts to connect to the remote server.
Understanding IPTables more deeply to fully debug this is outside the scope of this article. There are many resources on the web that attempt to explain it for various levels of experience.
5) Check routing tables
At this point, you may want to consider whether your routing tables are misconfigured.
This command gives a list of your machine’s routes:
If the ip command is unavailable, try route :
Determining whether the routing tables are correctly configured requires more network knowledge than can be reasonably placed here, and likely some knowledge of the local network topology.
There are many good resources on the internet for this, see Further Information below for links.
6) Check intervening firewalls
At this point you’ve checked connectivity at your client machine and the server. Now it is worth considering whether there is an intervening firewall between client and server blocking the connection.
- Local firewall (ie on way out)
We have already considered IPTables/NetFilter, but it is possible that there is some other kind of firewall running on your host that is preventing egress.
- If you are using AWS, or any other cloud provider…
then consider whether there are network rules set up to prevent egress. On AWS these come in the form of ‘Security Groups’ and ‘Network ACLs’.
- External/3rd party firewall
Any number of firewalls/hosts may be relaying your request to the destination host. Any of these may be blocking the request from going further.
Using traceroute might be considered at this point to determine which (and how many) hosts are being hit may help you debug further. See here for more background on this tool.
If the application no longer reports this error, then this issue is resolved.
This error originates from the Linux kernel, eg in:
It can be thrown within the kernel for a number of different reasons, which makes interpreting the error tricky.
How to Fix “No route to host” SSH Error in Linux
SSH is the most secure means of connecting to Linux servers remotely. And one of the common errors encountered while using SSH is the “ssh: connect to host port 22: No route to host”. In this short article, we will show how to troubleshoot and fix this error.
Here is a screenshot of the error we are talking about. Note that the port may not necessarily be port 22, depending on your configurations on the remote host. As a security measure, system administrators can configure SSH to be accessed via a different port.
SSH No Route to Host Error
There are different reasons why this error appears. The first is normally that the remote server could be down, so you need to check whether it is up and running using the ping command.
Ping Linux Server
From the ping command results, the server is up and running, that’s why it is accepting the pings. In this case, the reason for the error is something else.
If you have a firewall service running on your remote server, it is possible that the firewall is blocking access via port 22.
Therefore you need to access the server console physically or if it is a VPS, you can use any other means such as VNC (that’s if it is already setup) or other custom remote server access applications provided by your VPS service provider. Login, and access a command prompt.
Then use the firewall-cmd (RHEL/CentOS/Fedora) or UFW (Debian/Ubuntu) to open port 22 (or the port you configured to be used for SSH) in the firewall as follows.
Now try to re-connect to the remote server once more via SSH.
SSH Login Successful
That’s it for now! You will also find the following SSH guides useful:
Remember, you can share your thoughts with us or ask any questions concerning this topic via the comment form below.
If You Appreciate What We Do Here On TecMint, You Should Consider:
TecMint is the fastest growing and most trusted community site for any kind of Linux Articles, Guides and Books on the web. Millions of people visit TecMint! to search or browse the thousands of published articles available FREELY to all.
If you like what you are reading, please consider buying us a coffee ( or 2 ) as a token of appreciation.
We are thankful for your never ending support.