What is WebRTC Leak?
A WebRTC leak is a browser exposing your real IP address through its peer-to-peer connection API while page traffic goes through a proxy. WebRTC gathers ICE candidates over its own UDP sockets, which ignore the browser's proxy configuration, and any script on the page can read those candidates without asking permission.
WebRTC has to find a path between two peers before media flows, so it collects ICE candidates. Host candidates are the addresses on local interfaces. Server-reflexive candidates come from a STUN server, which replies with the public address it saw the packet arrive from. Relay candidates route through a TURN server when nothing else connects. The server-reflexive candidate is the one that betrays you, because a STUN request sent over a raw UDP socket travels on the underlying connection rather than through an HTTP or SOCKS proxy set inside the browser.
A detection script is short. It creates an RTCPeerConnection pointed at a public STUN server, opens a data channel, calls createOffer, and reads the candidate lines that arrive on the icecandidate event. Each line contains an address. No camera or microphone permission is involved, no prompt appears, and the whole thing finishes in well under a second. Fingerprinting vendors run it alongside canvas and TLS checks and store the result next to the exit IP for comparison.
Browsers have narrowed the exposure without closing it. Chrome replaces host candidates with randomised .local mDNS hostnames, which hides LAN addresses but does nothing about the public reflexive candidate. Chrome's WebRTC IP handling policy can be set to block non-proxied UDP, and Firefox exposes a preference that turns peer connections off entirely. Antidetect browsers take a different route and rewrite the reported address to the proxy IP so the two agree. Switching WebRTC off completely has a cost, since a profile with no peer connection support looks unusual and video calls stop working.
IPv6 deserves separate attention. A proxy that only carries IPv4 while the host has native IPv6 will produce an IPv6 reflexive candidate that points straight at the subscriber line, even though every IPv4 check passes. Verify inside the exact browser profile and proxy configuration you plan to use, since a clean result in another browser on the same machine says nothing about this one. Compare the addresses in the candidate list against the exit IP; they should agree, or the candidates should be absent for a stated reason.
Where you meet it
You meet this in the WebRTC dropdown of an antidetect browser, where the choice is between real, replaced and disabled, and in the audit that follows a batch of accounts getting flagged despite clean proxies. It also appears when a scraping stack uses a full Chromium instance with proxy settings applied at the browser level rather than the network level.
Common questions
How do I stop a WebRTC leak?
Set the browser to block non-proxied UDP, use an antidetect profile that rewrites the reported address to the proxy IP, or route the whole machine through a network-level tunnel that captures UDP. Disabling peer connections outright also works, at the cost of breaking calls and standing out.
Does turning WebRTC off make me anonymous?
No. A profile with WebRTC missing entirely is itself unusual, and detection scripts record the absence. Matching the reported address to your proxy exit is a quieter outcome than removing the API, and it keeps sites that legitimately use peer connections working.
Does using a proxy prevent WebRTC leaks?
An HTTP or SOCKS proxy configured inside the browser does not, because STUN traffic uses UDP sockets that bypass those settings. A system-level tunnel that captures all UDP generally does. Test rather than assume, since the behaviour differs between browsers and versions.
Related terms
Real 4G/5G mobile and residential IPs
PROXIES.SX runs carrier IPs in 100+ countries with HTTP and SOCKS5 on every endpoint. $4/GB down to $2.40/GB at volume, free endpoints and rotation, and your GB never expire.