How to Compare VPN Protocols on the Same Network

Ask ten people which VPN protocol is best and you will get ten confident answers, most of them based on one speed test done once on one evening. A fair comparison is not hard, but it does require discipline. The aim of a VPN protocol comparison test is to change exactly one thing, the protocol, while everything else stays the same, and then measure the results often enough that luck cancels out.

This article gives you a repeatable method for comparing two protocols on a single network, for example WireGuard and OpenVPN. It covers what to hold constant, what to measure, how to run the sequence, how to write down the results and how to decide. It does not tell you which protocol your own VPN supports, because that depends on your service and app. If you need background on what protocols are first, read what a VPN protocol is and the overview of WireGuard vs OpenVPN.

What a fair comparison means

A fair test has one variable and many controls. The variable is the protocol. The controls are everything else that could change the number.

Here is the list of things that must stay fixed during a comparison.

• The device. The same laptop or phone, on the same battery level, with background apps closed.
• The network. The same Wi-Fi network and the same position in the room, or the same cable. Do not compare protocols on Wi-Fi in the morning against mobile data in the evening.
• The VPN location. The same server location for every run. Distance changes latency and speed, which is explained in more detail in why VPN speed changes.
• The test targets. The same speed-test server, the same download file and the same latency target.
• The time window. Run all the tests within about thirty minutes, because home networks are busiest in the evening and quieter at night.
• The app version and settings. No updates in the middle of the test, and no other changes to the kill switch, DNS or split tunneling.

If you cannot control one of these, write it down. A result with a known weakness is still more useful than a result with a hidden one.

Notice what is missing from the list: marketing claims. Whatever you have read about one protocol being "twice as fast" was measured in someone else's lab. Your result on your network may be closer, further or even reversed.

First, find out whether you can choose a protocol

Before you plan anything, check whether your VPN app exposes a protocol choice at all. Some apps show a setting, some choose automatically and some hide the option unless you open an advanced screen. Look in the settings or connection menu and read what is offered, without guessing at names. If there is no protocol setting, you cannot run this test, and that is fine: it simply means the app has already made a choice that suits most users.

For XPASS customers, the free VPNclient app uses the username and password from the My Pass page, and the supported connection methods are listed there. If the app shows a protocol setting, leave it on the default for everyday use, and change it only for a deliberate test or when support suggests it. After a test, set it back to where it was and note the original value in your sheet.

Also decide what you actually want to know. The question "which is faster" has three common variants:

1. Which gives the best download speed on my home line?
2. Which gives the steadiest calls and gaming on mobile data?
3. Which connects most reliably on a restrictive network such as a hotel or office?

Each variant leads to a different measurement set. Write your question at the top of the sheet.

The metrics worth measuring

Five measurements cover almost every real-world difference. Others are optional.

Metric	What it tells you	How to get it	Matters most for
Throughput (download and upload)	How much data per second the tunnel carries	A speed-test page or file download	Downloads, streaming, backups
Latency (round-trip time)	How long a small message takes to go and return	A ping test or latency page	Calls, games, interactive apps
Jitter	How much latency varies from one packet to the next	A test that reports jitter, or ping spread	Calls and games
Connect time	Seconds from pressing connect to working traffic	A stopwatch	Daily convenience
Recovery time	Seconds to recover after a network switch or sleep	Stopwatch after toggling Wi-Fi	Mobile and travel use

Optional extras are CPU use on a laptop, battery drain over an hour on a phone, and packet loss during a long ping run. Latency is explained clearly in Cloudflare's guide to what latency is, and the effect of delay on gaming is covered in does a VPN reduce ping and in the note on VPN jitter.

Build the baseline: no VPN at all

Every comparison needs a zero point. Turn the VPN off and take the same measurements on the bare connection: five speed tests, a ping run to your latency target, and a note of jitter. This tells you the ceiling. If the bare line gives 200 Mbps and both protocols give about 90 Mbps, the protocol is not your bottleneck, and the VPN server or distance is.

Record the baseline at the start and again at the end of the session. If the two baselines differ by more than about 20 percent, the network moved under you and the session is suspect. Run it again at a calmer time.

The test sequence: alternate, do not batch

The most common error is running all of Protocol A and then all of Protocol B. If the network gets busier halfway through, Protocol B looks worse for reasons that have nothing to do with it. Alternate instead.

1. Baseline (no VPN): 3 speed tests and one 30-second ping run.
2. Protocol A: connect, wait 10 seconds, run one speed test and one ping run. Disconnect.
3. Protocol B: connect, wait 10 seconds, run one speed test and one ping run. Disconnect.
4. Repeat steps 2 and 3 until you have five runs of each, alternating A, B, A, B, and so on.
5. Baseline again.

A full session takes about 40 minutes. Between runs, fully disconnect so that each connect is a fresh handshake. If you want to start with Protocol B once, swap the order in the second round to cancel any "first connection" effect.

For the speed test itself, use the same page every time and choose the same test server. Pick a nearby one for the throughput measurement, because a distant test server adds its own distance to what you are measuring. For more on interpreting speed pages, see how to run a VPN speed test and, if WireGuard is involved, WireGuard speed tests.

Record the results on one sheet

