Complete VPN security audit: 9 tests to verify your protection

Turning a VPN on is trivial. Verifying that it actually does what it promises — that's another matter entirely. Most users click "Connect", see a green checkmark, and call it done. The client shows a foreign IP, so everything must be fine. Except that green light says nothing about DNS queries leaving in the clear to your ISP, the real IP revealed by WebRTC to any site that queries the browser, or the kill switch that never fires because an OS update silently disabled the extension.

This nine-test audit takes about half an hour the first time, then fifteen to twenty minutes as a quarterly routine. It goes beyond the classic leaks (IP, DNS, WebRTC, IPv6) — it also checks platform-side geolocation for streaming, browser fingerprinting (which survives the VPN), and overall stability over ten minutes of real-world conditions. It's more demanding than most quick 7-step VPN checks, and it's the exact protocol we apply to the VPNs we test internally for our published methodology.

Why a VPN set to "ON" is never enough on its own

The encrypted tunnel between your device and the VPN server is solid. It uses OpenVPN, WireGuard, or IKEv2 with modern cipher suites (AES-256-GCM, ChaCha20-Poly1305) — the cryptographic layer itself has essentially stopped being the weak link since 2018. The weak link today is everything that bypasses the tunnel without your knowledge.

Four vulnerabilities account for 80% of issues found in audit. First, silent DNS leaks: your OS keeps resolving domain names through your ISP's DNS server, which therefore sees every site you visit even though the content is encrypted. Second, browser-side WebRTC leaks: a JavaScript snippet on any page probes ICE candidates and retrieves your local and real public IP despite the active VPN. This is documented in RFC 8826 on WebRTC security considerations and is the most exploited de-anonymisation vector by behavioural marketing networks.

Third, unmanaged IPv6: your ISP deploys IPv6 natively (BT, Sky, Virgin Media in the UK; Comcast, Verizon in the US), your VPN only tunnels IPv4, and the result is that Google, Cloudflare, and Facebook see your real IPv6 while you think you're protected behind the VPN's IPv4. Fourth, an absent or broken kill switch: at any VPN drop (Wi-Fi change, screen suspend, client update), your traffic resumes in the clear with no visible alert, sometimes for minutes before automatic reconnection.

The Electronic Frontier Foundation puts it plainly: a VPN is a tool for delegating trust, not absolute anonymisation. You shift trust from your ISP to your VPN provider, on condition that they correctly configure the tunnel, handle client-side leaks, and honour their logging policy. Verifying those three technical conditions is what the tests below are for.

Test 1 — Is your public IP actually masked?

This is the most basic test and the one that catches 10% of broken configurations in under 30 seconds. Open our My IP tool without the VPN first. Note the IPv4 address displayed, the IPv6 if present, and — crucially — the name of the internet provider (BT, Sky, Virgin Media, Comcast, Verizon, Spectrum in the US; etc.). That's your baseline.

Now activate the VPN on a server of your choice — pick a geographically nearby server to keep test latency low. Reload the page. The IPv4 must be completely different. The displayed provider must switch to a datacenter host name: Tefincom S.A. (NordVPN subsidiary, Panama), Datacamp Limited (CDN77, also used by NordVPN), M247 Europe (used by several VPNs), Tata Communications, Leaseweb, Hetzner Online, DigitalOcean, or OVH. The detected geolocation should also have shifted to match the selected server's country.

If the IP hasn't changed after activation, either the VPN client isn't actually connected (check the interface status), or your corporate network is routing traffic through a proxy that overrides the VPN. A rarer case: on some split-tunnel configurations set up incorrectly, the client leaves the browser in the clear while tunnelling other apps — disable split-tunnelling for this test.

Also note the detected country: it must match the selected server. A mismatch (server listed as Netherlands, geolocation showing Germany) suggests either a poorly referenced server in the MaxMind GeoIP2 or IP2Location databases, or a transit route that exits in Germany despite the Dutch announcement. Not critical for privacy, but important when targeting a specific streaming catalogue — Netflix reads MaxMind geolocation, not the country declared by the VPN.

