Why did my ping go up? Diagnosing path, congestion and game server latency

If a ping that was 25 ms yesterday is 90 ms today, the cause is not distance — the distance did not change. What changed is either the path, the congestion on that path, or the load on the server itself. These three are solved in different places, and you can tell which one you are in within ten minutes.

Choosing a location before you buy and measuring the expected figures is a separate subject, covered in full in server location and ping. The question here is different: why did the ping degrade on a server that was already running?

First, separate: whose ping went up?

That single question is half the diagnosis.

• If it went up for one player, the problem is most likely in their own connection. Mobile data, a long copper line or home Wi-Fi add 20-40 ms on the player's side, and there is no way to fix that from the server.
• If it went up for players on one ISP, the problem is on the path between that operator and the server.
• If it went up for everyone, it is on the server or on the server's network connection.

This is why you should not measure from a single connection. Measurements from at least two different operators separate one line's own problem from the average.

1. Start inside the server — that is the cheapest check

A loaded server delays its packet responses; the ping rises even when the network is flawless. Look at the machine itself first:

uptime
top

If the CPU is pinned, if the load average is clearly above the core count, or if wa is high, the diagnosis ends here and the subject is not the network: why did my server slow down

The rule of separation is this: if `mtr` shows low latency at the final hop while the in-game ping is high, the problem is not in the network but in the server or the application. If the network carries the packet in 20 ms, the remaining 70 ms is processing time.

2. Measure the path, and read it correctly

mtr -r -c 100 185.137.98.29

Misread mtr output sends people to the wrong place very easily. Three rules:

• Loss% at an intermediate hop is usually that device rate-limiting its ICMP replies, not real loss. What matters is the loss on the final line.
• If latency rises at one hop and stays high on the following hops, the increase is real; from that point on the path is longer or congested.
• If latency spikes at one hop and drops again immediately after, that device simply deprioritises ICMP addressed to itself; it is not a problem.

Look at the hop names too. If a path that should stay domestic passes through the name of a foreign city, the traffic is taking a detour and the difference reaches 40-50 ms.

3. Measure the right protocol

Many networks process ICMP at low priority, so the ping figure may not represent your game's real traffic. Measuring the game port itself is more accurate:

mtr -u -P 30120 185.137.98.29
nc -vz 185.137.98.29 27015

The first measures the path over UDP; the second quickly tells you whether a TCP port is reachable from outside. Per-game ports and resource guidance are listed on the game server plans.

4. Watch the hour and the direction

When the measurement is taken changes the result. A path that is 30 ms during the day can be 60 ms between 21:00 and 24:00; that is the signature of congestion, and a single daytime measurement never shows it.

The second detail is directional asymmetry: outbound and return packets do not have to follow the same path. An mtr taken from the player to the server can look clean while the measurement from the server back to the player is broken. The single most useful thing in a support ticket is having measured both directions.

5. Look at the jitter, not the average

Players notice spikes, not averages. A steady 45 ms is better than a connection bouncing between 20 and 80. On Linux the mdev value on the last line of ping output is a rough measure of that variation; under 5 ms is good, over 20 ms is the range that generates complaints. Sustained packet loss above 1% is more disruptive in an FPS than a high average. The same thing is decisive for voice traffic; on TeamSpeak hosting variation breaks speech up directly.

6. A sudden, unexplained spike can be an attack

If the inbound traffic volume rose vertically alongside the ping and no game event explains it, there is one more possibility to rule out: am I under a DDoS attack

When to open a support ticket

If any of these three findings is present, there is nothing left to do inside the server:

• In the mtr output the hop where latency rises is inside the provider's network, and the increase persists on the following hops.
• Measurements from several operators show the same spike.
• The in-server measurements (uptime, top) are completely clean but the in-game ping is high.

Attach the two-directional mtr output, the time the measurement was taken, the player's operator and the game port. A routing problem is something that can be fixed on the network side; a distance problem is not. If your server is simply in the wrong location the answer is different: on virtual server plans the location is chosen at order time, and a domestic location is a direct gain of 20-40 ms over an overseas provider.