Complete VPN security audit: 9 tests to verify your protection

Turning a VPN on is easy. Checking that it really does what it promises is another matter. Most users click "Connect", see a green checkmark, and call it done. The client shows a foreign IP, so everything must be fine. But that green light tells you nothing about DNS queries leaving in the clear to your ISP. It says nothing about the real IP that WebRTC reveals to any site that queries the browser. And it hides 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. After that it runs in 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. It's also 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 mostly stopped being the weak link since 2018. The weak link today is everything that slips past the tunnel without your knowledge.

Four flaws cause most broken VPN configurations. First, silent DNS leaks: your OS keeps resolving domain names through your ISP's DNS server. That server 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 grabs your local and real public IP despite the active VPN. This is documented in RFC 8826 on WebRTC security considerations. It is the de-anonymisation vector most used by behavioural marketing networks.

Third, unmanaged IPv6: your ISP deploys IPv6 natively (BT, Sky, Virgin Media in the UK; Comcast, Verizon in the US), but your VPN only tunnels IPv4. 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. This can last 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. This works only if they set up the tunnel correctly, handle client-side leaks, and honour their logging policy. The tests below are there to check those three technical conditions.

Test 1 - Is your public IP actually masked?

This is the most basic test. It catches the most crudely broken configurations in under 30 seconds. Open our My IP tool without the VPN first. Note the IPv4 address shown, the IPv6 if present, and - most of all - 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 nearby server to keep test latency low. Reload the page. The IPv4 must be completely different. The shown 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, there are two likely causes. Either the VPN client isn't really connected (check the interface status), or your corporate network routes traffic through a proxy that overrides the VPN. A rarer case happens with some badly set up split-tunnel configurations. The client leaves the browser in the clear while it tunnels 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) points to two things. Either a poorly referenced server in the MaxMind GeoIP2 or IP2Location databases, or a transit route that exits in Germany despite the Dutch announcement. This isn't critical for privacy. But it matters when you target 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. Here is 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 set when you joined the Wi-Fi. Your ISP therefore sees your domain history, indexed in order and timestamped to the second. No visible signal shows on your VPN client.

This is the most frequent and least visible leak, so it matters a lot. The quick test: visit dnsleaktest.com with the VPN active. Click "Extended Test" (never the "Standard Test", which is not enough) 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.

For a second check, use our internal DNS leak tool. It combines DNS, WebRTC, and IPv6 detection in a single pass. It's the fastest way to confirm in 30 seconds that the three main leak types are neutralised. You may also want 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. For that, see our complete DNS leak test guide, which covers every fix in detail.

On good paid VPNs, this test passes with no setup. 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, which guarantees a leak.

Test 3 - WebRTC leaks: the browser trap

WebRTC is built for peer-to-peer communication in the browser - Google Meet video calls, real-time file sharing, online gaming. To work, it tries to discover all IP addresses on your machine: local IP (192.168.x.x), public IPv4, public IPv6, STUN and TURN candidates. This includes 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. It needs no user interaction and no permission.

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, and DNS passes. But WebRTC quietly gives away your real IP to any site that queries the browser. Ad networks and fraud detection platforms use it heavily.

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

Here are the fixes, from most to least effective. 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. It 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 cuts your internet connection automatically if the VPN tunnel drops. Without it, a one-second disconnection is enough to expose your real IP to all apps and sites in use. The trigger can be a Wi-Fi change, coming out of sleep, a client update, or CPU suspension. On a long download or a streaming session, the exposure can last several minutes before the VPN client reconnects on its own.

Here is the simple test, the one we apply on every internal audit. Start a long download in the background. The Ubuntu LTS ISO (4 GB) is perfect for this, or any legal Linux distribution torrent. Check that 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 keeps going, 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"). Some clients have two levels: a system kill switch (cuts everything) or a per-app kill switch (cuts only listed apps). For strict privacy audits, enable the system level.

There is a second test, often missed but critical: behaviour at machine startup. Does your VPN reconnect before the browser sends its first background requests? If not, the gap between OS boot and VPN activation can reveal your IP to trackers that auto-load. These include Google Analytics on bookmarked tabs, Facebook Pixel on news sites, and push notifications from connected services. The 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 usually loses 5 to 15% of throughput on a nearby server. It adds 10 to 40 ms of latency, depending on physical distance to the server. Past those thresholds, one of three things is happening. The server is congested at peak hours, the chosen protocol is outdated (OpenVPN TCP in particular, which stacks two retransmission mechanisms and wrecks latency), or your VPN sits below the 2026 market standard.

The right measurement method matters as much as the raw figures. Use our Speed Test tool in a sequence you can repeat. First pass without VPN: take three measurements 30 seconds apart, then 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 measurements under the same conditions, median. Calculate the percentage loss: (speed without VPN − speed with VPN) / speed without VPN × 100.

Here are the alert thresholds. If loss > 30% of throughput on a 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). They are far 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.

