Experience ease of use - Sign up for a free trial
When your Linux server seems to be offline or otherwise inaccessible, you should always be able to log in with the web console at your UpCloud control panel or through a VNC connection. Once logged in, test your server’s internet connection using ping and a public IP address such as Google’s public DNS server, which is most likely to reply provided your internet connection works.
ping -c 4 220.127.116.11
Your output should show something like
PING 18.104.22.168 (22.214.171.124) 56(84) bytes of data. 64 bytes from 126.96.36.199: icmp_seq=1 ttl=58 time=1.68 ms 64 bytes from 188.8.131.52: icmp_seq=2 ttl=58 time=1.70 ms 64 bytes from 184.108.40.206: icmp_seq=3 ttl=58 time=1.71 ms 64 bytes from 220.127.116.11: icmp_seq=4 ttl=58 time=1.69 ms --- 18.104.22.168 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 1.686/1.699/1.718/0.051 ms
If the server is unable to reach the destination, there may be a problem with your configuration. Follow the steps described here in order to troubleshoot the most common network issues with Linux Cloud Servers.
Make sure the network interfaces such as eth0 are enabled. To see all the configured interfaces, use this command.
The output of the command will show the status of each network interface on the server with “state UP” or “state DOWN”, for example as below.
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
Turn on any disabled interfaces with the next command.
sudo ifup <interface name>
Here the interface name is one of the names listed in the ip addr command output like eth0, eth1 or eth2.
When all network interfaces have been enabled, try using the ping command again. If the problem persists, check that the network interfaces have IPs assigned to them, and they match the information in Network section of the UpCloud control panel.
Try restarting any problematic interface with the following commands.
sudo ifdown <interface name> sudo ifup <interface name>
If either of these commands fails, it is possible that the interface is in a state unknown to the command script. Try the same commands again with --force parameter to resolve any such issues.
sudo ifdown --force <interface name> sudo ifup <interface name>
If restarting the network interface fixed the issue, great! If not, continue with the troubleshooting.
Linux commonly stores network settings in specific files and reads them for example at boot or when using the ifup command. To make changes to the network configuration, you’ll need to open the right file in a text editor. In Debian and Ubuntu-based distributions this can be done with
sudo nano /etc/network/interfaces
In most cases, the interfaces file should list at least the following interfaces.
auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp auto eth1 iface eth1 inet dhcp
In CentOS and other Red Hat variants, these configurations are split into separate files for each network interface and stored in /etc/sysconfig/network-scripts/. The default interface for internet connection is usually called eth0, opens the corresponding configuration file.
sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
The configuration file for eth0 should look like this.
DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes
If the interfaces configuration files do not match the example here, edit the file specific to your system to restore the original functionality. For any changes made to these files to take effect, you must restart the interfaces to which the changes apply as described previously with ifdown and ifup commands.
When ping with an IP works, but the regular connection still fails, try pinging a domain name instead. For example, you can ping the UpCloud domain with like so.
If the domain does not reply, the problem is most likely with the way your server resolves domain names to IP addresses. Check your server’s DNS records.
sudo cat /etc/resolv.conf
The list should contain a minimum of 1 name server. All default DNS resolvers at UpCloud have the same IP addresses regardless of the availability zone. The DNS servers are provided automatically by the DHCP protocol and there should be no need for manual configurations in the operating system.
The UpCloud DNS resolver IPv4 addresses are:
If your server has a public IPv6 address, you can also use IPv6 with the following servers:
If the list is empty do not edit it manually, because if you have a nameserver manager installed any changes you make will just get reverted. Instead, on Ubuntu and some Debian systems, you can try to update it with this command.
sudo resolvconf -u
On Debian servers, which do not have resolvconf installed, you can edit the resolv.conf file directly.
sudo nano /etc/resolv.conf
Add the lines shown below to the file, save and exit.
nameserver 22.214.171.124 nameserver 126.96.36.199
For those with resolvconf installed, in case resolv.conf is still empty after the update command, you can add nameservers to your interfaces file. Open it for editing.
sudo nano /etc/network/interfaces
Add a name server to the end of the eth0 section.
auto eth0 iface eth0 inet dhcp dns-nameservers 188.8.131.52
Afterwards, save the file and exit. You will also need to restart the network service with the following command.
sudo service networking restart
In CentOS and other Red Hat variants the resolv.conf file is populated a little differently, if the file is empty, you can add up to two DNS entries in your network configuration file for the network interface responsible for the public IP. For example, open ifcfg-eth0 it with the next command.
sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
Edit the file to look like this.
DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes DNS1=184.108.40.206 DNS2=220.127.116.11
Exit the editor and restart the interface which the configuration file you just edited using ifdown and ifup commands.
Try pinging your server over the internet. Open a terminal or command prompt on your own computer and try pinging your server’s public IP, which you can find in the UpCloud control panel under the Network section.
On your own computer: ping <server public IP>
Test the internet connection by pinging another site from your server, for example, use the following command to ping Google’s public DNS.
If you have a second server deployed on your account and the problem is with the interface assigned with the private IP address, try to ping your other server, to and from it, using the private IPs listed in the UpCloud control panel.
Should ping fail to receive a reply, try restarting all of your server’s network services. In Debian and Ubuntu 12.04 or older, use the command below.
sudo service networking restart
On CentOS and other Red Hat-based systems, restart the network with the command underneath instead.
sudo service network restart
In Ubuntu 14.04 and newer you’ll need to run the command for each network interface separately, for example, you can restart eth0 simply with the following.
sudo ifdown eth0 && sudo ifup eth0
After restarting the network services, try running ping again both ways. If ping works in one direction but not in the other, check your firewall settings.
Your internet connection in its basic form boils down to knowing the route to take to your destination. It is sometimes possible for the connection routing to hit a dead end, which then results in a failed connection. Run a route trace from your server to see at which network node the connection gets lost.
Ubuntu servers have a networking tool called mtr for this purpose, start it with the following command.
And to quit just press q on your keyboard.
To do this on Debian systems where mtr is usually not installed by default, you can use traceroute instead.
traceroute -4 18.104.22.168
On CentOS servers use tracepath command.
Different distributions run different tools and the output of these tools also differs slightly. The mtr runs in the foreground until cancelled, updating the response table on each pass, example output is shown below.
My traceroute [v0.85] ubuntu.jr-ux.com (0.0.0.0) Wed Jul 29 16:03:43 2015 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 22.214.171.124 0.0% 8 0.5 0.4 0.4 0.5 0.0 2. te0-0-1-2.rcr11.lon10.atlas.cogentco.c 0.0% 8 0.8 0.8 0.7 1.1 0.0 3. te0-7-0-13.ccr22.lon01.atlas.cogentco. 0.0% 8 1.2 1.2 1.1 1.3 0.0 4. 126.96.36.199 0.0% 8 1.3 2.7 1.1 13.0 4.1 5. 188.8.131.52 0.0% 7 1.9 1.8 1.8 1.9 0.0 6. 184.108.40.206 0.0% 7 1.8 1.9 1.8 2.0 0.0 7. google-public-dns-a.google.com 0.0% 7 2.0 2.1 1.9 2.3 0.0
Traceroute and tracepath are very similar to one another, they run pass over the network to the given destination and show the latency to each node that replied. The example of the traceroute shown underneath has much of the same information as mtr.
traceroute to 220.127.116.11 (18.104.22.168), 30 hops max, 60 byte packets 1 22.214.171.124 (126.96.36.199) 0.494 ms 1.010 ms 1.006 ms 2 te0-0-1-2.rcr11.lon10.atlas.cogentco.com (188.8.131.52) 0.877 ms 1.415 ms 1.413 ms 3 te0-7-0-13.ccr22.lon01.atlas.cogentco.com (184.108.40.206) 1.107 ms 1.643 ms 1.648 ms 4 220.127.116.11 (18.104.22.168) 1.499 ms 1.495 ms 1.492 ms 5 22.214.171.124 (126.96.36.199) 2.096 ms 188.8.131.52 (184.108.40.206) 2.097 ms 220.127.116.11 (18.104.22.168) 2.090 ms 6 22.214.171.124 (126.96.36.199) 2.088 ms 188.8.131.52 (184.108.40.206) 1.717 ms 220.127.116.11 (18.104.22.168) 1.995 ms 7 google-public-dns-a.google.com (22.214.171.124) 1.733 ms 2.250 ms 1.721 ms
Try the same from your own computer to the server using one of the tools mentioned above, for example, using the command below.
traceroute -4 <server public IP>
If an outbound trace does not reach even the first node, check your network settings and firewall. The firewall may also be responsible for connection rejections if the trace over the internet to your server falls short just before reaching the server.
Check that your connection is not getting blocked by a firewall. CentOS and some other Red Hat-based distributions have strict firewall rules by default. The following command will list all server-side firewall rules on your system.
sudo iptables -L
Iptables is the Linux built-in software firewall, and the command above prints out the following.
Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere the RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere The firewall dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:ssh DROP all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
This is an example of a simple firewall table. It has rules to allow SSH and HTTP traffic, but block all other input, which also blocks ping attempts. Check your server’s iptable for any is shown that might block your connection.
Your UpCloud control panel also provides an easily configurable firewall in your server settings under the Firewall tab.
The example image above has a few accepted incoming rules, but the default rule is set to reject. Make sure there are no rules blocking your desired connection.
Check the most up-to-date information on UpCloud infrastructure at status.upcloud.com, where you can also subscribe to updates by email, SMS, and Atom or RSS feeds.
If everything seems to be in order, but the network connection still just doesn’t work, or you are otherwise unable to troubleshoot the connection issues, don’t hesitate to ask for help.
Very good !
ipaddr says wlan0 is DOWN so is enp6s0. lo is UNKNOWN
suso ifup wlan0 returns Unknown interface wlan0
mtr 126.96.36.199 returns mtr: udp socket connect failed: Network is unreachable
Hi Bill, try enabling your wlan0 with ip link set dev wlan0 up If that doesn’t work, check your network configuration for any errors. Alternatively, try to get a wired connection working and update your network device drivers.
Your article gives an overall view of all the procedure of the How to troubleshoot network connectivity with Linux server in a very basic that can be understood by anyone.
Nice informative article.
The ping is a successful and the server is successful as well. I do not understand why it still said “could not connect to …” and is “connection refused.” Is there something I missed during the troubleshoot?
Hi Clo, thanks for the question. By the sound of the error message, I’m assuming you are attempting to reach a webserver on the browser. If you can ping the server, it has connectivity but is not necessarily able to replying to web requests. This could be because of a firewall or the webserver is not configured correctly. In the latter case, have a look at our troubleshooting guide for Apache2 at https://upcloud.com/community/
These commands are great for troubleshooting obvious physical issues, but what about more insidious issues? Interfaces can negotiate at the incorrect speed, or collisions and physical layer problems can cause packet loss or corruption that results in costly retransmissions. How do we start troubleshooting those issues?
Hi there, thanks for the comment. While important questions for self-hosted Linux systems, in the cloud such issues would be the responsibility of the infrastructure provider and I’d recommend contacting support.
Hello, I’m a total begginer to all of this stuff but I set up a server a few months ago to host minecraft for some friends. I recently got a new router with a better internet connection, however the server can no longer connect to the internet. When I tried to ping the google server it said network is unreachable, and when I did sudo ip addr none of he 3 results were eth0, eht1, eth2 or anything like that. I’m not really sure what the problem is since before getting a new router it worked fine. If you could offer any advice that would be much appriciated, thank you.
Hi Fynn, it’s likely that your Minecraft server has a static IP address that is in a different range to your new router. The ip addr will list all of your network interfaces but they can be named something other than eth*, for example, ens* or eno*. You will need to figure out which of the interfaces connects to your local network and check that it has an IP address.
Ultimate article . Please do share more trouble shooting steps to make us understand the actual solution of different problem.
I have linux 7 and other end ATM machine some time Linux connection stuck with ATM
and after change ATM IP my Linux server again connection established with ATM.
When the issue start with my Linux server at same time other Linux server can ping on same IPs of ATM. Can any one have idea whats going on with Linux machine that is VM. Also Selinux are enforcing on both Linux servers.
Hi Rehan, thanks for the comment. The issue could be with routing. Next time the connection drops, try running a traceroute between the two machines to see if that’ll give any indication as to what’s causing the problem.
Great article got me up and running, but after a reboot I have to do the ifdown/ifup dance again. How do I make it stick?
Hey there! First, you need to make sure in the network configurations that the interface is configured to be automatically started and possibly configured upon boot up. After you have done this and the interface is still not automatically started, check the server logs, especially DHCP client logs, for further information.
Have you checked whether port 22 is being blocked or the possibility that ssh is configured to use a different port other than 22
perfect , thank you for sharing