"WebRTC Leaks: Why Your Real IP Shows Through Even Behind a Proxy"

If a DNS leak exposes "what you accessed", a WebRTC leak exposes something more direct — your real network exit IP.

What Is WebRTC

WebRTC (Web Real-Time Communication) is the browser's built-in real-time communication framework, used for in-page video calls, online meetings, and P2P file transfer. Google Meet and the Discord web app's voice and video both depend on it.

To establish P2P connections, WebRTC needs to collect the machine's network candidates — that is its design purpose in the first place.

The Leak Mechanism

WebRTC gathers candidates through a process called ICE. It enumerates:

1. Local adapter IPs (private addresses such as 192.168.1.100)
2. Public mapped addresses (obtained from STUN servers — "what I look like on the internet")

The problem is step 2 — STUN requests are sent by the browser directly from a UDP socket, and many proxy clients do not take over such traffic by default. Even with all your HTTP traffic going through the proxy, what STUN gets back is still the public mapping of your real exit.

Worse, JavaScript on a page can read these candidates through the RTCPeerConnection API.

The result — a page's script can obtain:

• Your real public IP (even while you are on a proxy)
• Your private IP range (enough to infer whether you are at the office, at home, or on public WiFi)

Detection and Browser Differences

In IPchase's fingerprint check, "WebRTC IP exposure" is one of the core checks. The implementation simply creates an RTCPeerConnection and checks whether the candidates it produces include a public IP that differs from the HTTP exit.

Where each browser stands today:

Browser	Default behavior
Chrome / Edge	Enabled by default; leakage depends on whether mDNS obfuscation applies
Firefox	Enabled by default; can be disabled in settings
Safari	Recent versions hide local IPs from web pages by default

Since 2018, Chrome has applied mDNS obfuscation to candidates (pages see xxxx.local instead of the real IP), so ordinary pages can no longer read your private IP. But the public STUN mapping can still leak in some scenarios, depending on proxy type and configuration.

How to Prevent It

Turn it off when unneeded (simplest)

If you rarely use in-browser video calls, just switch WebRTC off:

• Firefox — type about:config in the address bar → find media.peerconnection.enabled → set it to false
• Chrome / Edge — the browser itself has no switch; install an extension that disables WebRTC (such as WebRTC Limiter)
• iOS Safari — Settings → Safari → Advanced → under Reader & WebRTC, choose "Links only"

Let the proxy take over (more elegant)

The TUN mode of modern proxy clients intercepts UDP traffic as well, so STUN requests go out through the proxy and come back with the proxy-side mapped address. With TUN mode on, proxying and in-browser video calls can coexist.

One side note

With WebRTC off, web features that depend on it stop working — video conferencing, voice calls, and some online multiplayer games. Weigh that against your own usage.

Summary

The essence of a WebRTC leak — the browser collects your network addresses for P2P communication, and that collection can bypass a plain proxy's HTTP layer. Prevention — turn it off if you do not use it; if you do, let the proxy take over UDP (TUN mode).

To see whether you are already leaking, one run of IPchase's fingerprint check tells you.