How to Benchmark VPN Latency Fairly

A VPN adds a detour. Your packets travel to a VPN server first, are decrypted there, and then continue to the real destination. Anyone who plays online games, joins video calls or simply likes a snappy browser wants to know how much that detour costs in milliseconds. The honest answer is "it depends", and the only way to find your own answer is to measure it. The trouble is that most home-made tests are unfair: a handful of pings, taken once, at one time of day, compared with a number from a different network.

This article gives you a repeatable VPN latency benchmark that a student, a remote worker or a gamer can run in under an hour with tools already on the computer. It focuses only on delay. For the idea of what latency is, read VPN latency explained; for the question of whether a VPN can ever help, see does a VPN reduce ping. Here we concentrate on method.

Define what you are actually measuring

Latency is the time a small packet needs to travel to a destination and back, called the round-trip time (RTT). It is not speed. A connection can have a huge download rate and still feel sluggish when every request waits 200 ms. Cloudflare's learning page on latency explains the basic idea clearly.

When a VPN is on, there are three separate numbers you could measure, and mixing them up is the first source of bad results.

What you measure	Meaning	When it is useful
RTT to the destination, VPN off	Your normal path	The baseline for everything else
RTT to the destination, VPN on	Path through the VPN server	The number you really feel
RTT to the VPN server address only	First leg of the detour	Diagnosing which part is slow

The difference between the first two lines is the VPN overhead. That is the figure worth reporting. The third line helps you explain it: if the first leg is already 150 ms, no setting inside the tunnel can fix it.

Write your goal in one sentence before you start. For example: "I want to know how much delay my VPN adds when I join a video call to a colleague, using my home cable broadband in the evening." A sentence like that decides the destination, the network and the time of day for you.

Set up a fair test bench

A benchmark is only fair if the only thing that changes between two runs is the thing you are testing. Prepare the following.

1. One device. Use the same laptop or phone for every run. Close cloud-sync clients, system updates, torrent apps and streaming tabs, because they fill your uplink and inflate latency.
2. One network, preferably wired. Wi-Fi adds random delay from interference and signal changes. A cable removes that variable. Later you can repeat on Wi-Fi, but never mix results from different networks in the same comparison.
3. One VPN server per test. Pick the server you would normally choose and write down its location label. If you want to compare two locations, run them as separate tests.
4. Stable settings. Keep the VPN app's defaults. Do not switch the connection type halfway through unless switching is the very thing you are testing, and note it if you do.
5. A log sheet. A simple spreadsheet or even a text file with columns for date, time, network, VPN state, target, samples, minimum, median, average, 95th percentile, maximum and packet loss.

Also check that nothing else on the machine uses the VPN differently. If you use split tunneling, make sure the app or tool you are testing really goes through the tunnel; our guide on what split tunneling is explains why a bypassed app would make the VPN look suspiciously fast.

Choose test targets that mean something

A benchmark against a single address is fragile. That address may be far from you, busy, or configured to answer ICMP slowly. Choose three to five targets that represent your real use:

• A nearby public DNS or infrastructure address. It shows the cost of the VPN with minimal distance on the far side.
• A site you open every day. News, email or a work portal. Use its domain name, not a stored address, so DNS is part of the real experience when you test with a browser.
• The service you care about. A game server, a conferencing service or a cloud region that your team uses. Many games and tools publish a test address or a latency display; use it as a second opinion.
• A far destination on another continent. It tells you whether the VPN path and the normal path diverge for long routes.

Use the same targets in every run. If a target stops answering ping, replace it in both the baseline and the VPN conditions, not just one of them.

One more point: ICMP echo (the ordinary ping) is treated differently from web traffic by some networks. When it matters, also measure an application-level request, for example the time to first byte of a small web page, using the browser's developer tools or a command-line fetch tool with timing output. Many modern services use QUIC over UDP, described in RFC 9000, so a TCP-based measurement is not always what the application experiences. Treat ping as an indicator and the application measurement as the confirmation.

The measurement procedure, step by step

Follow the same order each time. Here is a simple procedure for a computer.

1. Warm up. Open the target once in the browser, so DNS caches and routes are established. Cold first results are not representative.
2. Baseline with the VPN off. Run ping with at least 100 samples to each target. On macOS or Linux the command is ping -c 100 TARGET; on Windows it is ping -n 100 TARGET. Save the summary lines.
3. Run traceroute once per target (traceroute on macOS/Linux, tracert on Windows) and keep the output. It shows the hops and tells you later whether the path changed.
4. Connect the VPN. Wait 20 to 30 seconds so the connection settles and any initial key exchange or reconnect is complete.
5. Repeat the ping and the traceroute to the same targets with the same sample count.
6. Disconnect and repeat the baseline. This second baseline tells you whether the network itself drifted during the test. If the two baselines differ by more than about 10 to 15 percent, the test is unreliable; discard it and try again later.
7. Repeat the whole sequence in three sessions: for example morning, mid-afternoon and evening, or on three different days.

If you prefer to automate, a short shell loop that records timestamps and the output of ping into a file is enough. You do not need paid software. What you need is discipline about keeping everything else equal.

Record more than the average

The average hides the story. Record at least these values for each condition:

