This page compares two signals that should line up when a VPN is doing what you expect: the IPv4 address my HTTPS handler sees on /api/ip, and the public server-reflexive (srflx)endpoints your browser learns while running a short WebRTC ICE gather against Google's public STUN pool (stun.l.google.com:19302by default). I added the dual check after a friend on a well-known consumer VPN saw London on every "what is my IP" site yet still leaked their home ASN in a video call because UDP to STUN exited outside the tunnel while TCP to websites stayed inside. Below I explain how that happens, what a clean result looks like, and why no browser tab can fully replace a native DNS leak harness.
What this tool checks (and what it cannot prove)
The HTTP baseline row reflects the client address Cloudflare forwards to my origin (via CF-Connecting-IP or equivalent). That is the address accounting systems, fraud scores, and most websites observe for ordinary page loads over TLS. The WebRTC srflx list collects IPv4 addresses parsed from ICE candidates whose type is srflx, meaning the STUN server saw your UDP packet arrive from that public endpoint. When both paths use the same VPN exit, the addresses should match within each IP version family.
This is a heuristic, not a certification. Malware, split-tunnel rules that only list certain executables, captive portals, or IPv6-only leaks outside the tunnel can all produce confusing edge cases the UI labels inconclusive rather than binary pass or fail. Treat the output as homework: if anything disagrees, reproduce with your VPN vendor's native tester and packet capture before filing a bug against the VPN.
How WebRTC leaks differ from normal page loads
WebRTC negotiation uses the Interactive Connectivity Establishment (ICE) algorithm defined in RFC 8445. Part of ICE involves sending STUN binding requests defined in RFC 5389 so endpoints learn reflexive addresses through NAT. Browsers also ship mDNS hostnames for privacy on local networks; when those are in play you may see opaque .local names until srflx candidates arrive. If your VPN routes TCP web traffic through the tunnel but lets UDP fall back to the ISP because of a missing firewall rule, srflx can expose the ISP address even while HTTPS still shows the VPN. That is the classic WebRTC leak pattern privacy guides warn about.
Modern browsers continue to tighten defaults (muted interfaces, requiring user gestures for camera access, limiting host candidates), but ICE itself still needs reflexive data to function. The fix is rarely "disable WebRTC globally"; it is to route UDP through the same interface as TCP or to use a VPN client that installs a kernel driver capturing all IP protocols.
DNS leaks: why the browser cannot see everything
A DNS leak means queries for domain names resolve through a resolver your VPN did not intend, usually your ISP, while tunneled traffic still exits at the VPN IP. Full detection often uses unique subdomains so an authoritative server can log which resolver asked the question. Ordinary same-origin JavaScript cannot enumerate every OS socket or systemd-resolved split configuration; that is why this site steers you toward What Is My DNS for intentional DoH lookups and toward native leak testers for definitive answers.
IPv6 raises the stakes: if your VPN only tunnels IPv4 but your OS prefers IPv6 for some destinations, AAAA lookups and subsequent TCP connections can bypass the tunnel entirely. Fixing that is usually "enable IPv6 inside the VPN" or "block IPv6 at the client until the provider ships dual-stack exits," not blind toggling in the browser.
What a boringly good result looks like
Expect the HTTPS IP and every srflx IPv4 to match the VPN provider's announced exit range. Expect DNS answers (when you test them deliberately) to come from the provider's resolver hostnames, not your ISP branding. Expect WebRTC to either show no srflx within the gather timeout (strict NAT) or show srflx that still equals the VPN. Mismatches deserve screenshots for support: include timestamp, selected city, and whether split tunneling is enabled for "work apps."
Fixes that survive a reboot
Start with the VPN client: enable the kill switch, disable split tunneling for the browser you test with, and turn on the provider's DNS lock if offered. On Firefox, advanced users inspect about:config keys such as media.peerconnection.ice.default_address_only and related toggles, but prefer vendor guidance because the exact keys shift between releases. On Windows, verify the VPN virtual adapter metric is lower than the Wi‑Fi adapter so default routes actually move.
Example Firefox diagnostics (read-only; only change values you understand):
about:webrtc
about:networking#dnsThe first page summarizes active sessions; the second lists DNS cache entries visible to the browser, which helps when debugging captive portals or stale SRV records.
Claims on the box versus what you can verify
"No logs" is not observable from the outside; it is a legal and operational promise. Jurisdiction matters because subpoenas follow corporate domicile. RAM-only servers reduce forensic residue but do not change routing math. What you can verify at home is path correctness (this page), resolver choice (DNS tool), whether IPv6 is covered, and whether the kill switch blocks traffic when you yank the VPN process. Write those checks into your travel checklist the same way you test smoke detectors.
Leak types compared
| Leak type | What is exposed | Common cause | Practical fix |
|---|---|---|---|
| WebRTC / ICE srflx | Public IPv4/IPv6 outside VPN | UDP not routed into tunnel; disabled firewall helper | VPN kernel driver; disable split tunnel; vendor update |
| DNS | Hostnames visible to ISP resolver | OS still prefers DHCP DNS; VPN DNS not pushed | DNS lock; set DoT/DoH only on VPN interface |
| IPv6 | Native IPv6 path bypasses IPv4-only tunnel | Tunnel lacks v6; OS prefers AAAA | Enable dual-stack exit; or block v6 at OS until fixed |
| Traffic correlation | Timing and volume metadata | Global passive adversary on both sides of VPN | Tor or higher-latency mix networks; accept usability hit |
| Kill-switch failure | Cleartext bursts during reconnect | Client crash; sleep/wake race; custom routes | Enable OS-level blocking rules; test with ping during reconnect |
Frequently asked questions
What is a WebRTC leak?
It is any case where WebRTC ICE reveals a public IP or UDP path that disagrees with the address your tunneled HTTPS traffic uses. Srflx candidates come straight from STUN, so if STUN sees your ISP while the website sees your VPN, your browser is split-routing at the protocol layer.
How do I know if my VPN is actually working?
Run three independent checks: HTTPS IP (this site), srflx comparison (this page), and a resolver-specific DNS test (our DNS tool or your vendor panel). If all three align on the VPN provider, you have strong evidence the default route moved. If any disagree, capture logs before assuming the VPN is "broken."
Why does my VPN leak DNS?
Because operating systems resolve names before or alongside the tunnel coming up, and some VPNs only copy routes for IPv4 subnets. DHCP-provided DNS servers linger in systemd-resolved, NetworkManager, or Windows interface metrics unless the VPN pushes replacement servers and raises interface priority.
Should I disable IPv6 for my VPN?
Treat disabling IPv6 as a temporary triage step, not a lifestyle. The correct fix is a VPN that tunnels both families or an OS configuration that blocks AAAA until dual-stack exits exist. Leaving IPv6 off globally can break modern sites and complicate debugging.
Do free VPNs leak more than paid ones?
Price is not the variable; engineering is. Some free tiers are reskinned paid stacks with aggressive defaults; others monetize by logging and selling DNS data, which is worse than a routing leak you can see. Read the threat model: a free browser VPN that only proxies tab traffic will never behave like a system-wide tunnel no matter how shiny the UI is.
Related tools
Baseline identity without WebRTC is on What Is My IP. ASN and organization labels are in What Is My ISP. Resolver behavior is on What Is My DNS. For RTT to this edge after you change servers, run What Is My Latency.
Sources cited above
- RFC 5389: Session Traversal Utilities for NAT (STUN)
- RFC 8445: Interactive Connectivity Establishment (ICE)
- W3C WebRTC: browser API surface
- RFC 4787: Network Address Translation behavioral requirements