How to Benchmark VPN Download and Upload Speed

When people say "my VPN is slow", they usually mean one of three different things: pages take a long time to start, a large download crawls, or an upload (a backup, a video, a shared folder) never seems to finish. Those are different symptoms with different causes. A proper VPN throughput benchmark measures how many megabits per second actually move through the tunnel in each direction, and compares that to what your line carries without it.

This article is about throughput only. Delay (ping) is a different measurement, covered in VPN latency explained; the steps below are about how fast data moves. If you only want a quick sanity check, how to test a VPN is a shorter route. If you want to understand why numbers drop at all, read why internet speed changes with a VPN.

What throughput means and why one number is not enough

Throughput is the amount of useful data delivered per second, usually written in megabits per second (Mbit/s). Your internet plan advertises a maximum; what you get on a given day is lower. A VPN lowers it further for several reasons:

• Encryption and packaging. Every packet gets extra headers and has to be encrypted and decrypted, which costs a little capacity and some processor time.
• A longer path. The route to the VPN server and then onward may be longer than your direct route.
• The server's load. A server shared with many other users has a finite amount of capacity at that moment.
• Your device. A phone or an old laptop may not be able to encrypt as fast as the line can deliver.
• Packet size problems. If packets are sized wrongly for the tunnel, they get split or resent, which wastes capacity.

Because many causes act together, a single number tells you very little. You need a set of numbers that can be compared.

Number	Why it matters
Download, VPN off	Your normal ceiling
Download, VPN on	What the tunnel delivers toward you
Upload, VPN off	Your normal upload ceiling
Upload, VPN on	What the tunnel delivers away from you
Single stream vs several streams	Whether one connection or the whole tunnel is the limit

Step 1: Fix the conditions before you start

A benchmark is only worth reading if everything except the tunnel stays the same. Prepare this checklist.

1. Use a cable if you can. If you test on Wi-Fi, stay in the same spot, close to the router, and note the band you are using.
2. Close the noisy apps. Cloud sync, system updates, game launchers, backups and streaming tabs all take bandwidth that you are trying to measure.
3. Use one device. If you want to compare devices later, do that as a separate project.
4. Pick one VPN server and keep it. Write down its location label so you can repeat the test.
5. Disable other proxies and security add-ons for the test. Browser extensions that scan traffic can lower the result, and so can a second VPN or a filtering app. Our article on VPN blocked by antivirus shows how such software can interfere.
6. Note the time. Evening hours are busy on many home networks. Run each condition within a few minutes of its pair.

Check what your plan says on paper too. If your plan is 100 Mbit/s down and 20 Mbit/s up, the highest result you should ever expect is a little below those numbers (typically 90 to 95 percent after overhead). A result far below this with the VPN off points to a problem outside the VPN.

Step 2: Measure the baseline with the VPN off

Run the full test sequence with no VPN first. The point is to learn your real ceiling, not the number printed on your bill.

Use two kinds of tools together.

A browser-based speed test site. It is the simplest option and gives quick download, upload and latency numbers. Its weakness is that it chooses a nearby test server automatically, and the choice can change between runs. Write down which server it used and, if the site lets you, fix it.

A controlled transfer. For more control, use a command-line tool that measures raw throughput between two machines, or download a known large file from the same web address each time and time it. The first approach needs a second computer or a test server you control. The second needs only a stable web host that serves a big file and supports normal HTTP downloads as described in RFC 9110.

For each condition, record at least three runs and note the median, not just the best. A single great run is a coincidence; a stable median is a measurement.

Do the baseline twice: once before the VPN tests and once after. If the two baselines differ by more than about 10 percent, something changed on your network and the session should be repeated.

Step 3: Test download and upload separately

Many people run the speed test, see one big "download" figure, and stop. Upload deserves equal attention for anyone who sends large files, works on video calls, or backs up photos.

Download test. Pull a large file or run the download phase of the tool for at least 30 seconds. Look at the steady part of the graph, not the first few seconds. The initial ramp-up is not representative.

Upload test. Send a large file to a service you control or use the upload phase of the tool. Upload runs into different ceilings from download: your plan is usually much lower in that direction, and a VPN's per-packet overhead is a bigger share of a small pipe.

A realistic example with invented numbers for a home line sold as 200 Mbit/s down and 30 Mbit/s up:

Condition	Download median	Upload median
VPN off	188 Mbit/s	28 Mbit/s
VPN on, same city server	142 Mbit/s	24 Mbit/s
VPN on, server far away	61 Mbit/s	17 Mbit/s

From this, the VPN costs about 24 percent of download and about 14 percent of upload on the nearby server, and much more with a faraway one. Presenting the numbers as percentages of your own baseline is fairer than comparing them with someone else's line.

Step 4: Use one stream and several streams

