WebRTC Leak Test: Why Your VPN Might Not Be Working

Your VPN can show "Connected" while your real IP address is still visible. The culprit is often WebRTC — Web Real-Time Communication — a browser feature that enables video calls, screen sharing and peer-to-peer data without plugins. To set up those sessions, WebRTC asks STUN servers which network interfaces and public addresses your device can be reached on. Those answers can leak past your VPN tunnel, exposing your true location to any website running a few lines of JavaScript. A WebRTC leak test is the fastest way to know if your privacy tool is actually working — and on speedtest.doctor it takes seconds alongside DNS and full VPN verification.

Why VPNs fail silently on WebRTC

Consumer VPN marketing focuses on encrypting traffic and replacing your public IP for streaming and torrenting. Under the hood, most clients create a virtual network adapter and route selected traffic through it. WebRTC, however, was designed for lowest-latency media paths — it may query all available interfaces including LAN addresses (192.168.x.x, 10.x.x.x) and the ISP-facing public IP learned from STUN, not from the VPN exit node.

The result: a speed test or "what is my IP" page shows the VPN exit in one request, while a WebRTC probe in the same tab reveals your home city via a different path. Fraud systems, ad networks and hostile sites correlate both values. This is why a green VPN icon is insufficient proof — you need an explicit WebRTC leak test after every client, browser or OS update.

How WebRTC discovery works (STUN and ICE)

WebRTC connections use ICE (Interactive Connectivity Establishment) to find workable paths between peers. ICE gathers candidates — host IPs, server-reflexive addresses from STUN, and relay addresses from TURN. STUN sends a small UDP packet to a public server which echoes back the source address it saw. That reflexive address is often your true public IP as seen by the internet, not the VPN egress.

Browsers expose gathered candidates to JavaScript through APIs like RTCPeerConnection. Privacy-focused browsers have tightened defaults, but the specification still prioritizes call reliability over VPN anonymity. Enterprise users on split-tunnel VPNs face the same issue: corporate video calls need local interface access; attackers abuse the same mechanism.

TURN relays add another path: when direct peer connection fails, media may flow through a relay that sees metadata even if IP candidates were masked. Most leak tests focus on STUN reflexive addresses because those are what trackers scrape from JavaScript — understanding the full ICE table helps advanced users interpret ambiguous results.

Signs your VPN is not really protecting you

• Streaming still shows home region — IP may be masked while WebRTC or DNS metadata geolocates you.
• "What is my IP" differs from leak test — simple IP checkers do not exercise WebRTC candidate gathering.
• Ads reference your real city — correlating leaked local subnet with account profiles.
• VPN works in browser but not in apps — system-wide vs split tunnel; WebRTC is browser-scoped.
• Leak appeared after browser update — new WebRTC defaults or disabled VPN extension APIs.

Run a proper WebRTC leak test

Follow a repeatable protocol so results are comparable across VPN providers and devices:

1. 01Connect to your VPN and wait until the client reports a stable tunnel.
2. 02Close other VPN browser extensions that might conflict.
3. 03Open a fresh private/incognito window — reduces extension interference.
4. 04Visit /security/webrtc-leak on speedtest.doctor and start the test.
5. 05Review exposed IPs: only the VPN address should appear; no ISP or LAN leak.
6. 06Cross-check DNS leak and VPN test — privacy requires all three clean.

speedtest.doctor runs these checks in your browser against measurement infrastructure at api.speedtest.doctor — independent, self-hosted, and not affiliated with any VPN vendor. For a holistic view including throughput and latency, follow with the Connection Doctor at /diagnosis.

WebRTC leaks vs DNS leaks vs IP leaks

Fixing one does not fix the others. A hardened DNS configuration leaves WebRTC untouched. A browser extension blocking WebRTC does not stop DNS queries to your router. Treat privacy verification as a checklist, not a single green badge.

How to fix WebRTC leaks

VPN client with WebRTC protection

Quality VPN applications include "WebRTC leak protection" or "block WebRTC outside VPN" settings that bind browser traffic to the tunnel interface on supported OS versions. Enable it, reboot if prompted, retest. Not all clients implement this on Linux or mobile — verify on each platform you use.

Browser settings and flags

