WebRTC leaks, explained: how your browser hands over your real IP

You connect to your VPN. The status bar says you're protected. You load a website. The website silently asks your browser for its real IP address — not the VPN's IP, the actual one your ISP assigned. Your browser hands it over. You don't see a prompt, you don't see a warning, and the VPN is doing exactly what it promised.

This is a WebRTC leak. It's the browser's fault, not the VPN's. And it works on every modern browser unless you turn it off. (For its sibling failure mode — where the same kind of side-channel reveals you via IPv6 — see what is an IPv6 leak.)

What WebRTC actually is

WebRTC (Web Real-Time Communication) is the browser API that powers in-browser voice and video calling. Google Meet, Discord voice channels, Slack huddles, Whereby, the in-browser parts of Zoom — all of them use WebRTC. It's also used for direct file transfers, screen sharing, and the click-to-call buttons on customer support pages.

For peer-to-peer connections to work, the browser needs to know your public IP. That's how the other side reaches you. WebRTC handles this with a STUN server: the browser asks a public STUN server "what address am I coming from?" The STUN server replies with whatever IP it sees. The browser caches that and offers it to any page that asks via the WebRTC API.

The architecture made sense in 2011 when WebRTC was designed. Latency-sensitive peer-to-peer was the use case. Privacy from arbitrary websites was not on the design board.

Why a VPN doesn't fix it

The VPN tunnels your network traffic. WebRTC's STUN exchange operates on top of that, but the answer the browser caches is your real IP, not the tunnel's, in two cases:

Case 1: STUN was queried before the VPN connected. The browser learned your real IP at startup or on a previous network. Cached. The page asks WebRTC for IPs and gets the cached real value.

Case 2: The VPN doesn't tunnel UDP to the STUN server. Some VPN setups have routing edge cases. The STUN packet escapes the tunnel.

Even with a properly tunnelled VPN, the browser-level STUN cache is the attack surface. Pages don't need to query STUN themselves; they just ask WebRTC for the IPs the browser already knows.

Exposed vs leaking

The terminology matters because the response differs.

Exposed. You're not on a VPN, you visit a page, the page sees your real IP. This is the expected behaviour. It's not a leak; it's the internet working as designed.

Leak. You ARE on a VPN, the page should only see the VPN's IP, but WebRTC hands over your real IP anyway. This is a leak. The privacy you thought you had is broken.

The Fexyn WebRTC leak test tool shows you which case you're in. With the VPN connected, the public IP shown should be the Fexyn server's. If it's your real home IP, you're leaking.

What an attacker sees from a leak

The same things they'd see without a VPN:

Your real public IP address
Coarse geolocation (city-level usually, sometimes neighbourhood-level for residential ISPs)
Your ISP
A persistent identifier they can correlate with other visits and other sites

Worse than no VPN: the leak gives them both your real IP and your VPN IP. They can correlate those across sessions, build a profile that follows you whether the VPN is on, and use the VPN IP itself as a fingerprint.

For threat models where geolocation matters (journalists, activists, anyone hiding from a stalker, anyone using a VPN to avoid jurisdiction-specific tracking) a WebRTC leak undoes the protection silently.

Per-browser fixes

The fix lives in the browser, not the VPN. Each browser handles WebRTC differently.

Firefox — full disable

The cleanest option. Firefox lets you disable WebRTC entirely:

Open a new tab and navigate to about:config. Accept the warning prompt.
Search for media.peerconnection.enabled.
Set it to false.
Restart Firefox.

Cost: video calls in any web app stop working. Slack huddles, Google Meet, Discord voice in browser — all dead until you flip it back. For most privacy-focused users this is acceptable; calls happen in the dedicated app instead.

Brave — built-in toggle

Brave ships a privacy-focused setting:

Open brave://settings.
Search for "WebRTC".
Set "WebRTC IP Handling Policy" to Disable non-proxied UDP.

This is the strongest setting that doesn't fully break WebRTC. Calls still work; STUN traffic is restricted to the proxy path. For Brave users on a VPN, this is the right setting.

Chrome and Edge — extension required

Neither Chrome nor Edge has a built-in WebRTC toggle in the settings UI. You need an extension. Install one of:

uBlock Origin with the "Prevent WebRTC from leaking local IP addresses" filter enabled. uBlock Origin is the right ad blocker anyway; this is a free extra.
WebRTC Network Limiter (published by Google directly). Single-purpose, restricts WebRTC to the proxy path.

Avoid random one-star "WebRTC fix" extensions in the Chrome Web Store. The category attracts low-quality and occasionally malicious extensions. Stick to uBlock Origin or the Google-published one.

Safari

Safari implements WebRTC but doesn't expose a toggle. If you're on Safari and care about WebRTC leaks, switch to Brave (Webkit-based, has the toggle) or Firefox (Gecko-based, full disable).

How Fexyn handles it

Fexyn doesn't try to monkey-patch your browser. The browser's WebRTC behaviour is browser-side and outside the scope of what a VPN can or should override.

What Fexyn does:

Tunnels all UDP traffic, including STUN, when the protocol allows. WireGuard tunnels everything by default. VLESS Reality and OpenVPN configurations tunnel UDP through the same path.
Recommends specific browser settings on the support page.
Provides the leak test tool so you can verify your specific browser/setting combination.

The combination — tunnel STUN through the VPN, plus browser-side WebRTC disabled or restricted — closes the leak.

Re-test after applying the fix

After you change browser settings, restart the browser and run the test again at fexyn.com/tools/webrtc-leak-test. The public IP shown should match the Fexyn server. The local IP either should be empty or should show only the VPN tunnel adapter address.

If you still see your real public IP, the change didn't take. Check that:

The browser actually restarted (closing tabs is not enough; quit the application)
For Brave, the setting is "Disable non-proxied UDP", not "Disable non-proxied UDP and force proxy"
For Chrome/Edge, the extension is enabled, not just installed

What WebRTC isn't a leak about

WebRTC leaks are specifically about your IP being exposed via the browser API. They don't:

Affect non-browser apps. A native desktop app on a VPN doesn't have this problem.
Affect mobile apps that use their own networking. iOS/Android apps that don't embed a webview generally don't expose the VPN's IP via WebRTC.
Indicate that the VPN tunnel itself is broken. The tunnel is fine; the browser is volunteering information above the tunnel layer.

Try Fexyn free for 7 days. The tunnel does its part; the browser fixes are a one-time setting.