Test 2 — DNS leaks: the silent trap

A correctly masked IP guarantees nothing about DNS. The classic scenario: the tunnel encrypts all outgoing HTTPS traffic, but your OS keeps resolving netflix.com, bbc.co.uk, or nytimes.com through the ISP's DNS server configured when you joined the Wi-Fi. Your ISP therefore sees your domain history, chronologically indexed, timestamped to the second. No visible signal on your VPN client.

This is the most frequent and least visible leak — hence its absolute criticality. The quick test: visit dnsleaktest.com with the VPN active, click "Extended Test" (never the "Standard Test", which is insufficient), and wait 10 to 20 seconds. The tool sends about twenty unique DNS queries and lists every server that responded. If even one of those servers matches your ISP (BT, Sky, Virgin Media, Comcast, Verizon…), you have a confirmed leak.

Complementary test: our internal DNS leak tool, which combines DNS, WebRTC, and IPv6 detection in a single pass. It's the fastest check to confirm in 30 seconds that the three main leak types are neutralised. For the detailed OS-by-OS method — how to disable Smart Multi-Homed Name Resolution on Windows 11, how to force VPN DNS on macOS, how to handle systemd-resolved on Linux — see our complete DNS leak test guide, which covers every fix in detail.

On good paid VPNs, this test passes without any configuration: NordVPN, ExpressVPN, Surfshark, ProtonVPN, and Mullvad push their own recursive DNS servers when active. On free or budget VPNs, the OS decides — and the OS defaults to the ISP's server, guaranteeing a leak.

Test 3 — WebRTC leaks: the browser trap

WebRTC is designed for peer-to-peer communication in the browser — Google Meet video calls, real-time file sharing, online gaming. To function, it tries to discover all IP addresses on your machine: local IP (192.168.x.x), public IPv4, public IPv6, STUN and TURN candidates. Including the IPs your VPN is supposed to mask. If nothing blocks it on the VPN client side or browser side, any JavaScript snippet on any page can read your real IP in the background, with no user interaction and no permission requested.

This is the sneakiest leak of the nine tests. From the outside, the VPN shows "connected", the public IP seen via web tool is masked, DNS passes. But WebRTC silently betrays your real IP to any site that queries the browser — it's massively used by ad networks and fraud detection platforms.

The test: run our DNS leak test tool, which probes WebRTC ICE candidates from your browser and lists every IP revealed. Compare with the VPN exit IP noted in test 1. If a different public IP appears in the WebRTC list, leak confirmed. If only the VPN server's IP appears, protection is effective.

Solutions in decreasing order of effectiveness. First, enable WebRTC protection in the VPN client — most good VPNs have this option, sometimes called "WebRTC Leak Protection" or "Disable WebRTC". Second, install the provider's official browser extension, which disables WebRTC at the browser level and is more robust than a client-side block. Third, disable WebRTC manually: on Firefox, type about:config and set media.peerconnection.enabled to false; on Chrome, use uBlock Origin with "Prevent WebRTC from leaking local IPs" enabled under privacy settings.

Note: Brave has a well-configured native WebRTC protection and is one of the few mainstream browsers that passes this test without an additional extension. Tor Browser blocks WebRTC entirely by design.

Test 4 — Does the kill switch actually fire?

The kill switch automatically cuts your internet connection if the VPN tunnel drops. Without it, a one-second disconnection — Wi-Fi change, coming out of sleep, client update, CPU suspension — is enough to expose your real IP to all applications and sites currently in use. On a long download or a streaming session, the exposure can last several minutes before the VPN client automatically reconnects.

The simple test, and the one we apply systematically in internal audits. Start a long download in the background: the Ubuntu LTS ISO (4 GB) is perfect for this, or any legal Linux distribution torrent. Verify the speed is stable. Then, either click "Disconnect" abruptly in the VPN client, or kill the client process via Task Manager (Ctrl+Shift+Esc on Windows, Activity Monitor on macOS, killall on Linux). The download must stop dead within a second.

