Diagnosing High Ping to a VPS or Dedicated Server

High ping to a VPS or dedicated server can cause delays when connecting via SSH, slow website loading, remote desktop issues, and unstable network application performance.
The cause is not always the server itself. Latency can result from the geographical distance between the user and the data center, network congestion, issues with the Internet service provider, or packet loss along part of the network route.
In this article, we will look at how to check latency to a Linux server, analyze the network route using ping, traceroute, and MTR, and identify where the network problem occurs.

1. What Is Ping and What Is Considered Normal?

Ping is the time it takes for a network packet to travel from the user's device to the server and back. It is measured in milliseconds (ms).
For example, if the ping is 50 ms, it means that the complete round trip takes approximately 50 milliseconds.
Latency depends on several factors:

• The geographical distance between the user and the server.
• The route taken by network packets.
• The quality of the connection between Internet service providers.
• The load on network equipment and communication links.
• Packet loss and retransmissions.
• The current load on network equipment and the server itself.

Approximate ping values:

Ping	Assessment
1–10 ms	Very low latency, typically characteristic of nearby network nodes
10–30 ms	Low latency
30–60 ms	Moderate latency
60–100 ms	High latency for interactive applications, but normal for remote servers located far away
Over 100 ms	May be normal for distant regions, but should be investigated if latency has increased unexpectedly
Over 200 ms	High latency for most interactive tasks, especially if the server is located relatively nearby

These values are approximate. For example, a ping of 100 ms to a server on the other side of the world may be perfectly normal, while 100 ms to a server in a neighboring city may be a reason to investigate the network route.
Important: high ping alone does not prove that a fault exists. You must consider the server's location, the typical latency for that route, and the presence of packet loss.

2. Checking Ping to a Server Using ping

The first step is to measure the latency between your computer and the server.
On Linux, run:
ping -c 20 8.8.8.8Replace 8.8.8.8 with your server's IP address.
The -c 20 parameter specifies that 20 packets should be sent, after which the command terminates automatically.
Example output:

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=2.13 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=2.20 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=2.95 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=2.23 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=3.09 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=117 time=2.58 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=117 time=2.13 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=117 time=2.71 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=117 time=2.54 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=117 time=2.35 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=117 time=2.58 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=117 time=2.84 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=117 time=2.35 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=117 time=3.12 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=117 time=2.38 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=117 time=2.48 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=117 time=2.67 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=117 time=2.54 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=117 time=2.79 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=117 time=2.66 ms

--- 8.8.8.8 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19028ms
rtt min/avg/max/mdev = 2.127/2.565/3.122/0.287 ms

Pay attention to the following metrics:

• min — the minimum response time.
• avg — the average response time.
• max — the maximum response time.
• mdev — the standard (root-mean-square) deviation of delay.
• packet loss — the percentage of lost packets.

In this example, the average ping is approximately 2.565 ms, and there is no packet loss. The difference between the minimum and maximum latency is small, so the connection appears stable.
If latency fluctuates significantly, for example, between 30 and 250 ms, you should investigate the network route and possible network congestion.

How to Check Ping in Windows

Open Command Prompt (CMD) and run:
ping -n 20 8.8.8.8In Windows, the -n parameter specifies the number of requests, whereas Linux uses -c.

What to Do If Ping Fails

If the command reports that all packets were lost, this does not necessarily mean that the server is unreachable. Some networks and servers filter ICMP requests.
Check whether the server is accessible via SSH:
ssh user@IP_ADDRESSYou can also check whether the required TCP port is accessible:
nc -vz IP_ADDRESS 22If SSH works but ping requests receive no responses, the issue may be limited to ICMP filtering.

3. Checking the Network Route Using traceroute

If the ping to the server is high, you need to determine which network nodes the traffic passes through.
The traceroute utility is used for this purpose.
On Debian and Ubuntu, install it:
apt update
apt install tracerouteThen run:
traceroute -q 5 -w 1 8.8.8.8Here:
-q 5 — sends 5 probes to each node.
-w 1 — waits no longer than 1 second for a response.
8.8.8.8 — the destination IP address.
Example output:

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max
  1  148.227.170.1    0.931ms  0.855ms  0.847ms  0.460ms  0.614ms
  2  172.19.254.227    0.249ms  0.380ms  0.337ms  0.288ms  0.658ms
  3  172.19.254.226    0.503ms  0.228ms  0.919ms  0.862ms  1.187ms
  4  109.236.95.105    2.380ms  2.974ms  2.303ms  2.276ms  2.034ms
  5  *  *  *  *  *
  6  74.125.243.81    2.199ms  2.226ms  1.863ms  2.067ms  2.213ms
  7  8.8.8.8          2.275ms  2.332ms  2.150ms  2.422ms  2.492ms

Each line corresponds to a network node along the route to the destination server.
The five time values show the latency of the five probe requests.
If latency increases gradually, this is usually due to additional network hops and the distance between them.
If asterisks appear at one of the nodes:

5  * * * * *

