Practical guide

IP, DNS and WebRTC Leak Guide

A leak test is most useful when you know what each network path represents. This guide explains what the browser can observe, how to compare results and when a mismatch is expected rather than dangerous.

Updated: August 21, 2026

1. Establish a baseline

Before connecting a VPN or proxy, note your normal public IP country and ISP. Then connect the service, reload the test and run it again. The expected result is not always one particular country; it is consistency with the exit location and DNS behavior promised by your provider.

Run the comparison in a fresh browser window and wait for the full scan. Browser extensions, secure DNS settings, corporate proxies and split-tunnel rules can change one layer without changing the others.

2. Interpret the HTTP public IP

The HTTP address is the source address seen by this server. With a full-tunnel VPN it normally belongs to the VPN exit network. A hosting or datacenter classification is common for commercial VPN exits and is not itself proof of abuse or poor quality.

IP geolocation is approximate. City-level labels can reflect an ISP registration office, an anycast location or an old database entry. Country and ASN are usually more useful than the displayed city when diagnosing routing.

3. Interpret WebRTC candidates

WebRTC uses ICE to find paths for real-time communication and STUN to discover addresses beyond local network address translation. Modern browsers often hide private addresses behind mDNS names, which is a privacy feature and not a leak.

A public WebRTC address that differs from the HTTP exit deserves attention. Repeat the test, verify that the address is public, and compare its ASN with your normal ISP. A mismatch can indicate split tunnelling, an extension-only proxy or a browser route that bypasses the VPN.

4. Interpret DNS resolver results

DNS resolvers translate hostnames into addresses. A VPN may use its own resolver, a public resolver, encrypted DNS selected by the browser, or a regional anycast service. Because of this, a resolver country different from the HTTP exit is evidence to investigate, not automatic proof of a leak.

A stronger warning is a resolver owned by your normal ISP when the VPN claims to tunnel all DNS. Check browser secure-DNS settings, operating-system DNS, router configuration and the VPN's DNS-leak protection. Repeat after clearing caches or reconnecting to a different exit.

5. Understand false positives

Corporate networks, content filters, mobile carriers, satellite links, virtual desktops and privacy relays often split traffic intentionally. Anycast may place one IP in several regions, while IP databases can disagree. Browser language and timezone also describe a device preference, not a network leak.

Treat the combined score as a checklist of observations. The individual IPs, network owners and resolver names are more actionable than the score alone.

6. Troubleshooting checklist

If an unexpected public address remains visible, disconnect and reconnect the VPN, disable extension-only proxies, confirm the browser is included in the tunnel and test another browser. If DNS is unexpected, turn off conflicting secure-DNS settings or choose the resolver recommended by the VPN provider.

  • Compare results before and after connecting the VPN.
  • Check whether the unexpected address belongs to your normal ISP.
  • Repeat with browser extensions disabled and in a private window.
  • Review split-tunnel, kill-switch and DNS-protection settings.
  • Do not publish screenshots containing your full IP address unless you understand the privacy impact.