WebRTC Leak Test: Check Whether Your Real IP Leaks

WebRTC is the browser's built-in way to run calls, screen sharing and file transfers directly between two browsers. To connect, it gathers ICE candidates: every address another peer could reach you at. It learns your public address by asking a STUN server over UDP, and any script on the page can read the answer, with no permission prompt.

A proxy set in the browser or the system carries your web requests over TCP. WebRTC's STUN requests are UDP packets that leave your network directly, so the STUN server, and the page that reads its answer, sees your real public IP while every other request shows the proxy's. Browsers do not send WebRTC's UDP traffic through an HTTP or SOCKS5 proxy, so a proxy alone does not cover WebRTC; the fix is a browser or profile setting.

A VPN is different: it tunnels all of the device's traffic, UDP included, so STUN sees the VPN server's address. VPNs leak through WebRTC when they skip IPv6, when split tunneling leaves the browser out, or when the connection drops.

Local addresses are less of a problem today. Current browsers hide your device's address on the local network behind a random name ending in .local (mDNS), unless the page has camera or microphone permission, so the leak that matters is the public one.

The page opens a WebRTC connection that goes nowhere, with ProxyField's and Cloudflare's STUN servers, and collects every candidate your browser offers:

• Host candidates are your device's own addresses: a .local name, or a private IP if the browser shows it.
• Server-reflexive (srflx) candidates are the public addresses the STUN servers saw: the ones that can leak.
• Relay candidates come from a TURN relay server; the test lists them if any appear, and they are the relay's address.

Each public address gets its country and ISP from the DB-IP Lite databases, the same IP data as the IP checker, and is compared with the IP your browser used to load the page. If your network has IPv6, a STUN server can see a public IPv6 address even when your IPv4 traffic goes through the proxy, and that counts as a leak too. The raw list shows each candidate's type, protocol (UDP or TCP), address and port.

The examples use documentation addresses; yours will differ.

A private address does not reveal your public IP, but it tells a site about your network, such as your router's address range, and it adds detail to your fingerprint. An exposed private IP usually means an old browser, or a setting or extension that turned the .local names off.

The setting names below are the ones the apps show; labels can differ slightly between versions.

Chrome

Chrome has no WebRTC switch in its settings. Its WebRTC IP handling policy decides which network paths WebRTC may use, with 4 values: default, default_public_and_private_interfaces, default_public_interface_only and disable_non_proxied_udp. Only the last one keeps WebRTC off your direct connection: WebRTC may then use only the proxy or a relay, so no public address of yours shows up. You can set it with Chrome's WebRtcIPHandling enterprise policy, or with an extension that sets the policy. A setting that only hides local addresses, the public-interface-only value, still shows your real public IP behind a browser proxy.

Firefox

Open about:config. Setting media.peerconnection.enabled to false turns WebRTC off entirely: no leak, and no WebRTC calls. Setting media.peerconnection.ice.default_address_only to true limits WebRTC to your default network path, which hides other interfaces but not your public IP behind a browser proxy.

Edge

Edge is built on Chromium and handles WebRTC like Chrome: there is no switch in its settings, and the same 4 policy values are set through Edge's own group policy for WebRTC or through an extension.

Brave

Brave has the setting built in: Settings, Privacy and security, WebRTC IP handling policy. Choose Disable non-proxied UDP to keep WebRTC on the proxy, then press Run again here.

Safari

Safari hides local addresses and has no setting in its normal preferences to turn WebRTC off or route it through a proxy. Behind a proxy set in macOS or iOS network settings, its STUN requests still leave directly, so test with the proxy on; if your real IP shows, use a VPN that tunnels all traffic, or another browser for work through a proxy.

Phones

Most mobile browsers have no WebRTC switch, and the proxy setting of a Wi-Fi network does not cover WebRTC either. A VPN that tunnels all traffic is the reliable fix; test with it on.

Antidetect browsers set WebRTC per profile, and AdsPower, GoLogin, Dolphin Anty, Multilogin, Incogniton and BitBrowser each have the setting among the profile's fingerprint options. The usual modes:

• Replace the IP with the proxy's, called Altered, Replace, Forward or Based on IP depending on the app: page scripts see the proxy's IP as your public address, and this test shows No leak with the proxy on.
• Real: WebRTC works as in a normal browser, which behind a proxy means a leak.
• Disabled: WebRTC is off, and the test shows WebRTC is blocked. Some sites treat a browser without WebRTC as unusual, because ordinary browsers have it.

One caveat: if a mode only rewrites what page scripts can read while the STUN request still leaves your own connection, a site that runs its own STUN server can see where the request came from. A mode that sends WebRTC through the proxy, or Disabled, avoids that. Then match the rest of the profile to the proxy: time zone, language and geolocation based on the IP. Setup for each app: AdsPower, GoLogin, Dolphin Anty, Multilogin, Incogniton and BitBrowser.

More on what each one hides: proxy vs VPN and residential proxy vs VPN.

• STUN servers. Each test asks its own STUN servers, and a server reachable only over IPv4 cannot reveal an IPv6 address. This test uses ProxyField's and Cloudflare's.
• Timing. Gathering candidates takes a moment, and a test that reads too early misses some.
• Permissions. A site where you allowed the camera or microphone gets your local addresses without the .local names.
• Comparison. Some tests list addresses without comparing them with the IP they see over HTTP, and that comparison is what tells you whether an address is a leak.
• Rotation. A rotating proxy can show another exit IP on each page load, so compare the addresses within one run.

Your browser lists its cameras and microphones to any page; without permission it gives no names, only how many there are of each kind. The test shows those counts because they are part of your fingerprint: antidetect browsers set them per profile, and a count that does not fit the device, such as a laptop profile with no microphone, stands out. The page reads the counts and never asks for access.