Most network transfers on the internet are TCP connections, and a single TCP connection can be held back by the round-trip time and the size of its window. The result is that one stream may not fill a fast line, especially over a longer path such as one through a distant VPN server.

Run both of these:

• Single stream. It is how a simple file download or a single large upload behaves, so it is close to what an ordinary app feels.
• Parallel streams. Four to eight connections at once. This shows the best the line and the tunnel can carry together, and it is closer to what a browser, a download manager or a speed test website uses.

Interpreting the pair:

1. If one stream is slow and several streams are fast, the tunnel itself is fine. The limit is the round-trip time on a single connection. A closer server or an app that opens more connections will help.
2. If both are slow by a similar amount, the limit is capacity: the server, your processor, or the path.
3. If several streams are slower than one, something is oversubscribed, often a weak device processor or a congested Wi-Fi link.

Our article on VPN speed vs no VPN discusses typical differences in more depth, and WireGuard speed test looks at how the protocol choice shows up in numbers.

Step 5: Find the bottleneck, do not just record the result

A benchmark is supposed to answer a question, and the usual question is "what is limiting me?" Work through this checklist when the VPN result is clearly lower than the baseline.

Is it the device? Open the system's activity monitor during the test. If one processor core is near 100 percent while the transfer runs, the device is the bottleneck. Phones, small tablets and older laptops show this most. A newer or wired machine will show a very different figure.

Is it the Wi-Fi? Repeat on a cable. If the cable result is much higher, your wireless link was the limit, not the VPN.

Is it distance? Try a server closer to you, then one far away, with the same procedure. If speed falls clearly with distance, the path is the limiting factor. See VPN server distance for why this happens.

Is it the server? Repeat at a different hour. If the speed recovers late at night, the server or the route is busy at peak times. Our piece on VPN server load explains what that means for you.

Is it throttling? If a particular type of traffic is consistently slower than the rest, even on another server, your network operator may be shaping it. VPN bandwidth throttling covers how to recognise it without jumping to conclusions.

Is it packet size? If the connection works but large transfers stall or fall to a trickle while small pages load, the packet size (MTU) may be wrong for the tunnel. Path MTU discovery, described in RFC 1191, is the mechanism that is supposed to handle this. When it fails, fixing the size setting can recover a lot of speed.

Step 6: Report results in a way others can trust

If you plan to share your numbers with a colleague, a family member, or a support team, write them down in a consistent format. A good report includes:

• The date, time and duration of each run.
• The device model and how it was connected (cable or Wi-Fi band).
• The line's advertised rates and your baseline.
• The VPN server location label and the connection type shown in the app.
• The tool used, number of streams, file size and test server.
• Medians for download and upload, with the range.
• Notes on anything unusual: another device on the network, a reconnect, a sync running.

Percentages are more useful than raw numbers. "The VPN delivered 76 percent of my baseline download and 86 percent of my upload on the nearby server" tells a reader what to expect, while "I got 142" does not.

Common mistakes

• Testing for five seconds. The ramp-up phase is lower and noisier than the sustained rate.
• Measuring only download. Upload is the other half of many real tasks.
• Letting the test site choose a different server each time. The comparison collapses when the destination changes.
• Comparing Wi-Fi with a VPN to a cable without. Change one thing at a time.
• Ignoring the device processor. The tunnel cannot go faster than the device can encrypt.
• Reading the best run as the result. Use the median of at least three runs.
• Confusing megabits with megabytes. Speed tests show megabits per second; file managers show megabytes per second. One megabyte per second is eight megabits per second.
• Declaring a winner from a single comparison. One afternoon on one network proves little about another.

Practical examples

A student sharing a laptop with a hotspot. Lina has a mobile data plan and uses her phone as a hotspot. She tests with one stream and with four. One stream gives 11 Mbit/s, four streams give 24 Mbit/s with the VPN on. She learns that the tunnel can carry more but each connection is limited by the mobile path, so she prefers apps that open several connections for large downloads.

A remote worker uploading design files. Arun measures upload because he sends 2 GB packages every evening. His baseline is 35 Mbit/s up and the VPN result is 29. He compares a nearby and a far server, picks the nearby one, and schedules the upload for the time when his own home network is calm.

A family backing up photos. Their router also serves a smart TV. They notice that the photo backup stalls during an evening film. The benchmark with the TV off shows the VPN delivering most of the baseline; the problem is local congestion, not the tunnel.

Summary

A trustworthy VPN throughput benchmark measures download and upload separately, with the VPN off and on, using large transfers or a fixed test server, one stream and several streams, and at least three runs per condition. Express the result as a percentage of your own baseline, then work through the bottleneck checklist: device, Wi-Fi, distance, server load, throttling and packet size. If you want to run the method on a short prepaid pass, the pricing page shows what is available.