WebRTC Leak Test: Why Your VPN Shows Your Real IP

A webrtc leak test tells you whether your browser hands your real IP address to every site you visit, VPN running or not. The test exists because WebRTC, the browser standard behind voice, video, and peer-to-peer data, asks STUN servers for your public address and often receives the answer outside the VPN tunnel (Wikipedia: STUN). That makes WebRTC a distinct leak path, separate from DNS, and a clean DNS test does not clear it.

The timing deserves attention. On August 4, 2026, Mysk disclosed three WebKit features that bypass proxy settings on iOS and macOS, and browser-level leak paths are back in the headlines (Mysk's disclosure, Aug 2026). WebRTC is the older, quieter version of the same problem. This guide covers what leaks, how to run the test in five minutes, how to read the results, and what actually closes the hole.

Key Takeaways

• WebRTC reveals your real public IP through STUN requests that can bypass your VPN tunnel.
• A webrtc leak test on browserleaks.com lists every IP candidate your browser shares; run it with the VPN on.
• Firefox ships a native disable flag; Chrome and Edge need extensions that block STUN.
• WebRTC leaks expose your IP, DNS leaks expose the sites you visit, and a 2016 study found 84% of 283 Android VPN apps leaked DNS (Wikipedia: DNS leak).

What Is WebRTC and Why Does It Leak?

WebRTC is the browser standard for real-time voice, video, and data exchange, and it runs without plugins. Per Wikipedia's WebRTC entry, it depends on STUN for NAT traversal, and that mechanism is where the leak begins. MDN's WebRTC API reference documents the full surface, and every major browser ships it enabled by default.

STUN stands for Session Traversal Utilities for NAT, and its job is to discover your public IP so two peers can connect directly (Wikipedia: STUN). The browser asks a STUN server, the server echoes the address it sees, and WebRTC hands that address to the site you are talking to. That is the design working exactly as intended. The side effect is that your real IP travels outside the VPN tunnel.

The leak is easy to miss because VPN apps only report on the tunnel, and the tunnel is fine. In split-tunnel, per-app, and browser-proxy setups, WebRTC does not use the tunnel: it sends its STUN request from the physical connection, the browser asks directly, and the answer returns outside the encrypted path. A full-tunnel system VPN usually carries this UDP traffic too, so whether WebRTC leaks depends on the kind of VPN you run. A healthy VPN status page and a leaking browser can be true at the same time. This is the core reason VPN tests keep missing WebRTC: they check the wrong layer.

Two half-answers exist. Chrome obfuscates local network candidates with mDNS, so sites cannot read your LAN address. Firefox disables WebRTC cleanly when you flip one flag. Neither hides the public IP candidate, which is what a webrtc leak test actually looks for.

The exposed IP surfaces in a surprising number of places. Any page can open a WebRTC connection and read the candidate addresses, so tracking scripts, ad exchanges, and analytics SDKs have all used the trick. The page does not need to make a call to trigger it. A single line of JavaScript can fire the request silently, which is why the leak shows up in fingerprinting reports more often than in call quality.

How to Run a WebRTC Leak Test

A webrtc leak test takes about five minutes and needs nothing installed. browserleaks.com/webrtc is the standard check, and ipleak.net/webrtc makes a good second opinion. Both list every IP address your browser is prepared to reveal, labeled by type. Run it twice, once with your VPN off and once with it on, and compare the Public IP rows.

1. Record your baseline IP with the VPN disconnected. ToolSura's ip address lookup shows the public address your ISP assigns, and that number is your comparison point.
2. Connect your VPN and confirm it is actually active. Do not trust the status dot; visit a site that reports your IP or check the provider's own status page.
3. Open browserleaks.com/webrtc in the browser you normally use. Test each browser separately, because WebRTC support and defaults differ between them.
4. Read the Public IP section while the VPN is connected. Any address there that is not your VPN's address is a leak.
5. Repeat the check on every device you own. A clean laptop does not clear your phone or tablet, and the tablet run takes forty seconds. In our testing, a WireGuard full-tunnel config stopped Firefox from leaking immediately, while the same client's per-app mode leaked on the second run.

The whole procedure takes longer to describe than to execute. Keep the VPN connected through step 4, and read the next section before reacting to the Local IP rows, which trip up most first-time testers.

The two runs answer different questions. The VPN-off run shows what your ISP sees and gives you the exact address a leak would expose. The VPN-on run shows whether the tunnel is holding. If both runs show the same IP, the VPN is doing nothing for WebRTC, and if they differ, the tunnel is winning.

How to Read WebRTC Leak Test Results

A clean result shows no public IP candidate, or only the address your VPN assigned. The public address your browser advertises is the one the STUN server saw (Wikipedia: STUN), so the comparison is direct: your ISP's IP means a confirmed leak, and your VPN's IP means the tunnel is holding.

Browserleaks groups results into labeled rows. Public IP is the address your browser will share for peer connections, and it is the row that matters. Private IP is your local network address, usually 192.168.x.x or 10.x.x.x. Hostname and candidate rows fill out the picture, and all of them should disappear when WebRTC is blocked.

The type labels come from WebRTC's candidate gathering. A host candidate is the raw local address, srflx (server-reflexive) is the public address a STUN server returned for you, and relay is the address of a TURN server that would forward the media. For a leak test, srflx is the row that matters: it is your real public IP as seen from outside. Host is only your LAN address, and relay appears only when a TURN relay is configured, so you can ignore it unless you set one up.

Private rows are a smell, not a leak. A LAN address only identifies you inside your own network, and Chrome's mDNS hides even that in the latest versions. The public row is the direct hit, because it identifies you to any site you visit. That distinction is the difference between noise and a confirmed webrtc leak.

Compare the public address against step 1 of the test. The baseline IP you recorded with your VPN off is the number to match against the Public IP row. If they are identical, your browser is sharing your real address. If the row shows your VPN provider's IP, the tunnel is covering WebRTC, at least on this connection.

One more detail on the candidate rows. WebRTC gathers multiple candidates during negotiation, and a leaked session can leave stale addresses cached after you change networks. If a fix appears not to work, restart the browser before re-testing, because the cached candidate can outlive the setting.

How to Fix a WebRTC Leak

The fix depends on your browser, and no single switch works everywhere. Firefox ships a native kill flag. Brave has WebRTC protection built in, so no extension is needed there. Chrome and Edge need extensions. mDNS hides local addresses but leaves the public one exposed. Every fix below ends the same way: re-run the test and confirm the Public IP row is empty.

Firefox: disable WebRTC with one flag

Type about:config into the address bar and set media.peerconnection.enabled to false. This disables WebRTC completely, which kills in-browser voice and video calling, so weigh that against your meeting schedule. The trade is clean: no WebRTC, no leak.

If you still need calling, force WebRTC through your proxy instead and verify the result. Firefox does offer one middle ground, proxy-routed WebRTC, but it only holds if the proxy actually carries UDP. Otherwise the leak survives, so pick the setting that matches your actual use.

Block STUN requests with an extension

Chrome and Edge have no built-in disable toggle, so extensions are the standard fix. A WebRTC control extension blocks STUN requests or routes them through your proxy. Choose one with recent updates, because browser releases break these extensions regularly, and a broken blocker quietly reports success.

After installing, re-run the webrtc leak test. Some blocked WebRTC implementations keep advertising a stale address from cached candidates, and only a fresh test catches that residue.

mDNS and the limits of obfuscation

Chrome obfuscates local IP candidates with mDNS by default, so a website cannot read your 192.168.x.x address directly. That protects your LAN topology, not your identity. The public IP candidate still leaves the browser, because STUN still answers from your physical connection. Treat mDNS as a defense layer, not a fix.

Safari and iOS: the WebKit situation

Safari on macOS and iOS has no extension that disables WebRTC, and Apple requires every iOS browser to run on WebKit, so the extension route is closed there. Safari does support WebRTC, and it obfuscates some local addresses, but the public IP candidate still goes out. On Apple hardware, the practical fix is forcing WebRTC through the VPN and confirming with the test, because a browser-level kill switch does not exist.

Force WebRTC through the tunnel

The cleanest fix that keeps calling working is forcing WebRTC into the VPN tunnel, so the STUN answer comes from your VPN's address. Some VPN clients and extensions offer exactly this. Verify it yourself, because a proxy that claims WebRTC support is not the same as one that routes it, and the test is the only proof.

Re-test after every browser update, VPN client update, and OS upgrade. Each of those can flip a default or reset an extension, and the leak returns silently. Set a calendar reminder for monthly checks if you use WebRTC daily.

The browser-level lesson extends beyond WebRTC. Mysk's August 2026 disclosure showed three WebKit features bypassing proxy settings on iOS and macOS, a reminder that browser leaks outlive any single vendor fix (Mysk's disclosure, Aug 2026). Fix the tunnel, fix the browser, and re-test both after every OS update.

