How to Fix a WebRTC Leak
A browser feature for video calls hands out your addresses to any page that asks, tunnel or no tunnel.
🔎 Run the WebRTC leak test⚠️ Confirm it before you change anything
Every step below alters how your machine handles connections, and undoing a change you did not need is harder than not making it. Run the test first so you are fixing something that is actually happening, and run it again after each step so you know which one worked.
What this actually is
WebRTC exists so browsers can connect to each other directly for calls and screen sharing. To make that work it asks the operating system for every address the machine can be reached on, and any page can read the answer without a permission prompt. On a VPN this can surface an address the tunnel never presented - which is why a connection with a perfect IP row can still be identifiable.
WebRTC asks your operating system directly for candidate addresses so that calls can connect peer to peer. Any page can read the answer without permission, which is how a site learns an address your VPN never presented.
How it shows up
- A leak test reports a public address under WebRTC that differs from your VPN IP.
- A local address like 192.168.x.x is listed as well - your own network, not a leak by itself.
- Everything else passes - the leak is entirely inside the browser and invisible to the VPN client.
- It differs between browsers on the same machine.
Causes, in the order to check them
Work down the list in order. The first is the quickest to check and to undo, and the later ones only apply once it has been ruled out - which stops you disabling things you never needed to touch.
-
1 The browser is exposing candidates by default
- Firefox: open about:config and set media.peerconnection.enabled to false. This breaks browser calls and screen sharing.
- Chrome and Edge: there is no built-in switch. Use an extension that limits WebRTC to the tunnel's address - check that it supports your browser version - or use Firefox or Brave, which have the setting built in.
- Brave: Settings → Privacy and security → WebRTC IP handling policy → "Disable non-proxied UDP".
-
2 Your VPN app has WebRTC protection available but not enabled
- Check the VPN's browser extension settings - several ship a WebRTC toggle separate from the desktop app.
- Enable it, reload this page, and re-run the test.
🔁 Check whether it worked
Run it again after each change rather than at the end. Two steps applied together tell you nothing about which one mattered - and one of them may have been unnecessary.
🔎 Run the WebRTC leak testWebRTC is exposing an address the tunnel does not cover - FAQ
The questions that follow from it.
Should I disable WebRTC entirely?
Only if you never use browser-based calls. Disabling it breaks video conferencing in the browser, screen sharing, and some file transfer tools, and it takes a while to connect the breakage to the setting once you have forgotten you changed it. An extension that restricts WebRTC to the tunnel's address is the better trade if you make calls in the browser, because it keeps them working.
Does a WebRTC leak show my real IP if I am on a VPN?
It can, and that is the point of testing it. WebRTC asks the operating system directly rather than going through the browser's normal networking, so on some configurations it enumerates an interface the tunnel does not cover and reports the address attached to it. Whether that address is your real one depends on how the tunnel is set up - which is exactly what a test settles and guesswork does not.
Why does my leak test pass in one browser and fail in another?
Because the behaviour is the browser's, not the system's. Firefox, Chrome and Safari differ in what they expose by default and in how they obfuscate local addresses, and any extension that touches WebRTC changes it further. A pass in the browser you tested says nothing about the one you actually browse in - test each.
Do local IP addresses like 192.168.1.5 matter?
They do not identify you the way a public address does - millions of networks use the same private ranges. What they contribute is detail: how your network is numbered, and a value that stays stable enough to help link sessions together when combined with other signals. Modern browsers obfuscate them behind random hostnames for this reason, and seeing a real one means that protection is not active.
🧰 Test it yourself
The tests run in your browser. Where one needs to know whose network an address is on, our server looks it up and keeps no address. Nothing is stored unless you choose to share the result.
📚 Read next
The longer version: what this test is looking for, and what to do with the answer.