A simple table beats a pile of screenshots. Use one row per run.

Run	Protocol	Download (Mbps)	Upload (Mbps)	Ping (ms)	Jitter (ms)	Connect time (s)	Notes
1	A
2	B
3	A
4	B

At the end, calculate the median for each metric and each protocol. The median is the middle value when sorted, and it ignores a single odd result. The average gets dragged around by one outlier, and the "best run" is simply luck. If one run is wildly off, do not delete it: repeat that run and see whether the oddity repeats. A pattern is information.

Also calculate a spread, meaning the highest minus the lowest. A protocol with a slightly lower median but a much smaller spread is often more pleasant to use for calls.

Reading the numbers without fooling yourself

You now have a table. Read it with these rules.

• Ignore differences under about 10 percent. Home networks fluctuate more than that, so a gap of 5 percent is noise.
• Check the spread before the median. If A averages 80 and swings between 40 and 110, while B averages 75 and stays between 70 and 80, B is the steadier experience.
• Compare against the baseline. Express each result as a percentage of the baseline. "Protocol A keeps 85 percent of my line speed" is easier to reason about than a raw number.
• Latency changes are usually small. A tunnel adds a few milliseconds, and the VPN server's distance adds more. If the two protocols differ by less than the jitter, they are equivalent for latency.
• Look at the first-second behaviour. A protocol that takes a few seconds longer to connect may still be better for a long download.
• Upload matters too. Some tunnels favour one direction. If you back up photos or join video calls, check upload.

A small example. Dara tests on home Wi-Fi with a baseline of 120 Mbps down and 20 ms ping. Protocol A gives a median of 95 Mbps, 27 ms, and a spread of 15 Mbps. Protocol B gives 102 Mbps, 26 ms and a spread of 40 Mbps. B wins on the median but is less steady. Because Dara mostly streams and downloads, she might pick B. If she spent evenings in video calls, the steadier A could be the better choice. The numbers did not pick for her: her use did.

Protocol behaviour that explains your results

A few general facts help you interpret surprises, without relying on any claims about a specific service.

• UDP versus TCP carriage. Many protocols run over UDP, which is lightweight, but some can also run over TCP. TCP inside a TCP-based tunnel can slow down under packet loss, an effect covered in OpenVPN TCP vs UDP. On a lossy mobile network, the transport matters as much as the protocol.
• Packet size and MTU. If the tunnel's packet size is too large for the path, packets are split or dropped and speed collapses. The Path MTU Discovery standard, RFC 1191, describes the mechanism that normally avoids this. A strangely slow result that improves with a lower packet size is a clue.
• CPU cost. Encryption uses processor time. On an older phone or a low-power laptop, a protocol that does less work per packet leaves more headroom. On a modern computer, you may see no difference.
• Handshake and rekeying. Protocols differ in how fast they connect and how gracefully they recover after the network changes. This shows up in your connect and recovery times, not in your speed test.
• Restrictive networks. Some hotel and office networks allow only certain kinds of traffic. A protocol that is fastest at home may fail to connect there. That is a compatibility finding, not a speed one.

You can read more detail on how WireGuard is designed on the WireGuard site and how OpenVPN options work in the OpenVPN community resources.

Three test plans for three situations

The home streamer. Aim: maximum throughput on fixed broadband. Use a wired or close-range Wi-Fi connection, a nearby VPN location, five alternating download tests of a large file, and compare medians. Ignore ping unless you also game.

The commuter. Aim: steady calls on mobile data. Test on the same bus route or the same spot, measure jitter and recovery time. For recovery, connect, then toggle airplane mode for five seconds and time how long until a page loads. Run it three times for each protocol.

The traveller in a hotel. Aim: something that connects at all. The first test is binary: does each protocol connect on this network, and how long does it take? Only then compare speeds. If one protocol fails, record exactly what happened and see VPN not connecting for the standard checks. Do not try to defeat the hotel's rules, just choose what works.

Common mistakes in protocol testing

• Running all of A, then all of B, and calling the difference a result.
• Using one run, or the best run, rather than the median of several.
• Changing the server location between protocols.
• Testing while someone else streams video on the same Wi-Fi.
• Forgetting to restore the app's original setting afterwards.
• Treating a 5 percent gap as a win.
• Measuring only download and ignoring upload and jitter.
• Believing a result from last year's app version still applies.

When not to bother

Most people do not need this test. If the VPN works and your pages load, leave the protocol setting alone. The method is for three cases: you are troubleshooting a real slowdown, you have a specific use such as competitive gaming where small changes matter, or you simply want to understand your own network. For slowdowns, start with the help article on why a VPN is slow, because location, Wi-Fi quality and the device usually matter more than protocol choice.

Summary

A fair VPN protocol comparison test changes only the protocol, keeps device, network, location, time and test targets fixed, and alternates the protocols across at least five runs each. Measure throughput, latency, jitter, connect time and recovery time, compare the medians and the spread against a no-VPN baseline, and ignore gaps smaller than about 10 percent. Decide using your own priority: downloads, calls or compatibility. Afterwards, restore the original setting.

If you want a short prepaid pass to run this kind of test on your own devices, the pricing page lists the current options, and the download page has the free app for each platform.