Brave has a strong privacy reputation, and for good reason — it blocks trackers and ads by default. But there's one setting that trips up even careful users: the WebRTC IP handling policy. Left on its default, Brave can still leak your real IP address through WebRTC, even when you're connected to a VPN.
This guide explains what that setting actually does, walks through all four modes in plain language, tells you which one to pick, and shows you how to confirm the leak is closed.
Why Brave can leak your IP even with a VPN
WebRTC (Web Real-Time Communication) is the technology that powers in-browser video calls, voice chat, and peer-to-peer connections — think Google Meet, Discord, or Zoom running in a tab without a plugin.
To make those direct connections work, WebRTC needs to discover the best network path between you and the other party. It does this by querying STUN servers, which report back the IP addresses your browser can be reached on. That's useful for a video call. It's a problem for privacy, because those IP addresses can include your real public IP — the one your VPN is supposed to be hiding.
The leak happens at the browser level, underneath your VPN. Your VPN encrypts and reroutes your normal traffic, but WebRTC's IP discovery can sidestep that tunnel and hand your true IP straight to a website that asks for it. This affects Chrome, Edge, Opera, and every Chromium-based browser — Brave included.
The good news: unlike Chrome, Brave builds a direct control for this right into its settings.
The four WebRTC IP handling modes
Brave exposes four options for how WebRTC is allowed to discover and use your network interfaces. Here's what each one actually does, from least private to most:
Default — WebRTC can enumerate every network interface and use them all to find the best connection. This is the most permissive mode and the one most likely to expose your real IP (and your local network addresses). It's the default unless you're in a Tor tab or have fingerprinting protection active.
Default Public and Private Interfaces — WebRTC uses only the default route your regular web traffic takes, but it still exposes the associated private (local network) address alongside the public one. A modest improvement, but it still reveals your local IP.
Default Public Interface Only — WebRTC uses only the default public route and does not expose any local addresses. This hides your internal network layout but can still expose your primary public IP.
Disable Non-Proxied UDP — The strictest option that keeps WebRTC working. WebRTC is forced to use TCP through your proxy, and only uses UDP if your proxy explicitly supports it. In practice, this means WebRTC can no longer bypass your VPN or proxy to leak your real IP — any connection has to go through the tunnel.
Which mode should you choose?
For almost everyone using a VPN or proxy, the answer is Disable Non-Proxied UDP.
It's the most restrictive setting that still lets WebRTC function, so it closes the leak without breaking the feature entirely. Your VPN or proxy stays the source of any WebRTC connection, which is exactly what you want.
One honest caveat: Brave — like all Chromium browsers — does not offer a true "turn WebRTC completely off" switch the way Firefox does. If you need to fully eliminate the WebRTC engine, that requires a different browser or OS-level network controls. But for the practical goal of stopping IP leaks while keeping the browser usable, Disable Non-Proxied UDP is the right choice.
Step-by-step: change the setting in Brave
- Type
brave://settings/privacyinto your address bar and press Enter. (You can also go to Settings → Privacy and security.) - Scroll down to WebRTC IP Handling Policy.
- Open the dropdown and select Disable Non-Proxied UDP.
The change takes effect immediately — no browser restart needed, and it's fully reversible if you ever need to switch it back for a video call that won't connect.
Optional: strengthen fingerprinting protection too
Brave's fingerprinting protection also reduces some WebRTC-based exposure. To harden it further, go to Settings → Shields → Fingerprinting and choose the strictest blocking option available. Be aware this can occasionally break site functionality (some video calls, browser games, or mapping tools), so you may want a separate browser profile for sites that need full WebRTC access.
Verify the leak is actually closed
Changing a setting is only half the job — you need to confirm it worked. Turn on your VPN, then run a WebRTC leak test. It shows you exactly which IP addresses your browser is exposing through WebRTC right now.
Here's the reliable way to test:
- Connect your VPN.
- Run the WebRTC leak test and note the IP shown.
- Compare it to your real IP (disconnect the VPN and check again if you're unsure).
If the test shows only your VPN's IP — and not your real one — the leak is closed. If your real IP still appears, double-check that the policy is set to Disable Non-Proxied UDP and that your VPN is actually connected, then re-test.
Check everything else while you're at it
WebRTC is only one of several ways your browser can quietly expose you. Your DNS queries, your fingerprint, your referrer headers, and your HTTPS status all tell a story too. Once you've fixed WebRTC, run a full Privacy Score check — it runs eight privacy checks in one click and gives you an A–F grade with a personalised fix plan, so you can see everything that's leaking in one place rather than testing each vector separately.
Quick recap
- Brave can leak your real IP through WebRTC even with a VPN on, because WebRTC's IP discovery happens beneath the VPN tunnel.
- The fix is one setting: WebRTC IP Handling Policy → Disable Non-Proxied UDP, found at
brave://settings/privacy. - It's the strictest option that keeps WebRTC working, applies instantly, and is reversible.
- Always verify with a WebRTC leak test after changing it — never assume a setting worked without confirming.
Verify and Go Further
After changing the IP handling policy, confirm it worked with the WebRTC Leak Test. Brave blocks many trackers by default, but that does not cover DNS — run the DNS Leak Test to check. Brave also has strong fingerprinting protection; see what still gets through with Browser Fingerprint, and check what your browser exposes overall with Privacy Score.
Frequently Asked Questions
Does Brave leak my IP even with Brave Shields turned on?
Yes, potentially. Shields blocks trackers, ads and fingerprinting scripts, but WebRTC is a legitimate browser API rather than a tracker, so Shields does not disable it. A site can still request your local and public addresses through STUN unless the IP handling policy is changed. The two settings are independent, and leaving Shields on does not close this particular gap.
Will changing the IP handling policy break video calls?
It depends which mode you pick. "Disable non-proxied UDP" keeps WebRTC working while forcing traffic through your proxy or VPN, so Google Meet, Discord and Jitsi generally continue to function. The stricter modes can break peer-to-peer connections entirely, which is why the recommended setting is the one that constrains routing rather than the one that switches WebRTC off.
Why does my local IP still appear after changing the setting?
A local address such as 192.168.1.5 or 10.0.0.8 is assigned by your own router and is shared by millions of networks worldwide, so it identifies nothing about you. Only a public address appearing while your VPN is connected indicates a genuine leak. Most leak testers show both, which is why results look alarming more often than they should.
Do I need to change this on Brave mobile too?
Brave on Android and iOS does not expose the same IP handling policy setting, so you cannot configure it the same way. On mobile the practical fix is a VPN app that blocks WebRTC leaks at the system level rather than relying on a browser setting. Test on the device itself rather than assuming desktop settings carry across.
Is a browser extension a better fix than the built-in setting?
Generally no. The built-in policy is applied by the browser itself, which means it cannot be bypassed by a page and does not depend on a third party. Extensions add another party with access to your browsing and can silently stop working after updates. Use the native setting where one exists, and reserve extensions for browsers such as Chrome that do not offer one.
How often should I re-test for WebRTC leaks?
After any browser update, any VPN client update, and any change to your network setup. Browser updates occasionally reset privacy flags, and VPN clients sometimes change how they handle WebRTC between versions. A test takes a few seconds, so re-running it after updates is a reasonable habit rather than a chore.
