# How to test VPS latency with ping, mtr and curl

URL: https://cloudj.net/blog/test-vps-latency-ping-mtr
Published: 2026-11-11 · Updated: 2026-11-11

> Test VPS latency from Windows, macOS and Linux with ping, mtr and curl, read the results correctly, and compare locations before you commit to one.

To test VPS latency properly you need more than one ping from your laptop. You want a fair sample, a view of the route, and a timing of what a real request costs. This guide shows the commands on Windows, macOS and Linux, explains how to read their output without being fooled by common false alarms, and describes a cheap way to compare locations before you commit.

If you have not chosen candidate locations yet, start with [choosing a VPS location by latency](https://cloudj.net/blog/choose-vps-location-latency), and see the [VPS locations guide](https://cloudj.net/blog/vps-locations-guide) for the full list of regions.

## Get a test server in each candidate location

You need an IP address to measure against. Cloudj servers can be billed by the hour, so the simplest approach is to deploy the smallest plan in each location you are considering, run the tests below for a day, then delete the servers you do not keep. An hourly server is charged for as long as it exists, running or stopped, so deleting it is what stops the charges.

Deploy a Linux image such as Ubuntu or Debian, add your SSH key at deploy time (see [how to create SSH keys](https://cloudj.net/blog/ssh-key-vps-setup)), and note each server's public IP. In the commands below, replace `203.0.113.10` with your server's IP.

## Test VPS latency with ping

`ping` sends ICMP echo requests and reports the round-trip time of each reply. Send enough packets to see variation, not just four.

On Linux and macOS:

```bash
ping -c 50 203.0.113.10
```

On Windows (Command Prompt or PowerShell):

```powershell
ping -n 50 203.0.113.10
```

At the end you get a summary. On Linux and macOS it shows `min/avg/max/mdev` (macOS labels the last value `stddev`); Windows shows minimum, maximum and average. Read it like this:

- **Average or median** is your typical round-trip time.
- **The gap between min and max** shows jitter. A stable connection has a small gap; a wide gap means queues are filling somewhere.
- **Packet loss** above zero at the destination deserves a closer look with `mtr`.

Some networks deprioritise or block ICMP. If ping fails completely but SSH works, ICMP is filtered, not the server down.

## See the route with mtr

`mtr` combines traceroute and ping: it sends probes continuously and reports loss and latency for every hop. It is the best single tool for understanding where delay comes from.

Install it on Ubuntu or Debian:

```bash
sudo apt update
sudo apt install mtr-tiny
```

On macOS with Homebrew:

```bash
brew install mtr
```

Run a report with 100 cycles, wide host names and AS numbers:

```bash
sudo mtr -rwz -c 100 203.0.113.10
```

On Linux, `mtr` usually works without `sudo`; on macOS the Homebrew build needs it. If ICMP is filtered along the path, try TCP probes to a port that is open on the server, such as SSH:

```bash
sudo mtr -rwz -c 100 -T -P 22 203.0.113.10
```

Windows does not ship `mtr`. Use the built-in `pathping`, which traces the route and then measures each hop for a few minutes, or `tracert` for a quick path view:

```powershell
pathping 203.0.113.10
tracert 203.0.113.10
```

### Reading mtr without false alarms

The most common mistake is to panic about loss on a middle hop. Routers treat packets addressed to themselves with low priority and often rate-limit ICMP replies. Use these rules:

- **Loss on a middle hop that does not continue to later hops** is rate-limiting on that router. Ignore it.
- **Loss that starts at one hop and continues to every hop after it, including the last**, is real loss on the path.
- **Latency that jumps at one hop and stays high afterwards** shows where the long-distance link is, often an undersea cable or an exchange in another country.
- **Latency that jumps at one hop and drops back later** is again just slow ICMP replies from that router.
- **The last line is what matters most.** It is the server itself.

The AS numbers from `-z` tell you which networks the traffic crosses. If traffic to a nearby city leaves your country and comes back, that explains a surprisingly high number.

## Time a real request with curl

Ping measures the network; your users wait for whole requests. `curl` can break a request into phases. Run it against a web server on the test machine, or any HTTPS site you host there:

```bash
curl -o /dev/null -s -w 'dns:     %{time_namelookup}\nconnect: %{time_connect}\ntls:     %{time_appconnect}\nttfb:    %{time_starttransfer}\ntotal:   %{time_total}\n' https://example.com/
```

On Windows, call `curl.exe` (not the PowerShell alias) and write to `NUL`:

```powershell
curl.exe -o NUL -s -w "connect: %{time_connect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n" https://example.com/
```

Times are in seconds from the start of the request. The difference between `connect` and `dns` is one TCP round trip. TLS usually adds one more round trip with TLS 1.3, or two with older versions. `ttfb` minus `tls` is the server's own processing time plus one more round trip. This shows why distance hurts so much: a single HTTPS request already pays three or more round trips before the first byte arrives.

## Optional: measure throughput with iperf3

Latency and throughput are different. If you move large files, test bandwidth between your machine and the server with `iperf3`. On the server:

```bash
sudo apt install iperf3
iperf3 -s
```

Allow TCP port 5201 in the server firewall for the test, then from your machine:

```bash
iperf3 -c 203.0.113.10 -t 20
iperf3 -c 203.0.113.10 -t 20 -R
```

The `-R` flag reverses the direction so you measure download as well as upload. Stop the server process and close the port afterwards.

## A fair comparison method

Single measurements mislead. To compare locations fairly:

1. Run the same commands against every candidate, from the same client, back to back.
2. Repeat in the morning, in the afternoon and at the evening peak.
3. Test from where users are: a phone on mobile data, a friend in the target country, or an existing server there.
4. Test the reverse path too. Run `mtr` from the VPS toward a user's public IP, because routes are often asymmetric.
5. Record the median, the spread and the destination loss in a small table, then decide.

When the numbers are close, other factors win: included traffic, price on the [pricing page](https://cloudj.net/pricing), and the plan sizes you need. Delete the test servers you do not keep, then work through the [first-hour security checklist](https://cloudj.net/blog/secure-new-vps-checklist) on the one you do.

## FAQ

### What is a good ping to a VPS?

It depends on distance. Compare against the physical floor of roughly 1 ms of round-trip time per 100 km of fiber, and against other candidate locations, rather than a fixed target.

### Why does mtr show 100% loss on one hop but the server responds fine?

That router does not answer probes addressed to it, or rate-limits them. If the following hops and the destination show no loss, the path is fine.

### Why does my ping look fine but the website still feels slow?

Each HTTPS request needs several round trips, and the server's own processing adds time. Use the `curl` timing breakdown to see which phase is slow.

### Should I test from my computer or from the users' region?

Both, but the users' region matters more. A route from your office can be very different from the route your customers' ISPs use.

## Measure, then decide

Deploy small hourly servers in your candidate locations from the [Cloudj console](https://app.cloudj.net), run these tests for a day, and keep the location that serves your users best. Browse all regions on the [cloud servers page](https://cloudj.net/cloud-servers) before you start.