How to Test Your VPN Connection: Verify It's Actually Working
As a cybersecurity correspondent I treat VPNs not as magic boxes but as tools that must be tested. Vendors ask you to trust them; I advise you to verify. This guide walks through reproducible checks — IP leak, DNS leak, WebRTC, IPv6, kill‑switch behaviour and speed comparisons — so you can prove whether your VPN is doing its job.
Before you start: prerequisites and context
You’ll need: administrative access to the device you’re testing, the VPN client or manual configuration already applied, a modern browser (Chrome/Firefox/Edge), and a few web tools: ipleak.net, dnsleaktest.com, browserleaks.com/webrtc, and a speed test such as speedtest.net or fast.com. I also recommend having a terminal available for curl, dig/nslookup and traceroute when possible.
Critically: know whether your VPN supports IPv6. Many consumer VPNs only tunnel IPv4; if your ISP assigns IPv6 and the VPN ignores it, you will leak. Also note that past vendor failures and appliance vulnerabilities (for example CVE‑2019‑11510 in enterprise VPN appliances) demonstrate why independent audits matter — look for audits by firms such as Cure53 or Deloitte before treating vendor claims as definitive.
1) Check your public IP (baseline and while connected)
Start with a baseline: disconnect the VPN and visit a simple IP checker to record your real public IP. Use a terminal for repeatability: curl -s https://ifconfig.me or curl -s https://ipinfo.io/ip. Note the ISP and city returned by ipinfo; that’s your real-world fingerprint.
Reconnect the VPN to a known server location (e.g., Netherlands). Repeat the same command. The returned IP should be different and match the server location claimed by the VPN provider. If it doesn’t, you’ve already got a problem.
2) Perform an IP leak test
Open ipleak.net or ipleak.org in a browser while connected to the VPN. These sites enumerate the public IPv4 and IPv6 addresses visible to web servers. Critically examine all reported addresses: any appearance of your home ISP’s IP or local network IPs is a leak.
3) Test for DNS leaks
DNS leaks are common and subtle: even when your traffic is routed through the VPN, your system may still ask your ISP’s DNS servers who resolves example.com. Use dnsleaktest.com and dnsleak.com to run extended tests. They will list resolver IPs and associated ASNs — verify those resolvers belong to the VPN provider or a privacy‑minded third party (e.g., Cloudflare, Quad9), not your ISP.
For a terminal check use dig or nslookup to query an external resolver and compare. Example: dig +short txt ch whoami.akamai.net @resolver1.opendns.com will return the IP that resolver sees. If your resolver is your ISP while VPN is connected, you have a DNS leak.
4) Check WebRTC for browser IP leaks
WebRTC can expose local and public IPs directly to web pages even when a VPN is active, because it uses STUN servers and direct peer connectivity. Visit browserleaks.com/webrtc or ipleak.net to see WebRTC results. If any local network IPs or your real public IP appear, disable WebRTC in the browser or use a trusted extension until the VPN client provides proper mitigation.
5) Verify IPv6 handling
IPv6 leaks are frequent because many VPNs lack IPv6 routing. Use test-ipv6.com and ipleak.net to check for IPv6 exposure. If you see an IPv6 address from your ISP while VPN is active, either disable IPv6 on the system or use a VPN that explicitly supports IPv6. This is not optional if your ISP enables IPv6 by default.
6) Test the kill switch
A kill switch is a civil‑liberties feature: it prevents unencrypted or unproxied traffic when the VPN drops. To test it, start a continuous network action (large file download, ping to 8.8.8.8, or a long curl transfer). Then forcibly kill the VPN process or toggle the interface. If traffic continues after the VPN is down, the kill switch failed.
On Windows, disable the VPN service or close the client; on macOS, toggle the VPN in Network preferences; on Linux, bring the tun/tap interface down. Observe whether your public IP returns to the baseline or whether the transfer aborts. A correct kill switch should stop traffic immediately.
7) Speed tests: before and after
Measure performance using speedtest.net or fast.com. Run three tests without the VPN to establish a baseline, then three tests with the VPN connected to the same geographic region. Average the results. Expect a penalty — 10–40% is normal depending on distance and encryption — but anything that regularly exceeds a 60% drop suggests poor routing or overloaded servers.
If speeds are wildly inconsistent across sessions, run traceroute or mtr to inspect routing. High latency or excessive hops can indicate poor peering or traffic forced through distant gateways.
8) Additional checks and automation
Automate basic sanity checks with a simple script: curl to ifconfig.me for IP, dig to test DNS, and curl to a WebRTC test endpoint (or just open browser tests). Schedule this script to run on startup or on network changes. Automation helps detect intermittent leaks that manual tests can miss.
For shared devices, test both the system‑wide VPN and browser extension modes separately — browser extensions often only encrypt browser traffic and can mislead users into thinking the whole device is protected.
Interpreting results and remediation
If you find DNS, IP or WebRTC leaks: first update the VPN client to the latest version, because vendors patch issues. If the vendor’s client still leaks, either configure system DNS to trusted resolvers (Cloudflare 1.1.1.1, Quad9 9.9.9.9), disable IPv6, or move to a provider that documents protections and publishes independent audits. I am deeply skeptical of “trust us” claims; require transparency.
If the kill switch fails, stop using that setup for sensitive traffic. Either enable firewall rules that restrict outbound traffic to the VPN interface or use a different client that implements a kernel‑level kill switch rather than a userland watchdog.
Parting notes: continuous vigilance
VPN testing is not a one‑time activity. Browser updates, OS changes and policy shifts can introduce regressions. Re-run these tests whenever you switch servers, change clients, or update your operating system. Treat privacy as a rights issue: your digital anonymity is something to be defended actively.
If you want vendors to improve, demand independent audits and public disclosure. Look for providers that publish reports from firms like Cure53, and consider open protocols (WireGuard, OpenVPN) where the community can review code and configuration. Be particularly cautious with free VPNs that offer no audits or clear revenue model.
If you need help validating results, Compass Reviews regularly runs reproducible test procedures for major providers — including ExpressVPN, NordVPN, Proton VPN, Surfshark and Mullvad — and links to public audit reports where available. Contact our team for a deeper consultation.