Verify your VPN actually works: 5-minute quick check (2026)

The green icon in the corner of your VPN application means one thing only: the software client is connected to the VPN server. It doesn't say your browser goes through the tunnel. It doesn't say your DNS queries are encrypted. It doesn't say WebRTC isn't leaking your real IP via JavaScript. It doesn't say IPv6 isn't bypassing the tunnel directly to your ISP. Here's the check-list to really verify in 2026 - five minutes, five tests, and you know exactly where you stand. It's the express complement to our complete VPN audit in 7 steps for routine verifications.

Test #1 - Did your public IP actually change?

How to check: open the My IP tool without VPN and note your IP and ISP. Activate VPN, reload. The IP must be completely different and the ISP must switch to a datacenter name (Tefincom, M247, Tata Communications). If the IP shows the same residential provider, the VPN tunnel is not working - restart the client, change server, and retest.

The fastest and most visible test. Without VPN, open the My IP tool and note the displayed address and ISP name (Orange, Free, SFR, Bouygues if in France). To understand what your public address actually reveals beyond the basic ISP label, see our deep-dive on what your IP address says about you. Activate VPN, reload the page. The IP must be completely different: not just one last digit changed but a fully new range. The ISP must also change - it must show a datacenter host name (Tefincom for NordVPN, Tata Communications, M247, Datacamp, OVH) and no longer your residential provider.

If the IP hasn't moved: your VPN isn't actually connected, or it's routing traffic without masking IP (rare case linked to corporate proxy neutralizing VPN). Solutions by action order: restart VPN client, change server in the list, retry. If nothing changes even after 3 tries, your VPN simply isn't working - uninstall, reinstall the latest version, or contact the provider's technical support. No other test makes sense as long as this test #1 fails.

Test #2 - Detected country matches selected server

You connected to a "Netherlands"-labeled server in your VPN client. But the site you're browsing detects your geolocation as "Germany" or another country. Not necessarily a panic - IP geolocation databases (MaxMind GeoIP2, IP2Location) are sometimes imprecise to neighboring country, particularly at European borders. But if you target a country-specific streaming catalog, verifying on the final service is necessary.

For Netflix: go to netflix.com without logging in (or with a clean account). The homepage catalog shows content from the country detected by Netflix. If you target Netflix US and see "The Office US", "Brooklyn Nine-Nine", "Parks and Recreation" on the front page, that's good. If you see French or European productions, the detected country isn't what you targeted - change VPN server, clear Netflix cookies, retry. For methodology detail, see our Netflix US from France guide.

For BBC iPlayer, France TV, RTVE, NHK: same principle. A connection bouncing to the service's "international" version signals that your VPN exits in a country not covered by rights - proof that detected geolocation isn't the expected one. Worth noting: even with a perfect VPN exit, your radio-layer hardware fingerprint can give you away on captive networks - see our MAC spoofing on public Wi-Fi walkthrough for the identifier the VPN doesn't mask.

Test #3 - Is there a WebRTC leak exposing your real IP?

WebRTC (built into Chrome, Firefox, Edge, Safari) can expose your real IP via JavaScript even with an active VPN. Run our DNS Leak Test tool: if a public IP other than the VPN exit appears, it's a confirmed WebRTC leak. Fix: enable "Block WebRTC" in your VPN settings, or install the official VPN browser extension. This is the most frequent silent leak in 2026.

This is trap #1 and the most critical leak in 2026. WebRTC is a real-time communication API built into all modern browsers (Chrome, Firefox, Safari, Edge). It tries to discover your real IP via STUN servers to enable browser P2P communication (Discord video calls, Google Meet screen sharing, etc.). If your VPN doesn't explicitly block it, a malicious site can read your real IP via JavaScript in under 100 ms, with no visible user-side signal.

Run our DNS Leak Test tool which probes WebRTC in your browser and lists all detected candidate IPs. Three possible interpretations: (1) Local IP (192.168.x.x, 10.x.x.x, 172.16-31.x.x) - normal, that's your internal LAN/Wi-Fi network, reveals nothing external; (2) Public IP matching your VPN exit noted in test #1 - good sign, the VPN tunnels WebRTC correctly; (3) Public IP not matching your VPN - confirmed WebRTC leak, immediate action required.

Solutions by effectiveness: look in your VPN client for a "Block WebRTC" or "WebRTC Leak Protection" option (NordVPN has had it since 2022, ExpressVPN too), install the VPN's official browser extension that natively disables WebRTC, or as last resort manually disable WebRTC in Firefox about:config (variable media.peerconnection.enabled to false) or via uBlock Origin on Chrome (Settings → Privacy → prevent WebRTC from revealing local IP).

