VPN Leak Test Explained — WebRTC vs DNS vs IP (What Web Pages Can See)

A VPN leak is frustrating because it defeats the expectation that all traffic magically exits somewhere else under one IP. In practice leaks split into three buckets analysts talk about constantly: IP visibility on HTTP transports, UDP paths exposed via WebRTC ICE, and DNS lookups that bypass the tunnel resolver. Knowing what ordinary pages can diagnose helps you allocate effort—browser JavaScript excels at HTTPS and ICE signals, struggles with authoritative DNS proofs.

Your browser routinely displays the address servers see during TLS-connected fetches. That datum—sometimes augmented by CDN headers—is the backbone of generic “what is my IP?” widgets.

What WebRTC gathers and why srflx matters

Peer connections negotiate media or data paths using Interactive Connectivity Establishment (ICE). Each candidate is a potential route: local host/private addresses (host), symmetric NAT reflex results from interacting with STUN (srflx), relay overlays via TURN (relay), and learned peer-visible paths (prflx).

Srflx lines matter for leak hunts because constructing them sends UDP probes to cooperative STUN infrastructure. Reflexive IP values should align with whichever public endpoint your upstream NAT (or tunnel) exposes for outbound UDP—not necessarily identical to HTTPS’s TCP-visible address, especially when routers treat stacks differently—but large divergences merit inspection.

Modern browsers progressively expose typed candidate envelopes; SDP strings remain the compatibility fallback (typ srflx marker plus embedded IPv4). IPv6-containing SDP fragments can be tougher to fingerprint without richer parsing; combine automatic comparison with vendor leak suites when IPv6 ambiguity matters.

Practical comparison heuristic

Run a short ICE gather alongside the HTTPS baseline:

DNS leaks—the infrastructure gap

DNS leaks historically meant “my ISP resolver still queried authoritative servers for tunnel hostnames”. Proving resolver identity needs unique labels delegated under measurement domains—something passive pages cannot magically invent without cooperating DNS operators.

Responsible guidance still matters: insist on VPN DNS lock / exclusive resolver switches, firewall outbound 53/tcp/udp hygiene, DHCP option audits, systemd-resolved snapshots (Linux), and split-tunnel exclusions that accidentally leave Slack or browser updates cleartext.

Browser-only tools can nonetheless teach controlled DNS-over-HTTPS lookups so you consciously compare resolver-visible answers—for example using our complementary What Is My DNS page after you deliberately configure DoH. That instructional flow is orthogonal to exhaustive leak certification.

Why kill switches complement JavaScript probes

Operating-system kill switches cut non-VPN egress when tunnels drop—closing opportunistic windows where DNS or stray UDP escapes. Scripts cannot flip host routing tables; pairing automated UI checks with provider-native testers remains best practice during threat modeling—not consumer convenience alone.

Code snippet: minimal ICE scaffolding (educational)

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }],
});
pc.createDataChannel("probe");
pc.onicecandidate = (evt) => {
  const cand = evt.candidate;
  if (!cand) return;
  console.log(cand.type, cand.candidate ?? cand.address);
};
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

Production code adds bounded timers, SDP fallbacks when address is omitted, concurrency guards, concise privacy copy, and calibrated language (“possible signal” rather than binary pass/fail).

When a green check still lies

Symmetric NAT sometimes yields no srflx inside a few seconds even though your VPN is healthy—absence of ICE data is inconclusive, not proof of safety. Enterprises may proxy HTTPS while leaving UDP alone, which skews comparisons unless you control for policy. IPv6 paths can diverge from IPv4; if your VPN client handles only one family, you must inspect both explicitly.

Split-tunnel exclusions (games, conferencing, corporate SaaS IPs) purposely route outside the tunnel—calling that a “failure” misses intent. Readers should correlate browser findings with the VPN dashboard, firewall logs, or packet captures when stakes are high (journalism, legal, regulated remote access).

Fingerprinters stitch IP hints with unrelated signals—WebGL, fonts, audio—so tightening WebRTC alone does not erase tracking risk. Combine leak checks with browser hardening guides and HTTPS Everywhere-era habits (now largely default).

Open What Is My VPN / Am I Leaking? for an immediate HTTPS-vs-WebRTC comparison on this domain, browse What Is My IP / What Is My ISP / What Is My Latency / Internet Speed Test for transport context, and use What Is My DNS when you want hands-on resolver queries—knowing DNS identity still needs VPN-native tooling for authoritative proof.