If it continues, your kill switch isn't active. Check the option under the client's advanced settings (sometimes called "Network Lock", "Internet Kill Switch", or "App Kill Switch"). On some clients, two levels exist: system kill switch (cuts everything) or per-app kill switch (cuts only listed apps). For strict privacy audits, enable the system level.

Secondary test — often overlooked but critical: behaviour at machine startup. Does your VPN reconnect before the browser sends its first background requests? If not, the exposure window between OS boot and VPN activation can reveal your IP to the trackers that auto-load (Google Analytics on bookmarked tabs, Facebook Pixel on news sites, push notifications from connected services). Fix: enable "Launch at startup" + "Auto-connect on launch" + "Block traffic until VPN is connected" in the client. Also disable browser session restore if it opens sensitive tabs.

Test 5 — Real speed: what a VPN actually costs in performance

A well-configured VPN on a modern protocol typically loses 5 to 15% of throughput on a geographically nearby server, adding 10 to 40 ms of latency depending on physical distance to the server. Beyond those thresholds, either the server is congested at peak hours, the chosen protocol is obsolete (OpenVPN TCP in particular, which stacks two retransmission mechanisms and wrecks latency), or your VPN is technically below the 2026 market standard.

Correct measurement methodology matters as much as the raw figures. Use our Speed Test tool in a reproducible sequence. First pass without VPN: three consecutive measurements 30 seconds apart, take the median for download, upload, and latency. Note the figures. Second pass with VPN active on the nearest server (London from the UK, New York from the US East Coast, etc.): three consecutive measurements under the same conditions, median. Calculate the percentage loss: (speed without VPN − speed with VPN) / speed without VPN × 100.

Alert thresholds. If loss > 30% of throughput on a geographically local server, your VPN server is probably saturated: switch servers (good clients list load as a percentage) or change protocol — force WireGuard or its proprietary derivative (NordLynx for NordVPN, Lightway for ExpressVPN), which are significantly more efficient than OpenVPN in 2026. If added latency > 80 ms on a local server, that's abnormal — latency on a fibre connection to a domestic server should stay under 30 ms added.

Useful complementary test: also measure speed on a distant server (US East, Japan) to anticipate geo-unblocked streaming use. Loss there is legitimately higher (40–60%) due to physical distance, but must remain stable and reproducible. For protocol-by-protocol benchmark expectations and the full procedure, see our VPN speed test guide, which documents the method across 30 days of continuous use.

Test 6 — Platform geolocation (and why your VPN "doesn't work" on Netflix)

This is the test that separates a VPN that "technically works" from one that "works in practice". You can have a perfectly masked US IP, clean US DNS, zero WebRTC leak, and still see Netflix's "streaming error M7111-5059" with the message "you seem to be using an unblocker or proxy". Why? Because Netflix, Disney+, BBC iPlayer, and Hulu don't simply read the geographic IP: they cross-reference it against a database of IP ranges flagged as "datacenter" maintained by their anti-VPN teams, and they check behavioural signals (consistency between system language / browser language / OS timezone, unexpected latency).

The test: open a geo-restricted platform from a VPN server in the target country. Netflix US from a US VPN server: the catalogue must show US-exclusive titles ("Seinfeld", "It's Always Sunny in Philadelphia", HBO-licensed US content) and trailers in English with no French subtitles by default. BBC iPlayer from a UK VPN server: the homepage must load without "BBC iPlayer only works in the UK", and at least one episode must start. Disney+ Japan from a Japanese VPN server: the catalogue must show content in Japanese exclusive to the JP market.

If the "proxy" screen appears, two possible causes. Either the VPN server's IP pool is entirely flagged as datacenter by the platform — the case for most free VPN servers and many budget ones. Or the server hasn't been optimised for streaming by the provider — some VPNs offer dedicated "streaming-optimised" or "SmartPlay" servers designed to bypass these detections.

To validate streaming coverage on the platforms you actually use, run our geo-blocking test, which checks accessibility of Netflix US/UK/JP, BBC iPlayer, Disney+ US/JP, Max, and others in one pass. If a VPN fails on the platform you need, it fails for your use case — regardless of passing the other 8 tests. For methodological detail and NordVPN unblocking benchmarks versus alternatives, see our NordVPN review based on 8 months of continuous testing.