Firefox users can set media.peerconnection.enabled to false in about:config — disabling WebRTC entirely. Chromium-based browsers lack a simple toggle; extensions or enterprise policy may be required. Safari's implementation exposes fewer candidates but should still be tested after major iOS/macOS upgrades.

Extensions (use with caution)

WebRTC control extensions can patch leaks quickly but add supply-chain risk — only install reputable extensions with open policies. Prefer VPN-level or browser-level fixes when available. Remove duplicate extensions that inject scripts into leak test pages; they cause false positives.

Disable IPv6 on the VPN

IPv6 traffic sometimes routes outside an IPv4-only VPN tunnel, creating parallel leaks unrelated to WebRTC but equally dangerous. Many VPN clients offer "block IPv6" or full-tunnel IPv6 support — pair with VPN test to confirm.

Browser and platform differences

Chrome and Edge on Windows historically leaked local IPs via mDNS host candidates; patches reduced but did not eliminate risk on all VPN setups. Firefox offers the strongest manual controls for power users. Safari on iOS routes WebRTC differently; test on the device you actually carry. Mobile VPN apps running in "on-demand" mode may drop the tunnel while WebRTC pages stay open in background tabs — retest after unlocking the phone.

VPN marketing vs measurable privacy

"No logs" policies do not matter if the site you visit never needs your VPN provider's logs — it already read your real IP from WebRTC. Independent verification beats trust badges. speedtest.doctor publishes free, repeatable tests so you can compare providers, browsers and configurations with the same methodology. Developers can automate checks via the Measurement API at api.speedtest.doctor — see /docs for endpoints and authentication.

When to retest

Run a WebRTC leak test after: installing a browser update, enabling a new extension, changing VPN protocol (WireGuard vs OpenVPN), switching from Wi-Fi to Ethernet, or waking a laptop from sleep. Quarterly retests catch gradual configuration drift. Before sensitive research, journalism or travel, run the full trio — WebRTC, DNS and VPN — plus /diagnosis if connection stability also matters.

mDNS, local candidates and home LAN exposure

Beyond public IP leaks, WebRTC may advertise mDNS host candidates like abc123.local that fingerprint your device on a LAN. On a trusted home network that is low risk; on coffee-shop Wi-Fi it helps attackers correlate sessions. VPNs rarely tunnel mDNS. Some browsers mask mDNS names; test rather than assume. Combined with leaked 192.168.x.x host candidates, a remote site learns your internal subnet topology even if it cannot route packets inward.

Tor, proxies and double-hop setups

Users chaining Tor over VPN or using SOCKS proxies assume layered anonymity. WebRTC operates at the browser layer and may still enumerate interfaces below Tor Browser's protections if you use a standard Chrome profile with a proxy extension. Tor Browser disables WebRTC by design — verify you are not re-enabling it via experimental flags. After any chain change, rerun WebRTC leak test and VPN test in the exact browser profile you use daily.

Remote work and split tunnel policies

Corporate VPNs often split-tunnel SaaS traffic for performance while tunneling internal subnets. Personal privacy VPNs on the same laptop can fight corporate policy — two clients, overlapping routes, unpredictable WebRTC binding. Use separate browser profiles or VMs for personal versus work traffic. IT departments auditing compliance should include WebRTC in threat models, not only IP egress filters.

Legal and ethical testing notes

Leak tests on speedtest.doctor run client-side in your browser against our measurement endpoints — they do not bypass third-party systems or probe networks you do not control. Use results to configure your own devices. Journalists, researchers and travelers should document test timestamps when demonstrating due diligence on source protection.

False positives and troubleshooting the test

If a leak test fails unexpectedly, disable browser extensions one by one — ad blockers and privacy tools sometimes inject scripts that mimic leak behavior. Try a second browser with a clean profile. Confirm you are on https://speedtest.doctor, not a typosquat domain. Corporate SSL inspection can alter WebRTC behavior; test on a personal device on cellular data as a control. When results stabilize, record VPN protocol, browser version and OS build so you can compare after updates.

Building a personal privacy checklist

Save this repeatable workflow: (1) connect VPN, (2) WebRTC leak test, (3) DNS leak test, (4) VPN test, (5) optional Connection Doctor for stability. Archive screenshots or JSON exports from api.speedtest.doctor if your threat model requires audit trails. Revisit after vendor incidents — VPN providers change client behavior without prominent release notes.

Tool quick links