What a VPN should hide
A VPN creates an encrypted tunnel between your device and the VPN server. Traffic exiting to the internet appears to originate from the VPN server's IP address, not your own. Done correctly, this hides three things from the destination server: your real IP address, your ISP's identity (derivable from the ASN assigned to your IP), and your approximate geographic location.
A VPN does not hide everything. Your browser fingerprint — the combination of screen resolution, installed fonts, canvas rendering, and dozens of other attributes — is unaffected by a VPN. Cookies and existing logged-in sessions persist through the tunnel. Tracking pixels and login state follow the user, not the IP. A VPN is a network-layer control; it does not protect against application-layer tracking.
Understanding this scope is important when evaluating whether a VPN is "working." The relevant question is: does the destination server see the VPN's IP instead of yours? Everything else requires different controls.
Types of leaks
Three distinct leak types are commonly encountered:
- IP leak — the VPN tunnel drops or fails to establish, and traffic is sent directly over the default network interface. The destination sees your real IP. This happens during VPN reconnections, on network changes (switching from Wi-Fi to mobile data), or when the VPN client crashes. A kill switch is the mitigation: block all traffic if the tunnel is not active.
- DNS leak — DNS queries bypass the VPN tunnel and are sent to the system resolver — typically your ISP's DNS server. Your browsing habits are exposed to your ISP even though payload traffic goes through the VPN. This is particularly common with split-tunnel configurations, where only some traffic is routed through the VPN.
- WebRTC leak — browsers implement WebRTC for peer-to-peer communication (video calls, file transfer). The WebRTC STUN protocol reveals local and public IP addresses as part of ICE candidate gathering, bypassing the VPN tunnel entirely. This is a browser-level bypass, not a VPN client failure. It can be mitigated by disabling WebRTC in browser settings or using a browser extension that restricts it.
How to detect an IP leak
The baseline test is straightforward: check your visible IP before enabling the VPN, enable the VPN, then check again. If the IP address is the same, the tunnel is not working. If it has changed but shows your ISP rather than the VPN provider's ASN, you may have a partial or split-tunnel configuration that is not routing all traffic.
Reading the IP enrichment output tells you more than just the address. The key fields to examine are:
- ASN and organization — should show the VPN provider, not your home ISP or mobile carrier.
- Network type classification — should show
vpnordatacenter, notresidentialorisp. A residential classification while connected to a VPN is a strong signal of a leak. - Geolocation — should match the VPN exit server's location, not your physical location.
Note that geolocation accuracy varies significantly. MaxMind and similar databases are accurate to the city level for most residential and datacenter IPs, but VPN exit nodes in unusual locations may show stale or coarse geolocation data. Treat geolocation as a supporting signal, not a definitive check.
How to detect a DNS leak
A DNS leak is invisible from the IP check alone. Your traffic IP may show the VPN, but DNS queries may still reach your ISP's resolver. The test requires querying a DNS server that logs and returns the resolver identity — several specialized test services exist for this purpose.
The mechanism behind DNS leaks is usually one of three causes: the OS resolver is configured separately from the VPN's DNS settings, the VPN client does not override DNS on the current network interface, or a split-tunnel configuration routes DNS queries outside the tunnel. On Windows, the OS may use Smart Multi-Homed Name Resolution (SMHNR) and send queries to all configured resolvers simultaneously, which bypasses the VPN's DNS.
A clean DNS test should show only the VPN provider's resolver or a third-party resolver (like Cloudflare 1.1.1.1) that you have explicitly configured, with no queries reaching your ISP. If your ISP appears in the results alongside or instead of the VPN resolver, you have a DNS leak.
What IP enrichment reveals
Even with a VPN active and no leak, the VPN exit IP carries information. IP enrichment databases classify IP ranges by network type and usage patterns. Common classifications include residential, ISP, datacenter, CDN, VPN, Tor exit, hosting, and mobile. VPN exit IPs are frequently already classified as VPN because VPN providers operate predictable IP ranges that researchers and threat intelligence services have catalogued.
This has practical implications. Many websites and services use IP classification to apply friction to VPN users — CAPTCHAs, additional verification steps, or outright blocks. If your VPN exit IP is classified as a known VPN range, destination services know you are using a VPN even if they cannot see your real IP. Some VPN providers rotate IPs or use residential proxy networks to avoid this, but these introduce their own trust and performance tradeoffs.
VPN provider IP ranges and reputation
Shared VPN exit IPs are a two-edged property. You benefit from anonymity in the crowd — your traffic is indistinguishable from other users on the same exit IP. But the IP also carries the history of every other user who has used it. If previous users triggered abuse reports, sent spam, or engaged in credential stuffing, the exit IP may be on blocklists. This causes legitimate requests to be blocked or challenged by destination services.
Dedicated IPs (offered by some VPN providers as an add-on) avoid shared reputation risk but are trivially linked to your account. The tradeoff is between reliability and anonymity. For corporate VPN use cases — remote access to internal systems — the reputation concern is usually secondary to performance and reliability. For privacy-sensitive use cases, shared IPs are generally preferable despite the reputation risk.
What to do if you have a leak
For an IP leak, the immediate fix is enabling the VPN client's kill switch. This blocks all non-tunnel traffic at the firewall level, ensuring that if the tunnel drops, the machine goes offline rather than routing traffic over the default interface. On Linux, this is typically implemented with iptables or nftables rules; on macOS and Windows, the VPN client handles it.
For a DNS leak, override the DNS resolver at the OS level to use one explicitly routed through the tunnel. Most modern VPN clients provide a "prevent DNS leaks" option that sets the DNS server and blocks DNS queries not going through the tunnel. On Linux with systemd-resolved, ensure the VPN's DNS settings are pushed and applied to the correct interface.
For WebRTC leaks, the fix is browser-level: disable WebRTC entirely in Firefox (about:config, set media.peerconnection.enabled to false), use an extension in Chrome, or accept that WebRTC-dependent features will not work. There is no VPN-side fix for WebRTC leaks because the browser bypasses the tunnel by design.