A WebRTC leak is a browser exposing an IP address or network path outside the proxy, VPN or privacy boundary you intended. It happens when the browser's ICE agent gathers candidates or runs STUN/TURN connectivity checks over a route you did not mean to use (see RFC 8445 and RFC 8828). This guide is for people running a VPN, proxy or anti-detect browser profile who want to check what their browser announces. The workflow has five phases: baseline (steps 1-3), detection (steps 4-6), interpretation (steps 7-9), one mitigation (steps 10-13), and verification of calls and retesting (steps 14-15).
What a WebRTC leak is, and what it is not
WebRTC is a W3C/IETF standard for real-time audio, video and peer-to-peer data in the browser. It is not a vulnerability in itself. The exposure comes from how connection setup discovers and reports network addresses. Chrome and Firefox shipped WebRTC in the early 2010s and Safari added it later; current Edge is Chromium-based and inherits Chrome's implementation. Check MDN's compatibility tables for exact versions rather than relying on a single date. Availability of the API is separate from what it reveals: a page can create a peer connection and read gathered candidates without a call starting. Host-candidate obfuscation with mDNS is described in the IETF mDNS draft, which also discusses cases where a page that has been granted camera or microphone access may see real host addresses. How each browser and version handles that case differs, so test it instead of assuming it. What you see depends on browser, OS, VPN and proxy setup, so a result can be your real public IP, your VPN or proxy address, or no useful candidate data at all.
Full-tunnel VPN versus browser-only proxy
A correctly configured full-tunnel VPN sends all IP traffic from the device through a tunnel interface, including the UDP packets of the browser's ICE agent. WebRTC does not automatically bypass it, and a STUN query in that setup returns a tunnel-side address. Exposure appears when the boundary has gaps: split tunneling or excluded apps, a kill switch that fails open, IPv6 that is not tunneled, or a proxy configured only inside the browser. A browser or extension proxy typically carries HTTP, HTTPS or SOCKS TCP traffic, while WebRTC's UDP sockets can bypass it unless the browser's WebRTC IP-handling policy forbids non-proxied UDP (RFC 8828 describes this as its most restrictive mode). A proxy-only extension changes where HTTP(S) requests go, not WebRTC behavior. An extension that also holds Chrome's privacy permission can set webRTCIPHandlingPolicy, so check which of the two kinds you installed.
How ICE gathers candidates
A page creates an RTCPeerConnection, the browser gathers candidates, STUN Binding requests go to any configured STUN servers, TURN allocations are requested if the page supplies TURN servers, and candidates are validated through connectivity checks (RFC 8445). The iceServers list is empty by default, and a script can supply its own STUN or TURN servers. Detection pages do exactly that, so no call has to be placed.
The four candidate types and what each means
A candidate type describes how an address was learned, not whether the address is private or public: a host candidate can hold a private LAN address, an mDNS name, or a globally routable interface address such as a public IPv6 address, while srflx, prflx and relay candidates are learned from other parties. Always classify the address itself and the interface or server it came from.
| Candidate type | Where it comes from | What it means for exposure |
|---|---|---|
| Host | Addresses assigned to local, virtual or VPN network interfaces. It may be a private address such as 192.168.1.20, an mDNS name ending in .local if the browser obfuscates it, or a globally routable IPv4 or IPv6 address on an interface. | A private address reveals local network details and is a fingerprinting input; common private ranges are reused across unrelated networks, so a LAN address alone does not identify a device or user. A globally routable host address (often IPv6) can be your real public address with no STUN query involved, and must be compared against your baseline. See steps 9 and 11. |
| Server-reflexive (srflx) | The mapped address a STUN server observed on the route the request actually took (RFC 8489). | Shows the address visible on that route. Behind a working full-tunnel VPN this is a VPN-side address, not your ISP address. It becomes a concern when it equals your real baseline address, or when it differs from baseline but cannot be attributed to your intended egress. |
| Peer-reflexive (prflx) | Learned during connectivity checks, when a remote peer sees your traffic from a mapped address not yet known to you (RFC 8445). | Requires an actual remote peer, so a single-page test normally does not display it. Treat it like srflx if you ever see one. |
| Relayed | A transport address allocated on a TURN server (RFC 8656). It appears only if the page supplies TURN servers. | The remote peer sees the TURN server's address instead of yours, so it masks your address from that peer. It does not show how your client reached the TURN server, and it does not by itself route your traffic through your proxy or VPN. The TURN server sees your source address on whatever route that connection used. Address masking and traffic routing are different properties. |
Quick decision table
| What you observe | Likely cause | Where to fix it |
|---|---|---|
| srflx equals baseline IPv4, using a browser-only proxy | WebRTC UDP is not forced through the proxy | Set the WebRTC IP-handling policy: step 11 (Firefox) or step 12 (Chrome/Edge) |
| srflx equals baseline IPv4, using a full-tunnel VPN | Split tunneling, app exclusion or kill switch failing open | Fix the VPN configuration (step 10), not the browser |
| IPv6 host or srflx equals IPv6 baseline while IPv4 looks clean | IPv6 not tunneled | Enable IPv6 in the VPN or disable IPv6 on the interface (step 10) |
| Only private or mDNS host candidates | LAN detail and fingerprinting exposure, not a public IP leak | Optional restriction: steps 11 or 12 |
| Relay address, or srflx not attributable | Route to the TURN or STUN server is unknown | Packet capture: steps 6 and 8 |
| Safari or an anti-detect profile | Controls differ from the others | Step 13 |
Scope and limitations
This guide did not run browser-version tests for 2026; you record your own versions and conditions in step 1. Setting names and policy values come from the linked Mozilla and Chrome documentation and can change between versions, so confirm them in your build. The IP addresses in the examples are documentation addresses, not measurements. A test page shows only what that page's STUN/TURN configuration triggers. A single clean result, or an empty candidate list, cannot establish protection against every site, network or later browser update. The outcome of this guide is 'no exposure observed under the tested conditions', not proof of anonymity.
Primary references
- RFC 8445: Interactive Connectivity Establishment (ICE)
- RFC 8489: Session Traversal Utilities for NAT (STUN)
- RFC 8656: Traversal Using Relays around NAT (TURN)
- RFC 8828: WebRTC IP Address Handling Requirements
- IETF draft: Using mDNS to protect WebRTC ICE candidates
- MDN: WebRTC connectivity
- Chrome extensions: chrome.privacy API (webRTCIPHandlingPolicy)
Before you start
Estimated time: 45 minutes.
- The exact browser and profile you will use, with its version number, OS version, and the proxy or VPN attached to it. WebRTC behavior varies by browser, OS and setup, so only results from that same combination apply to it.
- Your proxy or VPN credentials, and the provider's documentation on its exit addresses or ranges, tunneling mode (full tunnel or split), IPv6 handling and DNS policy. You need these to interpret results.
- A note file with fields for: test conditions, baseline real IP (IPv4 and IPv6, each with the method and time used), ISP, local IP range, session exit IP, and configured DNS policy.
- Three public test pages: browserleaks.com/webrtc (candidate list), ipleak.net (IP, IPv6 and DNS) and dnsleaktest.com (DNS). These are third-party sites, and every visit sends them your connection's source address.
- Wireshark (or tcpdump on macOS/Linux) on the tested device, with permission to capture on network interfaces. It is optional for srflx checks but required for any verdict on relay candidates or unattributed addresses.
- Permission to change browser settings on the tested profile, and a note of the current value of every setting before you change it, so you can roll back.
- Only if you already use one: an anti-detect browser profile that exposes a WebRTC setting. No specific product is recommended here because this guide did not compare them, and a proxy provider supplies an exit address but does not fix WebRTC exposure, which is browser behavior.
Step-by-step instructions
Baseline: record the test conditions
Results are valid only for the conditions that produced them, so write them down first. In your note, record the browser name and exact version (Chrome > About Google Chrome, Firefox > Help > About Firefox), OS and version, VPN client and version, proxy type (HTTP, HTTPS or SOCKS5), whether the VPN is full-tunnel or split-tunnel, whether IPv6 is tunneled, and the intended DNS policy (VPN-provided, remote proxy resolution, or a named DoH provider).
Expected result: A written conditions record that lets you reproduce the test after a browser or VPN update.
Baseline: obtain your real public IP, separately for IPv4 and IPv6
A baseline must come from the tested device with no tunnel, because IPv6 addresses are usually specific to a device (and often rotate through temporary addresses) while IPv4 is often shared across a household. Best method: disable the VPN, proxy and any proxy extension on the tested device, open ipleak.net, and copy the IPv4 address, IPv6 address (if shown) and ISP. This sends a request from your unprotected connection to a third-party site, which it and your ISP can see. If you cannot disconnect, you can get only an IPv4 baseline from your router's status page (the WAN address) or your ISP account page, or from a second device on the same network with no tunnel.
Expected result: A baseline for each address family, with the method and time noted. A router WAN address can differ from what websites observe under carrier-grade NAT. A second device or router page does not establish the tested device's IPv6 address; if you could not measure IPv6 on the tested device, mark the IPv6 baseline INCONCLUSIVE and treat any IPv6 verdict as provisional.
Baseline: record the session exit IP with your tool on
Reconnect the VPN or proxy and, in the profile you will actually use, open ipleak.net. Record the IP, ISP/ASN, reported country and the time in the note. This is the session exit IP, the reference for step 7.
Expected result: A time-stamped exit IP for this session. Rotating proxy pools and multi-hop VPNs can legitimately give different exit IPs on different runs, so also note the provider's stated rotation behavior.
Detection: run the WebRTC test in the exact profile
With the VPN or proxy on, open browserleaks.com/webrtc in the profile from step 3, wait for the page to finish gathering, and copy every listed candidate into the note, including type, address, address family and protocol. Reload the page and repeat once.
Expected result: A candidate list from two runs. Differences between runs can come from rotating egress, mDNS names regenerated per session, interface changes, gathering timing, or STUN server responses; note each difference and do not assume which cause applies.
Detection: annotate each candidate by type, family and protocol
Label each line in the note with type, address family, protocol and address. Illustrative lines using documentation addresses: 'typ host 192.168.1.20 UDP' is a host candidate, IPv4, a raw private LAN address. 'a1b2c3d4-0000-4000-8000-0123456789ab.local UDP' is a host candidate with an mDNS name. 'typ host 2001:db8:a:0:1c2d::9 UDP' is a host candidate with a globally routable IPv6 address. 'typ srflx 203.0.113.45 UDP' is server-reflexive, IPv4, the address a STUN server saw. 'typ srflx 2001:db8:a::1234 UDP' is the same for IPv6. 'typ relay 198.51.100.77 UDP' is a TURN relayed address.
Expected result: Every candidate has four labels: type, address family, protocol and address. Test IPv4 and IPv6 separately, because a clean IPv4 result says nothing about IPv6.
Detection: capture STUN and TURN traffic on both interfaces
A capture shows which route the packets actually took, and it has to be taken at two layers. With a full-tunnel VPN, the physical interface (Wi-Fi or Ethernet, for example en0 or eth0) carries the outer, encrypted tunnel packets, while the tunnel interface (for example utun, wg0, tun0 or a TAP adapter) carries the inner, plaintext packets. In Wireshark, start captures on both interfaces from the Capture > Options window, then reload browserleaks.com/webrtc. Use the display filter 'stun || udp.port == 3478 || udp.port == 19302 || udp.port == 5349' on each. In tcpdump use 'sudo tcpdump -ni <interface> udp port 3478 or udp port 19302', and add 'or tcp port 5349' for TURN over TLS.
Expected result: STUN Binding requests visible on the tunnel interface only, with the tunnel-side source address, are consistent with working tunneling. Plaintext STUN packets to a non-VPN destination on the physical interface, with your real source address, are evidence of a leak. On the physical interface you should otherwise see only the encrypted packets addressed to your VPN server. Non-standard STUN ports or TURN over TCP 443 will not match these filters, so an empty capture is not proof of no leak.
Interpretation: classify each srflx candidate
A srflx address shows how the STUN server saw you on one route, so judge it against session-specific evidence. CONFIRMED EXPOSURE: it equals your baseline real IP in the same address family while the tunnel or proxy was supposed to carry the traffic. MATCHES SESSION EXIT: it equals the exit IP recorded in step 3 in the same session, ideally with the step 6 capture showing the STUN request on the tunnel interface. UNATTRIBUTED: it differs from baseline and from the session exit IP; ASN or provider range membership is supporting evidence only, because it cannot show that this is your intended exit rather than another customer's or another route of the same provider. INCONCLUSIVE: no srflx candidate appears, the page failed to load, or only one address family was tested.
Expected result: A labeled verdict per srflx address and family. An UNATTRIBUTED result is a reason to investigate with the provider or the capture, not automatic proof of real-IP exposure.
Interpretation: classify each relay candidate separately from client egress
A relay address belongs to the TURN server and says nothing about how your client reached it. Skip this step if no relay candidate appeared, as test pages that supply only STUN servers produce none. Otherwise, find the TURN server address and port from the page, then use the step 6 capture to read the client-to-TURN packets: which interface carried them, the destination address, and your source address. Assign RELAY ROUTED VIA TUNNEL (packets only on the tunnel interface, tunnel-side source address), RELAY CLIENT ROUTE EXPOSED (packets to the TURN server on the physical interface with your real source address), or INCONCLUSIVE (no capture, or TURN over a port your filter did not cover).
Expected result: A route verdict for each relay candidate that rests on the client-to-TURN capture. STUN-only capture evidence does not establish the route to TURN, and the relay address does not show it either.
Interpretation: classify the host candidates by the address itself
Host candidates come from your interfaces, so classify the address, not the type. Private address (for example 192.168.x.x, 10.x.x.x, or the tunnel interface's own 10.x address): LAN detail and fingerprinting input, not a public IP leak. mDNS name ending in .local: the browser obfuscated the address; record it as OBFUSCATED. Globally routable address (public IPv6, or public IPv4 on a device with a direct public address): compare it with your baseline for that family. If it equals the baseline, mark CONFIRMED EXPOSURE against the boundary you intended. If it is a different public IPv6 address (for example a temporary address), mark UNATTRIBUTED and check whether it belongs to the physical interface or the tunnel interface.
Expected result: Each host candidate has a class: private, obfuscated, or routable with a verdict. A tunnel interface address of a VPN that assigns a public IPv6 address is an intended exposure, which is why the intended boundary matters.
Mitigation: choose one fix from the decision table and apply any network-level fix first
Browser settings can hide addresses from pages but cannot repair a broken tunnel, so fix the network layer first if your verdicts point there. Use the quick decision table in the introduction. For split tunneling or an app exclusion, remove the browser from the exclusion list in the VPN client. For a kill switch that fails open, enable the always-on or block-traffic-outside-VPN option if your client has one. For untunneled IPv6, enable IPv6 inside the VPN client if the provider supports it, or disable IPv6 on the network adapter in OS network settings. Note the previous value of each setting you change.
Expected result: A written list of changes with before and after values. If your only findings were private or mDNS host candidates, skip ahead to the browser step for your browser.
Mitigation (Firefox only): restrict ICE candidate gathering in about:config
Firefox has no Settings-page toggle for this, so change preferences in about:config. Open a new tab, enter about:config, select Accept the Risk and Continue, then search for each preference. 'media.peerconnection.ice.default_address_only' set to true limits gathering to the default-route interface. 'media.peerconnection.ice.no_host' set to true removes host candidates (including mDNS names). 'media.peerconnection.ice.proxy_only_if_behind_proxy' set to true restricts candidates to the proxy path when a proxy is configured. 'media.peerconnection.enabled' set to false disables WebRTC entirely and is a last resort, since it breaks video calls. Set one preference at a time, and restart the browser after changes.
Expected result: The changed preference shows as bold (modified) in about:config. Names and defaults can differ by version, so if a name is missing in your build, search for 'peerconnection' and check Mozilla's documentation before using a different one. To roll back, click the Reset arrow next to the preference.
Mitigation (Chrome and Edge only): set webRTCIPHandlingPolicy through an extension
Chrome and Edge expose this policy through the chrome.privacy API (documented at developer.chrome.com), not through a Settings page. Install an extension that requests the privacy permission and exposes a WebRTC IP handling option (review its permissions on chrome://extensions > Details), or write a short local extension that sets chrome.privacy.network.webRTCIPHandlingPolicy. The documented values are 'default', 'default_public_and_private_interfaces', 'default_public_interface_only' (do not expose private addresses), and 'disable_non_proxied_udp' (use UDP only through a proxy that supports it, otherwise TCP only or no WebRTC media). Pick 'default_public_interface_only' for a full-tunnel VPN and 'disable_non_proxied_udp' for a browser-only proxy.
Expected result: The extension reports the active policy, and the Chrome privacy API reports it as controlled by the extension. A proxy-only extension without the privacy permission does not change WebRTC behavior. Edge uses the same extension model. To roll back, disable or remove the extension at chrome://extensions (or edge://extensions) and restart the browser.
Mitigation (Safari or an anti-detect profile): use what that product exposes
For Safari, no documented user setting restricts WebRTC candidates in the way Firefox's preferences do, so rely on the full-tunnel VPN fix from step 10 and on the network-level check. Safari's Develop menu includes WebRTC-related experimental toggles; do not change them unless you can name what each does, and record the original value before any change. For an anti-detect browser profile, open the profile's settings and find its WebRTC option (labels vary by product, such as real, replaced or altered, and disabled). Choose the mode that reports only the profile's proxy address, or disable WebRTC if calls are not needed.
Expected result: The setting is recorded with its before and after values. A replaced or altered mode changes what pages are told, not the route your packets take, so confirm it with the step 6 capture and not only with the test page.
Verify: check that the calls you actually use still work
Restrictive WebRTC settings can break calls, so test one real use. Open a WebRTC call or meeting app you use (or a public camera and microphone test page), grant camera and microphone permission only to that site, and start a test call or loopback. Do this once with the mitigation on. Then, if the call fails, check whether the failure is the setting: roll back only this setting, repeat, and note the result.
Expected result: Each tool is marked WORKS, DEGRADED (for example TCP relay only, higher latency) or BROKEN. With 'disable_non_proxied_udp' or the Firefox 'no_host' preference, calls through peer-to-peer paths may fail or fall back to a relay; that is the expected cost of the setting.
Retest: repeat steps 4 to 9 and record a before and after comparison
Repeat steps 4 to 9 with the same browser, version, profile, network and time-of-day notes, then record both runs side by side. Illustrative example with documentation addresses (not measured): baseline IPv4 203.0.113.45, baseline IPv6 2001:db8:a::1234, session exit 198.51.100.7 (IPv4 only). Before: srflx 203.0.113.45 (CONFIRMED EXPOSURE, IPv4), host 2001:db8:a::1234 (CONFIRMED EXPOSURE, IPv6), host 192.168.1.20 (private). Step 10 change: disable IPv6 on the adapter, since the VPN does not tunnel it. Step 11 change: set media.peerconnection.ice.default_address_only to true. After: srflx 198.51.100.7 (MATCHES SESSION EXIT, capture shows STUN only on the tunnel interface), no IPv6 candidates, no host candidate other than the tunnel address. Call test from step 14: WORKS.
Expected result: A table with test conditions, each candidate, its verdict before and after, each setting changed with its rollback value, and the date. The result you can state is 'no exposure observed under the tested conditions'. Retest after any browser, OS or VPN update, since defaults can change.
Troubleshooting
- The WebRTC public address matches my exit IP, but ipleak.net shows my real ISP.
- That is a routing failure, not a WebRTC one. Re-check that the proxy or VPN is attached to the profile you are testing, then re-run step 4.
- The test shows a 192.168.x.x host candidate and I cannot remove it.
- This is a lower-severity signal and not a public IP leak. Use a WebRTC control option or profile-level setting that hides or obfuscates local addresses, then re-test. A .local mDNS hostname is expected and fine.
- The leak disappeared but video calls no longer work.
- Disabling WebRTC trades compatibility for protection. Switch to a profile-level or extension-based setting that follows the proxy IP, or keep a separate browser without the restriction for calls.
- Results change between runs or between browsers.
- Results vary by browser, OS and VPN/proxy setup. Always test the exact profile in use and run the test at least twice after any change.
- The exit IP geolocates to the wrong country.
- Request a different exit from your provider and re-run steps 3 to 15. In our own proxy logs one exit out of the visible runs resolved to a different country than advertised, so a location mismatch is not always a WebRTC problem.
- DNS still points to my local ISP after I fix WebRTC.
- WebRTC is only one of three common leak routes. Enable DNS leak protection in the VPN or route DNS through the proxy, then repeat step 13.