this means that no response was received from that node within the specified timeout for the probes.
This does not necessarily indicate a fault: routers may not respond to diagnostic requests or may limit how many of them they process.
The main rule is to evaluate not only intermediate nodes but also the latency to the destination server. If an intermediate router reports high ping while subsequent nodes and the destination server respond normally, the router is most likely limiting the processing of diagnostic requests.

4. How to Identify the Problematic Network Segment Using MTR

MTR combines the functionality of ping and traceroute. The utility repeatedly checks network nodes along the route and displays latency and packet loss statistics.
It is one of the most convenient tools for diagnosing high ping to a VPS or dedicated server.

Installing MTR

On Debian and Ubuntu:
apt update
apt install mtr

Running Diagnostics

Run the following command:
mtr -o "LSDNABWV" -s 1000 -nrc 1000 8.8.8.8Here:
-o "LSDNABWV" — specifies the order and selection of columns in the report.
-s 1000 — sets the probe packet size to 1000 bytes.
-n — prevents IP addresses from being resolved to domain names.
-r — generates a report instead of running in interactive mode.
-c 1000 — sends 1000 probes to each node along the route.

What the Letters in -o "LSDNABWV" Mean

This option determines which columns appear in the MTR report and in what order.

Letter	Column	Description
L	Loss%	Percentage of packet loss
S	Snt	Number of packets sent
D	Drop	Number of lost packets
N	Last	Response time of the last received packet
A	Avg	Average latency
B	Best	Minimum latency
W	Wrst	Maximum latency
V	StDev	Standard deviation of latency

For diagnostics, it is preferable to run MTR directly from the computer where the problem occurs.
Example output:

HOST: virterion.srv              Loss%  Snt Drop  Last  Avg  Best  Wrst StDev
  1.|-- 148.227.170.1              1.0% 1000    1  1.2  0.7  0.3  1.7  0.3
  2.|-- 172.19.254.227            0.0% 1000    0  0.9  0.7  0.3  1.4  0.3
  3.|-- 172.19.254.222            68.0% 1000  68  0.6  0.7  0.3  1.4  0.3
  4.|-- 109.236.95.107            56.0% 1000  56  2.6  2.4  1.8  3.2  0.3
  5.|-- 72.14.195.126              0.0% 1000    0  3.5  3.6  2.9  5.9  0.4
  6.|-- 72.14.239.107              0.0% 1000    0  2.5  2.7  2.0  3.9  0.3
  7.|-- 172.253.71.199            0.0% 1000    0  2.6  2.7  2.1  3.6  0.3
  8.|-- 8.8.8.8                    0.0% 1000    0  2.2  2.6  2.0  3.4  0.3

The losses observed at nodes 3 and 4 do not persist at subsequent nodes or at the destination server; this indicates that these routers are simply rate-limiting responses to diagnostic packets, while transit traffic remains unaffected.

How to Interpret Packet Loss
Consider another example:

HOST: virterion.srv              Loss%  Snt Drop  Last  Avg  Best  Wrst StDev
  1.|-- 148.227.170.1              0.0% 1000    0  1.2  0.7  0.3  1.7  0.3
  2.|-- 172.19.254.227            0.0% 1000    0  0.9  0.7  0.3  1.4  0.3
  3.|-- 172.19.254.222            15.0% 1000  15  0.8  0.9  0.3  2.4  0.4
  4.|-- 203.0.113.1              16.0% 1000  16  32.1 32.5  31.4  45.5  2.1
  5.|-- 203.0.113.10              16.0% 1000  16  35.1 35.8  33.4  48.5  3.1

In this example, packet loss begins at the third node and continues along subsequent segments up to the destination server.
This indicates a possible problem starting at this point in the route. However, the results must be confirmed by repeating the measurements: some routers limit responses to diagnostic packets, and the packet loss percentage reported by MTR does not always correspond to actual user traffic loss.
If packet loss appears only at a single intermediate node but is absent from subsequent nodes and the destination server, this usually does not indicate a loss of transit traffic.

How to Identify Where Latency Increases

Compare the Avg values across consecutive nodes.
For example:
Node 1: 1 ms.
Node 2: 8 ms.
Node 3: 12 ms.
Node 4: 95 ms.
Destination server: 98 ms.
A sharp increase in latency between the third and fourth nodes may indicate increased transit time along that segment or a change in the route.
However, this does not prove that a specific router or communication link is congested. You need to compare packet loss, repeat the measurements and, if necessary, run MTR in the reverse direction.

5. Checking the Network Route in Both Directions

Network traffic from the user to the server and back may follow different routes.
For example, a request from the user may pass through one transit provider, while the server's response travels through another.
This situation is known as asymmetric routing.
Therefore, for a more complete diagnosis, it is useful to perform two measurements:

1. Run MTR from the user's computer to the server's IP address.
2. Run MTR from the server to the user's public IP address.

On the Linux server, run:
mtr -o "LSDNABWV" -s 1000 -nrc 1000  PUBLIC_USER_IP Replace PUBLIC_USER_IP with the user's public IP address.
If latency or packet loss occurs in only one direction, this can help narrow down the area that needs investigation.
However, reverse MTR does not always fully reproduce the original route: network paths may differ, and ICMP responses may be handled differently from ordinary TCP traffic.
If the user is behind NAT, a VPN, or a corporate firewall, use the address visible to the server rather than the computer's local IP address.

