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.