• Minimum: roughly the physical floor of the path (distance and equipment).
• Median: what half of the packets beat. This is the most honest "typical" number.
• Average: useful for comparison but sensitive to outliers.
• 95th percentile: the slowest 5 percent boundary. It captures the stutters you notice in a call.
• Maximum: one extreme spike. Note it, but do not build conclusions on it.
• Jitter: how much latency varies from one reply to the next. Many ping tools print a standard deviation (mdev); use that as a quick jitter estimate. See VPN jitter for what it means in practice.
• Packet loss: the percentage of requests with no reply. Even 1 to 2 percent loss can hurt a call more than an extra 20 ms; the article on VPN packet loss goes deeper.

A worked example makes this concrete. Imagine a remote worker on cable broadband measuring a conferencing service in the evening.

Condition	Min	Median	Average	95th pct	Max	Loss
VPN off, session 1	18 ms	21 ms	23 ms	34 ms	71 ms	0%
VPN on, session 1	41 ms	46 ms	49 ms	78 ms	140 ms	0%
VPN off (baseline 2)	18 ms	22 ms	23 ms	33 ms	65 ms	0%

The baselines agree, so the test is valid. The VPN overhead is the median difference, about 24 ms, and the worst-case difference at the 95th percentile is roughly 44 ms. For a video call that is comfortable. For a fast online shooter, the 95th percentile matters more than the average, and 78 ms with spikes would deserve a second look. These numbers are an invented example to show the method; your own will differ.

Read the results without fooling yourself

Raw numbers need interpretation. Use this short list of checks.

Compare medians first, then the 95th percentile. If medians differ by a few milliseconds and the tails overlap, call it a tie. Differences below your own run-to-run variation are noise.

Look at the sessions, not just the pooled data. If session 1 shows 24 ms overhead and session 3 shows 60 ms, the cause is probably congestion at a certain hour, on your side or the server's side, and not the VPN design.

Use the traceroute. If the VPN-on path travels to a far region before returning, the overhead is geography, as explained in VPN server distance. If the extra delay appears on the very first hop after the tunnel, the server may be busy or the network between you and it is poor.

Check what moved. Sometimes latency to a target drops with the VPN on because the VPN provider's route to that destination is more direct than your internet provider's. That can happen, and it is a legitimate result, but it is specific to that pair of networks and that time. Do not generalise it into "VPNs reduce ping".

Beware ICMP quirks. If ping through the tunnel looks wildly better or worse than a browser-level measurement, trust the application measurement. Some networks treat ICMP differently from web traffic.

Common mistakes that ruin a latency benchmark

• Four pings and a conclusion. The default on some systems is four pings. That is not a benchmark.
• Comparing a different time of day. Evening congestion is real. Always pair baseline and VPN measurements within minutes of each other.
• Testing on Wi-Fi from another room. Signal changes dominate everything.
• Forgetting that the VPN reconnected. Check the app shows a stable connection throughout. A silent reconnect creates one giant outlier.
• Using a destination in the same building as the VPN server. It shows an unrealistically small overhead. Test the places you really visit.
• Switching servers between runs. Two different servers are two different experiments.
• Reading one provider's marketing number as your result. Latency is local to your network. Another person's figure does not transfer to your home.
• Ignoring DNS. If DNS queries go through a slow resolver, pages will feel slow even when ping is fine. Compare DNS lookup time separately when browsing feels slow.

Troubleshooting a high result

If the overhead is larger than you expected, work down this list in order and retest after each change.

1. Move to a cable or sit closer to the router, and repeat.
2. Pause background downloads and cloud sync.
3. Reconnect and choose a server closer to your target or to you. A server on the way to the destination adds less detour than one in the opposite direction.
4. Reboot the router if its uptime is long, particularly when packet loss appears in the baseline.
5. Close other VPN or security apps that could be filtering the same traffic; conflicts add delay. If the connection drops or stalls, the VPN not connecting guide and why is my VPN slow cover practical fixes.
6. Try again in a different hour. If the problem is only at peak time, the cause is likely congestion, not configuration.

After these steps, treat the remaining difference as the realistic cost of the detour for your situation.

A reusable benchmark template

Copy this plan and adapt it.

• Goal sentence: one line stating destination, network and time.
• Targets: three to five, same in every condition.
• Samples: 100 per target, per condition.
• Sessions: three, at different times.
• Order: baseline, VPN, baseline.
• Metrics: minimum, median, average, 95th percentile, maximum, deviation, loss.
• Validity rule: baselines within 10 to 15 percent of each other.
• Output: median overhead and 95th-percentile overhead, per target, with one sentence of interpretation.

Keep the sheet. When you change your router, internet plan or VPN server, run the same plan again and compare like with like. A benchmark that you can repeat in six months is worth more than a perfect one you cannot.

Summary

A fair VPN latency benchmark compares the same device, network and targets with the VPN off and on, uses at least 100 samples, repeats in several sessions, brackets the VPN run with two baselines and reports the median and 95th percentile alongside jitter and loss. The result is the overhead for your own situation, not a universal ranking, and small differences are usually noise. If you want to try the measurement on a short prepaid pass, you can look at the pricing page and run the template above on your own network.