6. How to Distinguish Server Issues from Internet Provider Issues

High ping is not always related to the network route. In some cases, latency may be caused by excessive load on the server itself or its network interface.
First, check whether the problem persists when connecting to the server from different networks.
For example:

• Ping from a home Internet connection is 150 ms.
• Ping from a mobile Internet connection is 35 ms.
• Ping from another server in the same data center is 3 ms.

These results indicate that the problem should be investigated in the user's home network, with their Internet service provider, or along the route from the user to the data center.
If high ping occurs across several independent networks, you should check the network route, the data center's network infrastructure, and the server itself.

Check the Server Load

Connect to the server via SSH and run:
uptimeThe command displays the system uptime and Load Average values.
Next, check resource usage:
topTo analyze memory usage:
free -hTo inspect the network interface:
ip -s linkPay attention to the errors and dropped counters in the ip -s link output. An increase in these values while the problem occurs may indicate issues with the network interface or packet processing.
However, individual dropped values do not necessarily indicate a fault. You need to evaluate how the counters change over time and correlate them with other symptoms.

Check the Server's Connectivity to External Hosts

For example:
ping -c 20 8.8.8.8If the server reaches an external host with low latency and no packet loss, this confirms that the connection in that particular direction is working properly. However, it does not rule out problems along the route between the server and a specific user.
If the problem affects only clients of a particular Internet service provider or users in a specific country, the relevant routing path must be investigated separately.

7. How to Check Whether High Ping Is Caused by Network Congestion

Sometimes latency increases sharply only at certain times of the day. For example, ping may be 35 ms in the morning and 150 ms in the evening.
Possible causes include:

• Congestion in the Internet service provider's network.
• Saturation of a transit link between network operators.
• Congestion on a communication link in a particular direction.
• Packet queueing under heavy network load.
• Problems with the home router or Wi-Fi connection.

To investigate, run MTR during normal operation and again when the problem occurs.
Compare:

• The average ping to the destination server.
• The maximum latency.
• The packet loss percentage.
• The nodes where sustained degradation first appears.
• Changes in the route between measurements.

If the problem occurs regularly, save several reports and include the measurement time and time zone.
To diagnose network congestion, it is also useful to check latency under load. For example, if ping increases sharply only when downloading large files, this may indicate packet queueing on the communication link or network equipment.
Do not conclude that a transit node is congested based solely on a high Wrst value. Individual spikes may be caused by temporary delays in processing diagnostic packets.

8. What to Do If High Ping Occurs Only from a Specific Country

Another common situation is when a VPS is located in Europe, but users in another country report high ping or packet loss.
For example, the server is located in the Netherlands, while users in Russia experience the problem.
In this case, you need to check:

1. The route from the user to the server's IP address.
2. Packet loss at intermediate nodes.
3. Latency to the destination server.
4. Whether users of other Internet service providers experience the same problem.
5. Routing changes at the time the problem occurs.
6. The reverse route from the server to the user.

If ping increases and packet loss occurs in only one direction, this may indicate a routing issue or a connectivity problem between network operators.
However, the fact that a problematic node is located in a particular country does not, by itself, prove that the cause lies in that country or with a specific operator.
It is also important to remember that some intermediate nodes may limit their responses to ICMP requests without affecting ordinary traffic forwarding.
If the server is used for a VPN, you should separately test the connection through the VPN and direct access to the server. The results may differ because of routing, tunneling, and network restrictions.

9. How to Prepare Diagnostic Data for a Technical Support Request

If you cannot identify the cause of high ping yourself, prepare diagnostic data.
To do this:

1. Send 20–100 ping requests to the server's IP address.
2. Run MTR to the same IP address.
3. Repeat the measurements when the problem occurs.
4. Specify the country and Internet service provider used for the connection.
5. Explain when the problem started and whether it occurs continuously.
6. If possible, run reverse MTR from the server to the user's public IP address.

Example MTR command:
mtr -o "LSDNABWV" -s 1000 -nrc 1000 IP_ADDRESSReplace IP_ADDRESS with the IP address of your VPS or dedicated server.
If the problem occurs intermittently, it is useful to attach several reports collected at different times.
Important: diagnostic reports may contain public IP addresses and information about the network route. Before publishing them publicly, consider that this data may reveal details about your network infrastructure.

Conclusion

To identify the cause of high ping to a VPS or dedicated server, running a single ping request is not enough. You need to check packet loss, analyze the network route, and compare the results with the server load.
For initial diagnostics, use the following sequence:

1. ping — measure latency and packet loss.
2. traceroute — inspect the route to the server.
3. mtr — collect statistics for all nodes along the route.
4. ip -s link — check network interface error counters.
5. top and uptime — assess the server load.
6. Reverse MTR — compare the route from the server to the user.

If performance degradation affects only users of a particular Internet service provider or users in a specific region, it is especially important to investigate routing and packet loss along the affected path.
The more data you collect while the problem is actually occurring, the easier it is to identify its source and determine the next steps.