Test 7 — Logging policy and provider jurisdiction

This is the step you can't test technically yourself, but can verify indirectly through trusted third parties and a bit of research. A VPN that claims "no-logs" without a published public audit is just a marketing promise — not a technical proof that holds up to a legal injunction.

Look on the VPN's site for mention of a recent independent audit by a recognised firm. Names to look for: PwC, Deloitte, KPMG, Cure53, Securitum, VerSprite. The date matters as much as the auditor: an audit from 2019 says nothing about 2026 policy. NordVPN has published multiple PwC audits (2018, 2020, 2022) and Deloitte audits (2023, 2024). ExpressVPN was audited by KPMG in 2022 and re-audited by Cure53 in 2024. Mullvad has a series of annual Cure53 audits since 2020. ProtonVPN was audited by Securitum in 2023.

Also check the jurisdiction of the provider's registered headquarters. A VPN based in Panama (NordVPN), the British Virgin Islands (ExpressVPN), Switzerland (ProtonVPN), or Romania (CyberGhost) is not subject to the same data retention obligations as one based in the United States (a Five Eyes member, intelligence-sharing jurisdiction), the United Kingdom (Five Eyes; Investigatory Powers Act 2016 with active state surveillance obligations), or Australia (Five Eyes; Technical Assistance and Access Act). This doesn't guarantee they won't log in practice, but it reduces the legal pressure that could compel them to.

For further cross-referencing, check the independent recommendations of PrivacyGuides, the community reference site that regularly audits providers and publishes its minimalist list. They only include VPNs that meet criteria around transparency, independent auditing, and favourable jurisdiction.

