---
title: "WebRTC Leaks: What They Expose and How to Fix Each Browser"
description: "How do you stop a WebRTC leak? Block non-proxied UDP or turn WebRTC off. Get Firefox and Chrome steps, then retest in the same profile with your proxy on."
url: "https://donutbrowser.com/ja/webrtc-leak/"
---

1. [ホーム](https://donutbrowser.com/ja/)

2. [ブログ](https://donutbrowser.com/ja/blog)

3. WebRTC Leaks: What They Expose and How to Fix Each Browser

# WebRTC Leaks: What They Expose and How to Fix Each Browser

Updated October 14, 2026

webrtc privacy proxy

**A [WebRTC leak](https://dnsleaktest.com/webrtc.html) is your real public IP reaching a site through WebRTC candidates while a proxy or VPN is on. Fix it by stopping non-proxied UDP or controlling what WebRTC reports; the method differs per browser and can [break in-browser calls](https://chromewebstore.google.com/detail/webrtc-leak-prevent/eiadekoaikejlgdbkbdfeijglgfdalml). Retest in the same profile and proxy setup.**

The problem usually looks like this: an IP checker shows your proxy address, while a WebRTC test page lists your real ISP address. It affects agencies, media buyers, sellers, QA and automation engineers, and privacy-minded users who keep identities apart.

After reading, you can interpret a test result, fix each browser and verify the fix per profile. I make Donut Browser, which doesn’t sell proxies, so the advice is by trade-off. No browser guarantees a clean result, so the test is the check.

> **Key Takeaways**

> - **Your public IP is the one that matters.** If a [WebRTC page](https://dnsleaktest.com/webrtc.html) shows it while a VPN is on, that’s a leak.

> - **Proxies don’t always cover WebRTC.** When direct internet access is allowed, [WebRTC’s STUN checks bypass the proxy](https://www.rfc-editor.org/rfc/rfc8828).

> - **Switching WebRTC off has a cost.** [WebRTC-based services may be affected](https://chromewebstore.google.com/detail/webrtc-leak-prevent/eiadekoaikejlgdbkbdfeijglgfdalml), so compare it with controlling what WebRTC reports.

> - **A clean result isn’t a clean identity.** Timezone, language and geolocation still need to match the proxy.

## What Is a WebRTC Leak and How Does It Happen?

A WebRTC leak happens when a browser’s WebRTC connection setup reveals an IP address you expected a proxy or VPN to hide. WebRTC gathers ICE candidates, including a public address learned from a STUN server over UDP. That address can be your real one if the traffic never went through the proxy.

![Image generated](https://api.birchseek.com/m/p46qMRkD8ckwdDVI-zq96dSNYc0AmDCV.webp)

WebRTC is the browser feature behind in-browser calls, and a page starts it with `new RTCPeerConnection()`. The browser then runs ICE (Interactive Connectivity Establishment), which [RFC 8445](https://www.rfc-editor.org/rfc/rfc8445) describes as a protocol for NAT traversal for UDP-based communication.

ICE collects candidates, each one an address a peer could use to reach you, and hands them to the page through `icecandidate` events. Two candidate types matter here:

- **Host candidate:** an address on one of your own network interfaces, such as a LAN address.

- **srflx (server reflexive) candidate:** your public address as a STUN server sees it. [RFC 8489](https://www.rfc-editor.org/rfc/rfc8489) says STUN lets an endpoint “determine the IP address and port allocated to it by a NAT.”

The STUN Binding request and its response usually travel over UDP, outside the web requests a proxy handles.

The page, not the browser, picks the STUN server. Per [MDN’s RTCPeerConnection reference](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection), a connection created without `iceServers` has no STUN or TURN server available:

```
new RTCPeerConnection(); // no srflx candidate
new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.example.org:3478" }]
}); // can return an srflx candidate
```

That’s why a [WebRTC leak test](https://donutbrowser.com/tools/webrtc-leak-test/) supplies its own STUN server. Without one, the test would have no public address to show.

[RFC 8828](https://www.rfc-editor.org/rfc/rfc8828), WebRTC IP Address Handling Requirements, is the standards-level answer. It defines four handling modes, from “Enumerate all addresses” to forcing traffic through a proxy.

## Does mDNS Hide Your IP in WebRTC Leaks?

**mDNS obfuscation hides your local network address from websites, but it does not hide your public address.** It addresses local-address exposure only.

A _host candidate_ is your device’s address on your own network, such as `192.168.1.20`. The [IETF document on mDNS and ICE candidates](https://datatracker.ietf.org/doc/draft-ietf-rtcweb-mdns-ice-candidates/) says it describes a way to share local addresses while preserving privacy, by “concealing IP addresses with dynamically generated Multicast DNS (mDNS) names.”

In practice, a site sees a random name ending in `.local` instead of the number.

A _srflx candidate_ (server reflexive) is the public address a STUN server sees when your browser contacts it. mDNS doesn’t touch it, because that address is already public.

So read your result in two parts:

- **A `.local` host candidate** is not a leak. It’s the obfuscation working.

- **A srflx address that matches your proxy or VPN** is a pass.

- **A srflx address that is your real ISP IP** is a leak.

Whether you see a raw local number or a `.local` name depends on whether your browser implements this obfuscation. Run the [WebRTC leak test](https://donutbrowser.com/tools/webrtc-leak-test) in the browser and profile you actually use, and check which candidate types appear.

## WebRTC Leak With an HTTP Proxy, SOCKS5 or VPN: What Differs?

A proxy leak and a VPN leak have different causes: a proxy covers only what the app sends to it, while a VPN covers whatever your system routes into the tunnel.

| Proxy or tunnel type | WebRTC path | What to set |
| --- | --- | --- |
| HTTP/HTTPS proxy | Page requests use the proxy; STUN checks can go direct | Chrome policy `disable_non_proxied_udp`, then retest |
| SOCKS5 | Depends on provider UDP support | Ask the provider, set `disable_non_proxied_udp` if unsure, retest |
| WireGuard, full tunnel | Follows the system routes into the tunnel | Check IPv4 and IPv6 routes, retest |
| WireGuard, split routes or no IPv6 route | Depends on routes, a real address can appear | Route all traffic, close the IPv6 gap, retest |

**HTTP and HTTPS proxies** carry web requests over TCP. [RFC 8828](https://www.rfc-editor.org/rfc/rfc8828) states the gap: when direct internet access is permitted, “WebRTC’s STUN checks will bypass the proxy and reveal the public IP address of the client.”

**SOCKS5** is different on paper. [RFC 1928](https://www.rfc-editor.org/rfc/rfc1928) defines the UDP ASSOCIATE command, which it describes as “used to establish an association within the UDP relay process to handle UDP datagrams.”

[RFC 8828](https://www.rfc-editor.org/rfc/rfc8828) notes that all HTTP and most SOCKS proxies do not support UDP. Check with your provider, and don’t assume a SOCKS5 port means UDP works. The [proxy guide for anti-detect browsers](https://donutbrowser.com/proxies-for-anti-detect-browsers) covers choosing one per profile.

**A full-tunnel VPN** sends traffic through system routes, so WebRTC UDP usually travels inside the tunnel too. The browser needs no special setting for that. This is why a VPN often passes where an HTTP proxy fails.

**Split tunneling** breaks this. If the browser’s traffic, or just the STUN traffic, takes the normal route, your real address shows up.

**IPv6** needs its own check. Confirm that your tunnel config routes IPv6, or that IPv6 is off, before you trust a clean IPv4 result.

After any change, run the [WebRTC leak test](https://donutbrowser.com/tools/webrtc-leak-test) in the exact profile and proxy setup. A `.local` host candidate is fine. A real ISP address is a leak.

- **Best for HTTP/HTTPS proxies:** simple web tasks, paired with a policy that blocks non-proxied UDP.

- **Best for SOCKS5:** setups where the provider confirms UDP ASSOCIATE in writing.

- **Best for a full-tunnel WireGuard VPN:** whole-profile coverage, if both address families are routed.

- **Best for split routes:** only when you’ve tested every route and still see no real address.

## How Do You Read a WebRTC Leak Test Result?

You read a WebRTC leak test by comparing every address it shows with the one proxy or VPN IP that profile should have. Run the [WebRTC leak test](https://donutbrowser.com/tools/webrtc-leak-test) first, then the [DNS leak test](https://donutbrowser.com/tools/dns-leak-test) in the same profile.

- **Proxy or VPN IP shown: pass.** The WebRTC address matches the IP your proxy or VPN gives that profile.

- **Real ISP IP shown: leak.** [DNSLeakTest.com](https://dnsleaktest.com/webrtc.html) says: “If any of the IP Addresses displayed above is your public IP Address and you are using a VPN service, then you have a WebRTC leak.” The same logic applies to a proxy.

- **`.local` host candidate: fine.** It’s a masked local address, not your public IP, so you don’t need to act.

- **IPv6 address shown: check it.** If it belongs to your ISP instead of your proxy or VPN, it’s a leak, even when the IPv4 line looks clean.

- **Timezone or geolocation mismatch: a separate problem.** WebRTC settings don’t fix it, and a clean WebRTC result doesn’t prove the profile is consistent.

A worked example: a profile uses a Berlin proxy, and WebRTC shows that Berlin IP, so it passes. The profile reports the `Europe/Prague` timezone, though. That is still a mismatch, because the browser exposes a named zone, not just a UTC offset.

If you run many profiles, give each one a single story: one WebRTC-visible IP, the same proxy IP, one timezone and one language.

## How Do You Fix a WebRTC Leak in Firefox, Chrome, Brave and Tor?

You fix a WebRTC leak in Firefox, Chrome, Brave and Tor by turning WebRTC off or by limiting which network addresses it uses, and each browser has its own switch with its own cost. Pick the one whose breakage you can live with, then retest with the [WebRTC leak test](https://donutbrowser.com/tools/webrtc-leak-test).

### Firefox: turn WebRTC off

[BrowserLeaks documents](https://browserleaks.com/webrtc) the exact Firefox preference that does this.

1. Type `about:config` in the address bar, press Enter and accept the warning.

2. Search for `media.peerconnection.enabled`.

3. Double-click it so the value reads `false`.

4. Reload the leak test. Local and public candidates should be gone.

**Cost:** WebRTC-based services, such as in-browser calls on Google Meet or Discord web, may stop working.

### Chrome: set the IP handling policy

Chrome has no settings page for this, so you set it from an extension that requests the `privacy` permission. [Chrome for Developers](https://developer.chrome.com/docs/extensions/reference/api/privacy) lists four values for `webRTCIPHandlingPolicy`, and [Chrome’s WebRtcIPHandling policy definition](https://chromium.googlesource.com/chromium/src/+/main/components/policy/resources/templates/policy_definitions/WebRtc/WebRtcIPHandling.yaml) describes them:

- `default_public_and_private_interfaces`: WebRTC “will only use the interface connecting to the public Internet, but may connect using private IP addresses.”

- `default_public_interface_only`: WebRTC “will only use the interface connecting to the public Internet, and will not connect using private IP addresses.” It does not hide your public IP.

- `disable_non_proxied_udp`: WebRTC “will use TCP on the public-facing interface, and will only use UDP if supported by a configured proxy.”

1. Create a folder with a `manifest.json` that sets `"manifest_version": 3` and `"permissions": ["privacy"]`. Current Chrome extensions [must use Manifest V3](https://chromewebstore.google.com/detail/webrtc-leak-prevent/eiadekoaikejlgdbkbdfeijglgfdalml).

2. Add a background service worker containing:

```
chrome.privacy.network.webRTCIPHandlingPolicy.set({
  value: 'disable_non_proxied_udp'
});
```

1. Open `chrome://extensions`, switch on Developer mode and choose Load unpacked.

2. Retest in that profile with the proxy on.

If your proxy doesn’t carry UDP, this policy leaves WebRTC no media path, so calls will fail. That is the trade for not leaking.

The Chrome Web Store page for WebRTC Leak Prevent, which uses “the official API”, warns that “WebRTC-based services may be affected by this extension.”

### Brave

Brave is Chromium-based. Check Brave’s help center for its WebRTC IP handling policy setting before you install an extension. **Cost:** the same as Chrome, since the strictest option stops non-proxied UDP.

### Tor Browser

Tor is built for anonymity, not for managing profiles with separate proxies. Don’t use it as a WebRTC fix for a multi-profile setup, and follow the Tor Project’s documentation for what it does with WebRTC.

Don’t disable JavaScript to fix this. It breaks most sites and is a far louder signal than a WebRTC setting.

## Should You Disable WebRTC or Control What It Reports?

**Control what WebRTC reports in most multi-profile setups, and disable it only in a browser where you never need in-browser calls.** Both choices have a cost.

**Disabling** removes the leak, and it also breaks Google Meet and similar in-browser calls. It can look odd too: [BrowserLeaks](https://browserleaks.com/webrtc) runs a check for `RTCPeerConnection` and `RTCDataChannel` support, so a browser with neither stands out from the usual setup.

**Controlling or spoofing** keeps the API present. The values it returns match the profile’s proxy, so the page sees one consistent story: one IP, one timezone, one language.

The IP isn’t the only WebRTC signal. [MDN says](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/enumerateDevices) `navigator.mediaDevices.enumerateDevices()` returns “a list of the currently available media inputs and outputs, such as microphones, cameras, headsets, and so forth.”

BrowserLeaks also shows a Session Description (SDP) log next to its Media Devices section. Both feed your [browser fingerprint](https://donutbrowser.com/browser-fingerprinting), so they should look like a real device, not a blank.

### Where Donut Browser fits

[Donut’s Wayfern docs](https://donutbrowser.com/docs/wayfern) say Wayfern, its Chromium-based engine, sets fingerprint values, WebRTC included, at the C++ level, not with scripts injected into the page. [The pricing page](https://donutbrowser.com/pricing/) lists full fingerprint protection on the free plan, at the same quality as paid plans.

Each profile can have its own proxy or a WireGuard config. Donut [doesn’t sell proxies](https://donutbrowser.com/proxies-for-anti-detect-browsers/), so you bring your own.

Donut doesn’t promise your accounts won’t be banned. Verify with the [WebRTC leak test](https://donutbrowser.com/tools/webrtc-leak-test) inside the exact profile and proxy you’ll use.

## How Do You Verify a WebRTC Fix in Your Exact Profile Setup?

You verify a WebRTC fix by retesting inside the exact profile, with the exact proxy or VPN attached, because a test in your default browser says nothing about that setup.

1. **Open the test inside the same profile.** Launch the profile you fixed, with its proxy or WireGuard config attached, then load the [WebRTC leak test](https://donutbrowser.com/tools/webrtc-leak-test). A different window or profile proves nothing.

2. **Confirm the exit IP first.** Check it on the [IP lookup tool](https://donutbrowser.com/tools/what-is-my-ip). If it isn’t the proxy’s address, fix the proxy before reading any WebRTC output.

3. **Read every candidate.** Look for `srflx` (public address), `host` entries ending in `.local`, and any IPv6 address. A `.local` host is fine; a `srflx` or IPv6 address that isn’t your proxy or VPN address is a leak.

4. **Compare against the profile identity.** A timezone or language that doesn’t fit the exit IP’s region is a separate mismatch. Fix it even when WebRTC is clean.

5. **Check media devices and the SDP log.** Both appear beside the IP fields on BrowserLeaks and are part of what the page can read.

6. **Retest after every change.** Rerun steps 1 to 5 after you swap the proxy, edit the profile, or update the browser.

## Reading WebRTC output in Playwright or Puppeteer

You read WebRTC output in Playwright or Puppeteer by collecting ICE candidates inside `page.evaluate` with standard browser APIs. Replace the `stun:` URL with a STUN server you choose.

```
const candidates = await page.evaluate(async () => {
  const found = [];
  const pc = new RTCPeerConnection({
    iceServers: [{ urls: "stun:stun.example.org:3478" }],
  });
  pc.createDataChannel("probe");
  pc.onicecandidate = (event) => {
    if (event.candidate) found.push(event.candidate.candidate);
  };
  await pc.setLocalDescription(await pc.createOffer());
  await new Promise((resolve) => setTimeout(resolve, 3000));
  pc.close();
  return found;
});
```

Assert that no candidate contains your real IP. The same call works in Puppeteer’s `page.evaluate`.

To drive a Donut Browser profile this way, you need a CDP port. The [local REST API docs](https://donutbrowser.com/docs/rest-api) list a launch call that starts a profile and returns its CDP port, and Donut’s [Pro page](https://donutbrowser.com/pro/) describes launching a profile with one API call and attaching Playwright or Puppeteer over CDP. For the wider setup, see [browser automation with Donut Browser](https://donutbrowser.com/use-cases/automation/).

## Frequently Asked Questions

### How do I stop a WebRTC leak?

**Make sure WebRTC can’t send UDP outside your proxy or VPN.** In Chrome, [set the WebRTC IP handling policy](https://chromewebstore.google.com/detail/webrtc-leak-prevent/eiadekoaikejlgdbkbdfeijglgfdalml) to `disable_non_proxied_udp` with an extension. In Firefox, [set `media.peerconnection.enabled`](https://browserleaks.com/webrtc) to false.

Then retest in the same profile and proxy setup. Expect in-browser calls such as Meet to break.

### Does a VPN stop WebRTC leaks?

**A full-tunnel VPN usually does, but it isn’t a guarantee.** It captures traffic through system routes, so WebRTC’s own sockets go through the tunnel too. Run the [WebRTC leak test](https://donutbrowser.com/tools/webrtc-leak-test) with the VPN on to confirm.

### Is a `.local` address in my WebRTC result a leak?

**No, a `.local` host candidate is mDNS hiding your local address, not your public IP.** A [leak means your public IP](https://dnsleaktest.com/webrtc.html) shows while a VPN or proxy is on. A public srflx address from a STUN server is the one that counts.

### Why does my test pass on a VPN but fail on a SOCKS5 proxy?

**A VPN covers system traffic, while a SOCKS5 proxy covers only what the browser sends to it.** [WebRTC’s STUN checks can bypass the proxy](https://www.rfc-editor.org/rfc/rfc8828), and its UDP follows the proxy only if the proxy supports UDP ASSOCIATE. If it doesn’t, restrict WebRTC with the Chrome policy or the Firefox setting above.

## Next Steps: Test, Fix and Retest Your WebRTC Setup

**Today:** Turn your proxy on and run the [WebRTC leak test](https://donutbrowser.com/tools/webrtc-leak-test). Your proxy IP is a pass, your real ISP address is a leak, and a `.local` host candidate is fine.

**This week:** Apply the fix for your browser or profile. Then retest in the exact profile with the exact proxy attached, and check that timezone and language match the proxy’s location.

**Ongoing:** Retest after you change a proxy or update the browser.

To run the test in a separate profile, [download Donut Browser](https://donutbrowser.com). It’s open source, has zero telemetry, and runs on macOS, Windows and Linux. Bring your own proxy, open the WebRTC leak test inside a profile, and see what a site sees.

## Sources

[WebRTC Leak Test](https://dnsleaktest.com/webrtc.html) · [WebRTC Leak Prevent - Chrome Web Store](https://chromewebstore.google.com/detail/webrtc-leak-prevent/eiadekoaikejlgdbkbdfeijglgfdalml) · [RFC 8445: Interactive Connectivity Establishment (ICE)](https://www.rfc-editor.org/rfc/rfc8445) · [RFC 8489: Session Traversal Utilities for NAT (STUN)](https://www.rfc-editor.org/rfc/rfc8489) · [RTCPeerConnection: RTCPeerConnection() constructor - MDN](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection) · [RFC 8828: WebRTC IP Address Handling Requirements](https://www.rfc-editor.org/rfc/rfc8828) · [WebRTC Leak Test - BrowserLeaks](https://browserleaks.com/webrtc) · [Wayfern docs - Donut Browser](https://donutbrowser.com/proxies-for-anti-detect-browsers/). Every other source is linked where the article cites it.

## On this page

- What Is a WebRTC Leak and How Does It Happen?

- Does mDNS Hide Your IP in WebRTC Leaks?

- WebRTC Leak With an HTTP Proxy, SOCKS5 or VPN: What Differs?

- How Do You Read a WebRTC Leak Test Result?

- How Do You Fix a WebRTC Leak in Firefox, Chrome, Brave and Tor?

- Firefox: turn WebRTC off

- Chrome: set the IP handling policy

- Brave

- Tor Browser

- Should You Disable WebRTC or Control What It Reports?

- Where Donut Browser fits

- How Do You Verify a WebRTC Fix in Your Exact Profile Setup?

- Reading WebRTC output in Playwright or Puppeteer

- Frequently Asked Questions

- How do I stop a WebRTC leak?

- Does a VPN stop WebRTC leaks?

- Is a .local address in my WebRTC result a leak?

- Why does my test pass on a VPN but fail on a SOCKS5 proxy?

- Next Steps: Test, Fix and Retest Your WebRTC Setup

- Sources