How to test VPN speeds yourself (and why marketing numbers mislead)
How to evaluate a VPN like a security professional: policies, jurisdictions, audits, and honest speed tests.
Why marketing speed claims are worthless
VPN providers love plastering "fastest VPN" or "no speed loss" across their landing pages. These claims are meaningless. What you're seeing is a best-case scenario—usually a test from their own servers, during off-peak hours, on a gigabit connection most people don't have. When a provider claims "ultra-fast 6730 Mbps speeds," they're not lying exactly, but they're measuring something irrelevant to your actual experience.
Speed depends on dozens of variables: your base internet speed, physical distance to the VPN server, server load, time of day, encryption overhead, your device's CPU, even your router's firmware. A VPN can't make your 100 Mbps connection faster. At best, it might reach 85-95% of your baseline. Anyone promising otherwise is selling fantasy.
The only speed test that matters is the one you run yourself, on your connection, during the hours you'll actually use the service. This chapter shows you how to do that properly.
What you're actually measuring
Before running tests, understand what affects VPN speeds:
Encryption overhead: Every VPN encrypts your traffic, which requires processing power. Modern protocols like WireGuard minimize this, but physics still applies. Expect 5-15% overhead on a decent connection, more on weaker devices.
Distance and routing: Data traveling from Boston to a London server takes longer than hitting one in New York. VPNs add an extra hop—your traffic goes to the VPN server first, then to its destination. More distance equals more latency (delay), which feels like slowness even if bandwidth (throughput) stays high.
Server congestion: A server handling 500 simultaneous users performs worse than one handling 50. Premium providers maintain better user-to-server ratios, but you can't see these numbers from marketing materials.
Protocol efficiency: OpenVPN is stable but slower. WireGuard is faster but newer. IKEv2 splits the difference. Your choice affects speed, but there's no universal "best"—it depends on your use case.
ISP throttling: Some internet providers slow down specific traffic types. A VPN can occasionally improve speeds by hiding what you're doing from your ISP, but this is the exception, not the rule.
Setting up a proper baseline test
You can't measure VPN performance without knowing your starting point. Most people skip this step and wonder why results seem random.
Close everything: Shut down background updates, streaming services, cloud backups, other devices on your network. Even your smart TV pulling a firmware update skews results.
Test at consistent times: Internet speeds fluctuate throughout the day. Run your baseline test at the same time you'll test the VPN—ideally during peak evening hours when congestion is highest. A Tuesday at 2 PM tells you nothing about Friday night performance.
Use multiple test servers: Don't rely on Speedtest.net's default server. Manually select 3-4 geographically diverse servers and average the results. Your ISP might have peering agreements with specific networks that don't reflect real-world speeds.
Record everything: Make a spreadsheet. Note the date, time, test server location, download speed, upload speed, and ping. You'll need this data for comparison.
Run five tests minimum: Network jitter is real. One test might hit 120 Mbps, the next 95 Mbps on the same connection. Run five consecutive tests, throw out the highest and lowest, average the middle three. This eliminates outliers.
Example baseline:
``` Time: 8 PM EST, Wednesday Test server: New York (Verizon) Tests: 98, 102, 101, 95, 103 Mbps Average: 100.67 Mbps (after removing 95 and 103) Upload: 35 Mbps Ping: 12 ms ```
How to test VPN speeds properly
Now connect to your VPN and replicate the exact same process. Same time window (test immediately after baseline), same test servers, same methodology.
Test multiple VPN servers: Don't just hit "quick connect." Test servers in different locations:
- A server in your city or closest major hub
- A server 500-1000 miles away
- A server on another continent (if you need international access)
- A server in a popular streaming region if that's your use case
Test both TCP and UDP: Most VPNs default to UDP (faster but occasionally blocked). Switch to TCP and test again. If your workplace or hotel blocks UDP, that "fast" VPN becomes unusable.
Test different protocols: If the VPN offers WireGuard, OpenVPN, and IKEv2, test all three. WireGuard usually wins for speed, but not always. NordVPN's NordLynx (WireGuard implementation) typically shows 15-30% better speeds than their OpenVPN servers, but your mileage varies by device.
Check mobile performance separately: Desktop and mobile clients use different code. A VPN that flies on your laptop might crawl on your phone due to CPU limitations. Test both if you use both.
Document everything with the same rigor:
``` VPN: [Provider Name] Server: New York (same city as baseline) Protocol: WireGuard Time: 8:05 PM EST (5 mins after baseline) Test server: New York (Verizon) - same as baseline Tests: 87, 91, 89, 88, 90 Mbps Average: 89.33 Mbps Upload: 32 Mbps Ping: 18 ms Speed retention: 88.7% Latency increase: +6 ms ```
Interpreting your results
Raw numbers need context. Here's what actually matters:
70-90% retention is normal: If your 100 Mbps baseline drops to 85 Mbps through the VPN, that's expected. You're seeing encryption overhead and routing distance. Anyone promising "no speed loss" is lying.
50-70% is acceptable for distant servers: Connecting from California to a Tokyo server and keeping 60% of your speed is reasonable. Physics exists. The speed of light through fiber is finite.
Below 50% suggests problems: Either the server is overloaded, the routing is inefficient, or the protocol isn't optimized for your connection. Try different servers and protocols before blaming the provider entirely.
Latency matters more than throughput for some tasks: A 20 ms ping increase barely affects streaming but ruins gaming. If you're seeing +50 ms consistently, that VPN isn't suitable for real-time applications.
Upload speeds often drop more than download: This is normal. Encryption overhead hits both directions, but since upload is already slower for most connections, the percentage drop feels larger.
Consistency beats peak performance: A VPN that delivers 80 Mbps every test is better than one bouncing between 95 and 55 Mbps. Stability matters.
Testing during trial periods
Most VPN providers offer 30-day money-back guarantees or short trials. Use this window strategically.
Test your actual usage pattern: If you stream after work, test at 7-10 PM for a week. Weekend mornings if that's when you game. Test during your real routine, not when it's convenient.
Rotate through servers: Don't marry one server location. Test 5-10 different servers across the provider's network. Some providers have excellent US infrastructure but terrible European servers, or vice versa.
Stress test the network: Run tests during major sporting events, season finales, holiday weekends—times when everyone's online. A VPN that performs well on a random Tuesday morning might collapse during Sunday Night Football.
Compare against competitors: Run the same test methodology on 2-3 providers simultaneously (most trials overlap). You'll quickly see which providers maintain performance under realistic conditions. Tools like ExpressVPN and Mullvad often show up well in head-to-head comparisons, but your network might behave differently.
Common testing mistakes
Using VPN-provided speed tests: Some providers built speed-test tools into their apps. These are optimized to make their network look good. Use independent tools like Speedtest.net, Fast.com (Netflix's test), or Measurement Lab.
Testing immediately after connecting: Give the connection 30-60 seconds to stabilize. Initial connection speeds often don't reflect sustained performance.
Testing only when your connection is idle: Real-world usage means other devices, background apps, and concurrent streams. Your pristine test environment doesn't match actual conditions.
Ignoring protocol differences: "This VPN is slow" might mean "OpenVPN is slow on my device." Before abandoning a provider, test all available protocols.
Forgetting to disconnect between tests: Sounds obvious, but people run "VPN off" tests while still connected. Confirm you're disconnected before baseline tests.
Not testing across multiple days: One evening of tests doesn't capture provider consistency. Test across a week minimum, ideally during the trial period.
Tools beyond basic speed tests
Basic speed tests measure throughput, but they don't tell the whole story.
Ping and packet loss: Use `ping` commands (Windows) or `ping` in Terminal (Mac/Linux) to test latency and stability. Ping a reliable server like `8.8.8.8` (Google DNS) for one minute with and without the VPN. Packet loss above 1-2% indicates routing problems.
Traceroute analysis: Run `traceroute` (Mac/Linux) or `tracert` (Windows) to see the path your traffic takes. With a VPN, you'll see traffic route through the VPN server. Excessive hops or slow intermediary servers explain speed issues.
Streaming-specific tests: Fast.com specifically measures Netflix delivery speeds. If you're choosing a VPN for streaming, Fast.com results matter more than Speedtest.net numbers.
Real-world application testing: Time how long a 100 MB file takes to download with and without the VPN. Load your most-visited websites and compare load times. These practical tests often reveal issues pure speed tests miss.
What to do with your data
After a week of testing, you'll have a dataset showing:
- Baseline speeds at different times
- VPN performance across multiple servers and protocols
- Consistency patterns
- Protocol-specific advantages
Look for patterns. If every server in Europe is slow but US servers fly, you know the provider's international infrastructure is weak. If speeds tank every evening after 8 PM, they're overselling server capacity.
Calculate the opportunity cost. If you're paying $10/month for a VPN that cuts your 200 Mbps connection to 90 Mbps while a competitor maintains 170 Mbps for $12/month, that $2 might be worth it. Speed isn't everything—jurisdiction, logging policies, and audit history matter—but it's a major factor.
When speed doesn't matter
Sometimes, VPN speed is irrelevant. If you're bypassing censorship in a restrictive country, a working connection at 5 Mbps beats a blocked connection at any speed. If you're protecting sensitive communications, the security audit matters infinitely more than whether you get 80 or 95 Mbps.
But if you're choosing between audited, reputable providers with similar privacy policies, speed becomes the tiebreaker. Test properly so you're comparing reality, not marketing.
Key takeaways
- Marketing speed claims are best-case scenarios that don't reflect your actual experience—always test yourself during the trial period
- Establish a proper baseline by testing your raw internet speed multiple times at the same hours you'll use the VPN, using multiple test servers
- Test VPN speeds across multiple server locations, protocols, and times of day using the exact same methodology as your baseline
- 70-90% speed retention is normal; below 50% suggests problems with the server or routing
- Consistency matters more than peak performance—a VPN delivering stable speeds beats one with erratic results
- Use independent speed test tools, not VPN-provider tests, and combine throughput measurements with real-world usage testing