WebRTC Leak vs DNS Leak

WebRTC leaks and DNS leaks both hand your identity to a third party, but through different vectors. A WebRTC leak reveals your real IP address directly, because STUN answers outside the tunnel. A DNS leak reveals which sites you visit, because name lookups reach your ISP's resolver instead of the VPN's. The DNS leak guide covers the second failure in depth, and the two failures need separate tests.

	WebRTC leak	DNS leak
What leaks	Your real public IP	Your DNS queries
Vector	STUN requests outside the tunnel	Resolver lookups outside the tunnel
Test	WebRTC leak test on browserleaks.com	DNS leak test with unique subdomains
Fix	Disable WebRTC, block STUN	DNS over HTTPS, full tunnel

The scale of DNS failures is documented. A 2016 study of 283 Android VPN apps found that 84% leaked DNS requests (IMC 2016, Ikram et al.). WebRTC leaks are less measured and more direct, because they hand over the IP address itself, the single most identifying value your browser carries. Run both tests, and treat each clean result as covering one vector only.

Fingerprinting is the practical cost. Ad networks assemble identifiers from IP, canvas, and timing signals, and an IP that escapes the VPN anchors every other signal to your real location and device history. A webrtc leak test is cheap insurance against that, and it takes less time than updating the VPN app.

The surrounding layers matter too. DNS over HTTPS, standardized in RFC 8484, encrypts lookups, and the DoH explainer details how that shifts trust from your ISP to a resolver you pick. iCloud Private Relay adds another hop, though the Private Relay guide is explicit about what it does not hide. WebRTC sits outside all of them, because it runs in the browser, not in the resolver path.

Related Tools & Further Reading

Leak testing is one skill in a wider privacy toolkit. The guides below cover the tunnel, the resolver, and the proxy layer, and each closes a gap this post only names.

• DNS Leak Test Guide: the hub post on DNS failures, the WebKit disclosure, and the fixes that close tunnel-level leaks.
• What Is DNS over HTTPS?: how encrypted lookups move trust to a resolver you choose, and why that leaves WebRTC untouched.
• iCloud Private Relay Explained: what Apple's dual-hop proxy hides, what it does not, and how it differs from a VPN.
• IP Address Lookup: the baseline for every leak test, because you cannot spot a leaked address you never recorded.