When your server seems to be offline or otherwise inaccessible, you should always be able to log in with the Console at UpCloud Control Panel or through 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 guaranteed to reply provided your internet connection works.

ping -c 4

Your output should show something like

PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=58 time=1.68 ms
64 bytes from icmp_seq=2 ttl=58 time=1.70 ms
64 bytes from icmp_seq=3 ttl=58 time=1.71 ms
64 bytes from icmp_seq=4 ttl=58 time=1.69 ms

--- 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.

Check your network configuration

Make sure the network interfaces such as eth0 are enabled. To see all the configured interfaces, use this command

ip addr

The output of the command will show the status of each network interface on the server with “state UP” or “state DOWN”, as an example

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

Turn on any disabled interfaces with 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 with the information on Network section of the UpCloud Control Panel.

Try restarting any problematic interface with

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>

Check the network configuration file

Linux stores network settings in specific files and reads them for example at boot or when using 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, open the corresponding configuration file with

sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0

The configuration file for eth0 should look like this


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 an effect, you must restart the interfaces to which the changes apply to as described previously with ifdown and ifup –commands.

Check the servers DNS records

When ping with an IP works, but regular connection still fails, try pinging a domain name instead. For example you can ping the UpCloud domain with

ping upcloud.com

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 with

sudo cat /etc/resolv.conf

The list should contain a minimum 1 name server which usually resembles your server’s public IP address.

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 with

sudo nano /etc/resolv.conf

Add the lines shown below to the file, save and exit.


Those with resolvconf installed, in case resolv.conf is still empty after the update command, you can add name servers to your interfaces –file. Open it for edit with

sudo nano /etc/network/interfaces

Add a name server to the end of eth0 section

auto eth0
iface eth0 inet dhcp

Afterwards save the file and exit. You will also need to restart the network service with

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 command

sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0

Edit the file to look like this


Exit the editor and restart the interface which configuration file you just edited using ifdown and ifup –commands.

Test the connection both ways

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 and other 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 ping with 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

In CentOS and other Red Hat –based system

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

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.

Find out where the connection fails

Your internet connecting 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 as 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


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 with

traceroute -4

On CentOS servers use ‘tracepath’ command


Different distributions run different tools and output of these tools also differs slightly. The mtr runs on the foreground until cancelled, updating the response table on each pass, example output shown below.

                                My traceroute  [v0.85]
ubuntu.jr-ux.com (                                   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.                            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.                            0.0%     8    1.3   2.7   1.1  13.0   4.1
 5.                           0.0%     7    1.9   1.8   1.8   1.9   0.0
 6.                           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. Example of traceroute shown underneath has much of the same information as mtr.

traceroute to (, 30 hops max, 60 byte packets
 1 (  0.494 ms  1.010 ms  1.006 ms
 2  te0-0-1-2.rcr11.lon10.atlas.cogentco.com (  0.877 ms  1.415 ms  1.413 ms
 3  te0-7-0-13.ccr22.lon01.atlas.cogentco.com (  1.107 ms  1.643 ms  1.648 ms
 4 (  1.499 ms  1.495 ms  1.492 ms
 5 (  2.096 ms (  2.097 ms (  2.090 ms
 6 (  2.088 ms (  1.717 ms (  1.995 ms
 7  google-public-dns-a.google.com (  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

traceroute -4 <server public IP>

If an outbound trace does not reach even the first node, check your network settings and firewall. Firewall may also be responsible for connection rejections if trace over the internet to your server falls short of just before reaching the server.

Firewall settings

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             ctstate RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp 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 rules that might block your connection.

UpCloud Control Panel also provides easily configurable firewall in your Server settings under 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.

Host status information

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. To contact UpCloud support, please follow the instructions in your UpCloud Control Panel, under My Account and Support –tab.