One more useful test: also measure speed on a distant server (US East, Japan) to plan for geo-unblocked streaming use. Loss there is fairly higher (40–60%) due to physical distance. But it must stay stable and repeatable. For protocol-by-protocol benchmark expectations and the full procedure, see our VPN speed test guide, which documents the measurement method step by step.

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, and 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? Netflix, Disney+, BBC iPlayer, and Hulu don't simply read the geographic IP. They cross-check it against a database of IP ranges flagged as "datacenter" kept by their anti-VPN teams. They also check behavioural signals: whether the system language, browser language, and OS timezone match, plus any 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, there are two likely causes. Either the platform has flagged the whole VPN server IP pool as datacenter - the case for most free VPN servers and many budget ones. Or the provider hasn't optimised the server for streaming. Some VPNs offer dedicated "streaming-optimised" or "SmartPlay" servers built to bypass these detections.

To check streaming coverage on the platforms you actually use, run our geo-blocking test. It checks access to 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, even if it passes the other 8 tests. For methodological detail and NordVPN unblocking benchmarks versus alternatives, see our NordVPN review.

Test 7 - Logging policy and provider jurisdiction

This is the step you can't test technically yourself. But you can verify it 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. It's not technical proof that holds up to a legal injunction.

Look on the VPN's site for 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 several 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. Some VPNs are based in Panama (NordVPN), the British Virgin Islands (ExpressVPN), Switzerland (ProtonVPN), or Romania (CyberGhost). They don't face the same data retention rules 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 lowers the legal pressure that could force them to.

For more cross-checking, see the independent picks 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 set of unique signals your browser sends to every site, fully independent of your IP. These include the precise user-agent, system language, browser language, timezone, screen resolution, colour depth, installed fonts, installed plugins, Canvas rendering, WebGL rendering, AudioContext fingerprint, and extension list hash. Together, these signals can identify your browser almost 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 them. 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.

Here are practical fixes. First, use Firefox with resistance mode: about:config, set privacy.resistFingerprinting to true. This forces standardised values (resolution, fonts, UTC timezone). They make your browser look like other Firefox instances in resistance mode. There is slight UX friction (timezone sometimes shown wrong, standardised screen size), but a massive privacy gain. Second, Tor Browser: the most complete 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. Say your goal is simply to mask your IP from your ISP and websites for everyday private use. Then a VPN that passes the first 7 tests is enough. 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 check each dimension on its own in a static setting: one test page, one measurement, one tick. That's needed but not enough. Test 9 reproduces a real usage scenario over 10 continuous minutes to check that protection holds over time. It's the most revealing test, and the one that separates two VPNs that look the same on paper.

Here is 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 a batch of legal torrent files). Throughout the 10 minutes, keep our DNS leak test tool open in a tab. Reload it every 2–3 minutes to check that no leak appears over time.

Here is what this test reveals. First, tunnel stability: a budget VPN can switch servers mid-session (IP pool rotation on the provider side). This can briefly expose your real IP if the kill switch doesn't react fast enough. Second, behaviour under load: HD streaming + downloading + browsing together can saturate an undersized VPN server, degrade speed unevenly, 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 unworkable day-to-day.

Here are the success criteria. No leak detected on successive tool refreshes. Stable streaming with no abnormal buffering. Smooth browsing. The download holds a consistent speed in line with test 5 results. If any of these points break down, the VPN isn't suited for combined privacy + streaming use, which is exactly 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 day-to-day use, here's the sequence in the best order. Each test must return a result that meets the 2026 standard. If not, the VPN isn't suited for serious privacy or demanding multimedia use. The sequence runs from fastest to slowest to save time. If a test fails early, there's no point continuing with that VPN.

Run this full audit again 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 enough for non-sensitive personal use. 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. It broadly describes the three or four market leaders - NordVPN, ExpressVPN, Surfshark, with Mullvad or ProtonVPN added for more privacy-focused use cases.

Free VPNs rarely meet this standard. 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 operate 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 most everyday use cases - daily privacy, avoiding ISP data collection, geo-unblocked streaming, public Wi-Fi security - the nine checks above are more than enough. Once the routine is set, it takes about twenty minutes per quarter. And it's well worth it to confirm your privacy tool is really doing its job beyond the marketing.

Completing your security stack: password manager

A VPN encrypts your network traffic. But it doesn't protect your passwords once you enter them on a compromised site or reuse them across services. NordPass rounds out the defensive stack: 256-bit XChaCha20 encryption, Cure53 2024 audit, cross-device sync, and a free plan to start without commitment. Premium is $1.69/month on a 2-year commitment. It's a tool separate from the VPN, a complement - not a replacement.

Article published on 29 May 2026, updated on 13 June 2026. This guide describes an audit protocol you run yourself against your VPN - it is not the write-up of a private test bench. The thresholds quoted (5–15% throughput loss, 10–40 ms latency, alerts beyond 30%/80 ms) are general technical reference points derived from how the protocols are documented to behave, not proprietary measurements. The point about free VPNs draws on the public research cited (ACM IMC 2016 study of 283 apps). Affiliate disclosure: this site earns a commission if you subscribe via the NordVPN links - this does not influence the method described.