What is a WebRTC leak?

WebRTC discovers your public address by asking a STUN server what address it sees, and it does this from JavaScript without a permission prompt. If your VPN routes browser traffic but leaves another interface reachable, STUN can report the address behind the VPN. The page then knows both.

Does a VPN stop WebRTC leaks?

A well-configured one does, by routing all traffic including UDP through the tunnel and blocking traffic on other interfaces when the tunnel drops. Split tunnelling, a VPN that handles only IPv4 while your ISP provides IPv6, and browser extensions that proxy only HTTP all leave the gap open.

Why does the test show a .local address?

That is mDNS candidate obfuscation, shipped in Chromium and Firefox. The browser replaces your private LAN address with a random hostname so a page cannot enumerate your internal network. It is not a leak and it does not need fixing.

Should I disable WebRTC?

Only if you do not use browser-based calls. Disabling it breaks Google Meet, Discord in the browser, Jitsi, and most video chat. Fixing the VPN configuration is the better answer for almost everyone, because it removes the leak without removing the feature.

Does a leak here mean my VPN is useless?

No. It means one channel is bypassing it. Regular HTTP traffic still goes through the tunnel. But a site that runs this same test learns your real address in a few hundred milliseconds, which defeats the reason most people run a VPN.

WebRTC Leak Test

Check whether WebRTC exposes a public address different from the one your connection shows; the test runs in your browser.

Test not startedThis check runs entirely in your browser and needs JavaScript. Nothing about the result reaches our servers.

Edge sees 216.73.216.7

Fix instructions

Chrome and Edge

There is no setting in Chrome or Edge that turns WebRTC off, and the old command-line policies were removed for most users. Two things actually work.

Fix the VPN. Turn off split tunnelling, switch the kill switch on, and make sure the client carries IPv6.
Install an extension that sets the WebRTC IP handling policy to disable_non_proxied_udp. Video calls keep working through the proxy.

WebRTC cannot be tested without JavaScript. The test has to open an RTCPeerConnection in your browser, which is JavaScript by definition. With scripting off, no page can run this leak, so on this visit you are not exposed to it.

Our edge saw this request come from 216.73.216.7. That is the address a leak would be compared against.

How the test works

The page constructs an RTCPeerConnection with two public STUN servers configured, creates a data channel to force candidate gathering, and listens for icecandidate events until the gathering state reaches complete or a short timeout expires. Each candidate line is parsed for its type and address. The server-reflexive addresses are then compared against the address our edge recorded for the HTTP request that loaded the page.

Two STUN servers are queried rather than one, because a single blocked or unreachable server returns no candidates, and no candidates looks exactly like no leak.

Nothing is sent to our servers. The comparison happens in your browser, against a value that was already in the page.

Fixing a leak, by browser

Firefox. Open about:config, accept the warning, and set media.peerconnection.enabled to false. This disables WebRTC completely and breaks video calls in Firefox. For a narrower fix, set media.peerconnection.ice.default_address_only to true, which limits candidate gathering to the default route, or media.peerconnection.ice.no_host to true to suppress host candidates only.

Chrome, Edge, Brave, and other Chromium browsers. There is no flag in settings that disables WebRTC and no about:config. Chromium removed the older command-line policy options for most users. Brave has a built-in control at Settings, Privacy and security, WebRTC IP handling policy, where “Disable non-proxied UDP” is the setting that stops the leak while keeping calls working through a proxy. For plain Chrome and Edge, use an extension that sets the WebRTC IP handling policy, or fix the VPN so there is nothing to leak.

Safari. WebRTC is enabled and Safari already restricts candidate gathering: it exposes host candidates only after the page has been granted camera or microphone access, and uses mDNS otherwise. To disable it, enable the Develop menu in Settings, Advanced, then Develop, WebRTC, and uncheck the enable entry. The setting resets on some updates.

The better fix in every browser. If a leak appears, the VPN configuration is usually the real problem. Turn off split tunnelling, enable the kill switch or firewall lockdown, and make sure the client handles IPv6 rather than ignoring it. A VPN that tunnels IPv4 only will leak an IPv6 address through WebRTC on any dual-stack connection, and no browser setting fixes that.

Limits

This test checks what your browser will tell a page right now. It cannot tell you what a native application on your machine does, and it cannot see a leak that only appears when the tunnel drops. For that case, run the test again while deliberately disconnecting the VPN, and watch whether the address changes before the kill switch reacts.

About this tool

WebRTC has to discover your real address to connect two people, and a page can read it with no permission prompt. This test opens an RTCPeerConnection against two public STUN servers, gathers the ICE candidates, and classifies each one as host, server-reflexive, or relay. It then compares the server-reflexive address against the address our edge saw, and a difference is a leak. Everything runs in your browser.

How to read the result

Verdict: No leak: The server-reflexive candidates match the address our edge observed, or no srflx candidate exposed a distinct public address. WebRTC shows the same address as the rest of your traffic and is not revealing a path around your connection.
Verdict: Leak: WebRTC exposes X while your connection shows Y: A server-reflexive candidate carried a public address different from the one on your HTTP connection, so any site can run this same test and see your real address despite the VPN. It is typical of a split-tunnel configuration, or of a VPN client that leaves the physical adapter reachable.
Verdict: WebRTC disabled: The browser produced no candidates, or the RTCPeerConnection constructor is unavailable, so WebRTC is turned off or suppressed and cannot leak. Video calls in this browser will not work either.
Host candidates: Addresses on your local interfaces. Chromium and Firefox return an mDNS name ending in .local instead of an RFC 1918 address, unless the page holds camera or microphone permission, so a .local value here is the privacy protection working.
Server-reflexive (srflx) candidates: The public address a STUN server observed for your connection, and the field that actually leaks. Two STUN servers are used so that one unreachable server cannot produce a false all-clear.
Relay (relay) candidates: Addresses on a TURN server, the relay used when a direct connection fails. We configure no TURN server, so this row is normally empty, and a relay candidate would show the TURN server address rather than yours.

Questions people ask

What is a WebRTC leak?: WebRTC discovers your public address by asking a STUN server what address it sees, and it does this from JavaScript without a permission prompt. If your VPN routes browser traffic but leaves another interface reachable, STUN can report the address behind the VPN. The page then knows both.
Does a VPN stop WebRTC leaks?: A well-configured one does, by routing all traffic including UDP through the tunnel and blocking traffic on other interfaces when the tunnel drops. Split tunnelling, a VPN that handles only IPv4 while your ISP provides IPv6, and browser extensions that proxy only HTTP all leave the gap open.
Why does the test show a .local address?: That is mDNS candidate obfuscation, shipped in Chromium and Firefox. The browser replaces your private LAN address with a random hostname so a page cannot enumerate your internal network. It is not a leak and it does not need fixing.
Should I disable WebRTC?: Only if you do not use browser-based calls. Disabling it breaks Google Meet, Discord in the browser, Jitsi, and most video chat. Fixing the VPN configuration is the better answer for almost everyone, because it removes the leak without removing the feature.
Does a leak here mean my VPN is useless?: No. It means one channel is bypassing it. Regular HTTP traffic still goes through the tunnel. But a site that runs this same test learns your real address in a few hundred milliseconds, which defeats the reason most people run a VPN.

Last reviewed 2026-09-05.