How to Tell If Your VPN Is Actually Leaking

The five leak classes

Leaks are not one phenomenon. Each class has a different cause and a different fix, and a test page that reports pass or fail for all of them together hides which one you have.

IPv4 leaks are rare on a properly configured full-tunnel VPN, but occur with split tunnelling, where specific applications or destinations are deliberately routed outside the tunnel. If you configured split tunnelling and forgot, this is your leak.

IPv6 leaks are the most common by a wide margin. The tunnel carries IPv4, the ISP provides native IPv6, and every dual-stack destination is reached directly. Because Happy Eyeballs (RFC 8305) prefers IPv6, this affects most of your browsing rather than an edge case.

DNS leaks send name-resolution queries to a resolver outside the tunnel, exposing every domain you visit even when the connections themselves are tunnelled. On Windows, parallel multi-interface resolution causes this even when the tunnel resolver is configured correctly.

WebRTC leaks expose addresses through the browser's ICE candidate gathering. If a STUN request escapes the tunnel, a web page learns your real public address without any permission prompt.

Traffic leaks during state transitions are the fifth and least tested class: the seconds between the network coming back and the tunnel re-establishing, during which the operating system happily routes everything through the physical interface.

The complete test sequence

Run this with the VPN connected. Record every result. Any mismatch between what you expect and what returns is a leak, and the specific command that failed tells you which class.

The critical comparison is between your known VPN exit address, which the client displays, and each result below. Note that a passing IPv4 test tells you nothing about IPv6.

• Test 1 must return the VPN exit address, not your ISP-assigned one.
• Test 2 should fail with network unreachable, or return a VPN-owned IPv6 address. Anything else is a leak.
• Test 3 must return an address belonging to your VPN provider or a resolver you deliberately chose, not your ISP.
• Test 5 confirms the ownership question objectively rather than by geography, which can be misleading.

# 1. IPv4 exit address
curl -4 -s https://ifconfig.co; echo

# 2. IPv6 exit address (network unreachable here is a good result)
curl -6 -s https://ifconfig.co; echo

# 3. which resolver answered
dig +short whoami.akamai.net
dig +short TXT o-o.myaddr.l.google.com @ns1.google.com
nslookup whoami.akamai.net    # Windows equivalent

# 4. what the OS thinks the resolvers are
scutil --dns | grep nameserver          # macOS
resolvectl status | grep -A2 "DNS Serv" # Linux systemd
Get-DnsClientServerAddress -AddressFamily IPv4   # Windows

# 5. ASN of whatever address you saw
whois -h whois.cymru.com " -v $(curl -4 -s https://ifconfig.co)"

Reading the routing table

The routing table is the ground truth for where packets go. If the default route does not point at the tunnel interface, no amount of application configuration will keep traffic inside it.

On a full-tunnel VPN you should see the default route pointing at the tunnel device, often with the classic 0.0.0.0/1 and 128.0.0.0/1 pair that overrides the physical default without deleting it. Two separate half-routes covering the whole address space is a deliberate technique, not an anomaly.

Also check the IPv6 table separately. A machine with a valid IPv6 default route pointing at the physical interface while the IPv4 default points at the tunnel is the routing signature of the most common leak.

• ip route get 1.1.1.1 and Find-NetRoute show which interface a specific packet would actually use, which is more useful than reading the whole table.
• An IPv6 default route via fe80:: on the Wi-Fi interface while the tunnel is up means IPv6 is bypassing it.
• Routes for RFC 1918 ranges pointing at the physical interface are normal and desirable; that is local network access, not a leak.

# macOS / BSD
netstat -rn -f inet | head
netstat -rn -f inet6 | head
route -n get default

# Linux
ip route show
ip -6 route show
ip route get 1.1.1.1

# Windows
route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Format-Table ifIndex, NextHop, RouteMetric
Find-NetRoute -RemoteIPAddress 1.1.1.1

The reconnect window nobody tests

Almost every leak test is run on a stable connection, which is the condition under which leaks are least likely. The interesting case is the transition: waking from sleep, moving between Wi-Fi networks, a mobile handoff, or the VPN server dropping the session.

During that window, the physical interface comes up before the tunnel does. The operating system has a working default route through the ISP and applications with pending connections retry immediately. Background sync, email clients, and any open browser tab reconnecting will send traffic through the ISP for as long as the gap lasts, which ranges from under a second to more than a minute on a poor mobile connection.

Test it deliberately. Start a continuous check, then interrupt the network and watch the output. Anything that returns a non-VPN address during the gap is what would have leaked.

# run this, then toggle Wi-Fi off and on
while true; do printf "%s  %s\n" "$(date +%T)" "$(curl -4 -s --max-time 3 https://ifconfig.co)"; sleep 1; done

# packet-level: watch for anything leaving the physical interface
sudo tcpdump -n -i en0 'not host YOUR_VPN_SERVER_IP and not arp and not port 5353'

Kill switches: what they do and do not cover

A kill switch is a firewall rule set that blocks traffic when the tunnel is not established. Implementations differ enough that the term alone tells you very little.

An application-level kill switch terminates specific programs when the tunnel drops. It does nothing about the operating system's own traffic, other applications, or anything that starts while the tunnel is down. This is the weakest form and is common in consumer clients.

A system-level kill switch installs firewall rules that permit outbound traffic only on the tunnel interface plus a narrow exception for reaching the VPN server. This is what you want. On macOS it is implemented via the packet filter, on Windows via WFP filters, and on Linux typically via nftables or iptables rules.

Two questions determine whether yours is adequate. Does it apply at boot, before the VPN client starts, or only after the client has connected once? And does it block IPv6, or only IPv4? A kill switch that permits IPv6 while blocking IPv4 is worse than none, because it creates false confidence while leaving the most common leak path open.

You can verify both without trusting the client. Enable the kill switch, quit the VPN application entirely, and check whether you still have internet access. If pages load, the kill switch is application-scoped and does not survive the client not running.

Building a repeatable check

Testing once proves nothing about tomorrow. VPN clients rewrite network configuration on every connect, operating system updates reset adapter settings, and providers change server configurations without notice. A check you can run in one command is a check you will actually run.

Save the script below and run it whenever something feels wrong, and always after an OS update. It prints the four values that matter on one screen, so a leak is visible at a glance rather than requiring interpretation.

Two habits matter more than any tool. Always compare ASNs rather than cities, because a geographic match can be coincidental while an ASN match cannot. And always test IPv6 explicitly, because it is the leak class that most tools under-report and the one most likely to be silently exposing you.

#!/usr/bin/env bash
set -u
V4=$(curl -4 -s --max-time 5 https://ifconfig.co || echo "none")
V6=$(curl -6 -s --max-time 5 https://ifconfig.co || echo "none")
RES=$(dig +short whoami.akamai.net | tail -n1)
ASN=$(whois -h whois.cymru.com " -v $V4" 2>/dev/null | tail -n1)
printf "IPv4 exit : %s\nIPv6 exit : %s\nResolver  : %s\nExit ASN  : %s\n" "$V4" "$V6" "$RES" "$ASN"

Frequently asked