Test #4 - DNS resolved via VPN, not via your ISP

DNS queries must go through the VPN tunnel. Otherwise your ISP continues to see the exact list of domains you visit - logs retained 12 months in France per Hadopi 2.0, accessible on judicial request. This is the typical VPN privacy use case that becomes ironic in case of DNS leak.

Quick test: open dnsleaktest.com and launch an "Extended Test" (not insufficient "Standard Test" - it checks ~5 resolvers vs ~30 for Extended). Wait 10-20 seconds for results. The tool lists DNS servers that actually resolved the test queries. Success criterion: all responding DNS servers must belong to the VPN (NordVPN uses its own internal resolvers 103.86.96.X) or to a recognized public resolver (Cloudflare 1.1.1.1, Quad9 9.9.9.9, Google 8.8.8.8). No response from your ISP: that's the absolute criterion. If you see 80.10.246.X (Orange), 212.27.40.X (Free), 109.0.66.X (SFR), 194.158.122.X (Bouygues), it's a confirmed leak.

For technical detail of possible causes and OS-specific fixes (Windows SMHNR to disable, browser DoH to disable, IPv6 to tunnel), see our complete DNS leak test guide.

Test #5 - Is there an IPv6 leak bypassing your VPN tunnel?

Many VPNs only route IPv4 - IPv6 exits directly to your ISP without encryption. Visit test-ipv6.com: "No IPv6 detected" means safe. If an IPv6 address matching your ISP's prefix appears, you have a confirmed leak. Fix: enable "Block IPv6" or "Disable IPv6" in your VPN client settings. NordVPN supports native IPv6 tunneling since 2024.

IPv6 is the most forgotten trap of superficial audits. Many VPNs only route IPv4 in their encrypted tunnel; IPv6 traffic exits directly to your ISP without encapsulation. On sites supporting IPv6 (Google, Facebook, Cloudflare host much of the internet in IPv4+IPv6 dual stack), your real IPv6 remains visible to visited sites while your IPv4 is hidden by the VPN. The site therefore knows your real geolocation despite active VPN.

Go to test-ipv6.com. Two possible outcomes: "No IPv6 detected" means perfect - IPv6 disabled or efficiently blocked by the VPN. Otherwise "Your IPv6 address: 2001:..." is displayed: verify that this address corresponds to the VPN server's IPv6 prefix (different prefix from your residential ISP) and not your real IPv6 prefix. If it matches your ISP (Orange/Free/Bouygues have their own IPv6 ranges), it's a confirmed IPv6 leak.

Solutions: if your VPN doesn't natively manage IPv6 and leaks, either enable the "Disable IPv6" or "Block IPv6" option in the VPN client, or disable IPv6 in your network card system settings (Windows Settings → Network → Adapter → Properties → uncheck IPv6). Technically ugly (you give up IPv6 advantages) but works to block the leak. NordVPN supports native IPv6 tunneling since 2024, ExpressVPN blocks IPv6 by default.

Advanced tests 2026 - beyond the 5 fundamentals

For users wanting to go further than the quick check-list, here are four complementary tests to execute once per quarter or after any major network infrastructure change (ISP switch, IPv6 dual-stack rollout, router firmware update). These tests require 10-15 additional minutes but detect residual leaks invisible to the quick check.

WebRTC leak - command-line verification

Beyond our browser tool, reliable command-line verification confirms absence of STUN leak at system level. On Linux or macOS, install a WebRTC test client (npm install -g webrtc-leak-test) then execute webrtc-leak-test --stun stun.l.google.com:19302. The command displays candidate IPs reported by WebRTC. Interpretation: no public IP outside the VPN exit must appear. On Windows, browserleaks.com/webrtc is the most precise browser equivalent - it lists host, srflx and relay candidate IPs with their ASN prefix, allowing immediate source tracing. Note: with a properly configured kill switch (see VPN kill switch explained), a WebRTC leak is technically impossible because no traffic exits the tunnel - a useful complementary check.

IPv6 leak - per-OS fix

If test-ipv6.com reveals your ISP prefix, the fix depends on the system:

• Windows 10/11: Settings → Network & Internet → Wi-Fi/Ethernet → click connection → IP configuration → Edit → disable IPv6. PowerShell admin alternative: Disable-NetAdapterBinding -Name "*" -ComponentID "ms_tcpip6". Verify with Get-NetAdapterBinding -ComponentID ms_tcpip6 that the bind is disabled on all interfaces.
• macOS Sonoma/Sequoia: Terminal → networksetup -setv6off Wi-Fi (replace Wi-Fi with the exact interface name listed via networksetup -listallnetworkservices). To restore: networksetup -setv6automatic Wi-Fi.
• Linux Ubuntu/Debian: edit /etc/sysctl.conf, add net.ipv6.conf.all.disable_ipv6 = 1 then sudo sysctl -p. Disablement is persistent after reboot.
• iOS/Android: no native IPv6 disablement without rooting. Solution: use a VPN client that explicitly blocks IPv6 (NordVPN, Mullvad, ProtonVPN handle this case since 2024).

Browser fingerprinting - VPN/fingerprint correlation

Even with active VPN and IP/DNS/WebRTC leaks blocked, your browser exposes a unique fingerprint (timezone, language, installed fonts, screen resolution, plugins) that can serve cross-session tracking. Test on amiunique.org. If your fingerprint is reported as "unique among N visitors", a site can recognize you despite changed IP. Mitigation: use browser private mode alongside VPN, or a privacy-oriented browser (Brave, LibreWolf) that randomizes some fingerprint values. Tor Browser remains the absolute reference for neutralizing fingerprinting - see our Tor vs VPN comparison for the right choice by use case.

DPI bypass - does your ISP inspect your traffic?

Deep Packet Inspection (DPI) allows an ISP or corporate network to detect VPN traffic by recognizable pattern (OpenVPN handshake, WireGuard signature) even encrypted, and to throttle or block it. Simple test: measure your speed via our speed test tool without VPN, then with VPN standard protocol (OpenVPN UDP), then with obfuscated protocol (NordVPN Obfuscated Servers, Mullvad Bridges, or WireGuard on port 443). If speed drops only with standard OpenVPN but stays correct with obfuscated protocol, your ISP likely does DPI on classic VPN ports. Durable solution: force the VPN client on an obfuscated protocol or stealth mode - particularly useful on corporate networks, hotels, and aggressive ISPs.

VPN verification tools 2026 - quick comparison

Not all tools are equal. Here's a commented selection of the most accurate free tools for checking a VPN.

Practical recommendation: for routine check, chain our internal tool (30 s) + dnsleaktest Extended (20 s) + test-ipv6 (15 s) covers the large majority of leaks. For an in-depth check, add browserleaks for fingerprinting and ipx.ac for ASN confirmation. See our complete test methodology for the step-by-step protocol.

Summary - the practical 5-minute check-list

To quickly apply the check without missing a test, here's the exact sequence to chain in order. Each test takes 30-60 seconds cumulatively.

If you pass all 5 tests, your VPN actually works - not just in its taskbar icon. If even one fails, identify cause and apply appropriate fix before continuing sensitive use (banking, confidential accounts, political browsing). Redo the full sequence after every major update of system, browser, or VPN client.

Difference with the complete 7-step audit

This 5-minute check-list is a quick routine diagnosis, to execute regularly to confirm no silent regression occurred. It doesn't cover all aspects of in-depth verification: kill switch (step 5 of complete audit), speed loss measurement (step 6), and no-log policy verification via independent audit (step 7) aren't included here for speed reasons.

For in-depth annual audit or in case of serious doubt on the used VPN, switch to our complete VPN audit in 7 steps which includes all points. For routine verification (e.g., after Windows update, after installing a new browser, or quarterly), these 5 quick tests suffice largely.

What to remember

The VPN client's green icon is a software connection indicator, not effective protection. Five quick tests - public IP, country, WebRTC, DNS, IPv6 - suffice to confirm that your traffic, DNS, and browser APIs actually go through the encrypted tunnel, without silent bypass on browser or operating system side.

To redo after every update of OS (Windows, macOS), VPN (new client), or browser (Firefox 125 → 126 for example) - because silent regressions exist and no visible signal will tell you. If you seek deeper audit (kill switch, speed, logs), see our complete 7-step audit. For regular routine check, these five tests suffice largely and guarantee your privacy tool is doing its job.

Independent editorial assessment based on documented service capabilities, published independent audits and public benchmarks, with checks via standard tools (iperf3, dnsleaktest.com, browserleaks). Commercial links carry the rel="sponsored nofollow" attribute; an affiliate commission may apply at no extra cost to the reader and with no influence on the rating.