How to test VPS latency with ping, mtr and curl

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, and see the 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), 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:

ping -c 50 203.0.113.10

On Windows (Command Prompt or 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:

sudo apt update
sudo apt install mtr-tiny

On macOS with Homebrew:

brew install mtr

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

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:

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:

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:

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:

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:

sudo apt install iperf3
iperf3 -s

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

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, and the plan sizes you need. Delete the test servers you do not keep, then work through the first-hour security 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, run these tests for a day, and keep the location that serves your users best. Browse all regions on the cloud servers page before you start.