Test 8 — Browser fingerprinting (what the VPN doesn't erase)

This is the test that explains why a perfectly configured VPN doesn't make you anonymous. Browser fingerprinting is the collection of unique signals your browser sends to every site, completely independently of your IP. Precise user-agent, system language, browser language, timezone, screen resolution, colour depth, installed fonts, installed plugins, Canvas rendering, WebGL rendering, AudioContext fingerprint, extension list hash. Combined, these signals are sufficient to identify your browser quasi-uniquely among millions — even if you change IP every day.

The test: run AmIUnique or EFF Cover Your Tracks without VPN first, then with VPN active. Compare. If your fingerprint is marked "unique" or "almost unique" with a score of several million bits of entropy, your browser is fingerprintable regardless of the VPN. The VPN's IP masking does nothing against this tracking vector.

Practical solutions. First, use Firefox with resistance mode: about:config, set privacy.resistFingerprinting to true. This forces standardised values (resolution, fonts, UTC timezone) that make your browser indistinguishable from other Firefox instances in resistance mode. Slight UX friction (timezone sometimes displayed incorrectly, standardised screen size) but a massive privacy gain. Second, Tor Browser: the most complete implementation of fingerprinting resistance, by design. If your threat model justifies Tor over VPN, this is the tool. Third, Brave offers native fingerprinting protection ("Shields" → "Fingerprinting" → "Block") that randomises signals each session.

The VPN alone doesn't solve this problem — and that's important to understand. If your goal is simply to mask your IP from your ISP and websites for everyday private use, a VPN that passes the first 7 tests is sufficient. If your goal is strict anonymity (journalist, protected source, sensitive research), you need to stack VPN + hardened browser + full OPSEC. That's the nuance no VPN marketing ever states clearly.

Test 9 — Combined real-world test (the one that reveals everything)

The first eight tests validate each dimension in isolation in a static environment: one test page, one measurement, one tick. That's necessary but not sufficient. Test 9 reproduces a real usage scenario over 10 continuous minutes to verify that protection holds over time. It's the most revealing test, and the one that separates two VPNs that look equivalent on paper.

The protocol. Within the same 10-minute window: (1) start HD streaming on a geo-restricted platform that requires your VPN — Netflix US from a US server, BBC iPlayer from a UK server; (2) open three sites you normally use in separate tabs (news, search, e-commerce) and browse normally; (3) start a long download in the background (Linux ISO 4 GB, or an accumulation of legal torrent files). Throughout the 10 minutes, keep our DNS leak test tool open in a tab and reload it every 2–3 minutes to verify no leak appears over time.

What this test reveals. First, tunnel stability: a budget VPN can switch servers mid-session (IP pool rotation on the provider side), which can briefly expose your real IP if the kill switch doesn't react fast enough. Second, behaviour under load: the combination of HD streaming + downloading + browsing can saturate an undersized VPN server, degrade speed non-linearly, or even force a disconnection. Third, kill switch in real time: it must fire on an abrupt disconnection (test 4) but also stay silent during normal use — an overly aggressive kill switch that fires every 30 seconds is unmanageable day-to-day.

Success criteria. No leak detected on successive tool refreshes. Stable streaming without abnormal buffering. Fluid browsing. Download maintaining consistent speed with test 5 results. If any of these points break down, the VPN isn't suited for combined privacy + streaming use — which is precisely what most people do in practice.

Of the ten or so VPNs tested internally in spring 2026, only NordVPN, ExpressVPN, Surfshark, ProtonVPN, and Mullvad pass this combined test reproducibly. Free VPNs almost all fail the speed + stability criterion before the 5-minute mark.

Summary — your 9-test audit checklist

To miss nothing in operational mode, here's the sequence in optimal methodological order. Each test must return a result that meets the 2026 standard; otherwise the VPN isn't suited for serious privacy or demanding multimedia use. The sequence is ordered from fastest to slowest to optimise time: if a test fails early, there's no point continuing with that VPN.

Renew this full audit after every major update: Windows 11 semi-annual feature updates, annual macOS releases, Firefox and Chrome major versions, and of course after every VPN client update. Once per quarter is sufficient for non-sensitive personal use. Monthly for journalism or research. Our published testing methodology details the exact sequence we apply to the VPNs we review internally.

Key takeaways

A VPN that passes all nine tests protects you against common leaks (IP, DNS, WebRTC, IPv6), covers real-world usage scenarios (streaming, browsing, downloading), and reasonably resists platform-side profiling. That's the minimum standard for a privacy-conscious user in 2026, and it broadly describes the three or four market leaders — NordVPN, ExpressVPN, Surfshark, complemented by Mullvad or ProtonVPN for more privacy-focused use cases.

Free VPNs rarely meet this standard, and neither do the VPNs you can't verify quickly with 3 fast tests — the gap between a 3-test audit and a 9-test audit is exactly what separates "seems to work" from "I know it's doing its job". If you're operating in journalistic anonymity or whistleblower mode, you'll need to go further than these 9 tests — Tor over VPN, a dedicated Linux or Tails machine, full OPSEC over time. That's no longer a VPN audit topic; it's OPSEC, beyond the scope of this guide.

For the vast majority of everyday use cases — daily privacy, ISP data collection avoidance, geo-unblocked streaming, public Wi-Fi security — the nine checks above are more than sufficient. Once per quarter, it takes about twenty minutes once the routine is established, and it's absolutely worth it to confirm your privacy tool is actually doing its job beyond the marketing.

Completing your security stack: password manager

A VPN encrypts your network traffic, but doesn't protect your passwords once they've been entered on a compromised site or reused across services. NordPass logically completes the defensive stack: 256-bit XChaCha20 encryption, Cure53 2024 audit, cross-device sync, free plan to get started without commitment. Premium at $1.69/month on a 2-year commitment. It's a tool separate from the VPN, complementary — not a replacement.

Article published on 29 May 2026. Methodology: audit applied to 10 market VPNs (NordVPN, ExpressVPN, Surfshark, ProtonVPN, Mullvad, CyberGhost, PIA, and 4 free VPNs) in a controlled environment — Firefox 125 + Chrome 124 + Brave 1.66, Ubuntu 24.04 LTS + Windows 11 24H2 + macOS 14.5, 1 Gbps fibre from London, measurements over 30 days of continuous use March–May 2026. Logs, screenshots, and raw measurements kept in internal archive, available on editorial request via contact.