WebRTC Leaks: The Privacy Hole Most Crypto Users Ignore

A friend of mine was running a farm. Dozen wallets, each with its own SOCKS5 proxy, careful timing between transactions, the whole setup. Looked clean on paper. Then one day half his wallets got clustered by an analytics platform. Same real IP popping up across all of them.

He was furious. Blamed the proxy provider. Spent hours checking for DNS leaks. Nothing.

Turned out it was WebRTC.

What WebRTC actually is

WebRTC stands for Web Real-Time Communication. It's the thing that makes video calls work directly in your browser without installing plugins. Google Meet, Discord voice chat, some customer support widgets - all WebRTC under the hood.

The problem? To establish peer-to-peer connections, WebRTC needs to figure out your network setup. It does this by sending requests to STUN servers. These are basically servers that tell your browser "hey, here's what your IP looks like from the outside."

And here's the kicker: these STUN requests happen outside your proxy configuration. Your browser just fires them off directly. VPN? Proxy? Doesn't matter. The STUN request goes around them.

ICE candidates and why they matter

When WebRTC tries to set up a connection, it generates what are called ICE candidates. Think of them as a list of all the ways another computer could reach yours. This list typically includes:

Your local IP address. Like 192.168.1.42. Seems harmless, but it narrows things down a lot.

Your public IP. The real one. Not the proxy IP, not the VPN IP. Your actual ISP-assigned address.

Your STUN-resolved IP. Sometimes different from the above depending on your NAT setup.

Any website can trigger this process through JavaScript. No permission popup. No notification. Just a few lines of code and they have your real IP alongside whatever proxy IP you thought was protecting you.

How people actually get caught

Saw a thread on a Telegram group last year where someone shared their experience with a LayerZero-adjacent airdrop. They'd been using unique proxies per wallet but forgot about WebRTC. The project's analytics partner was collecting ICE candidates alongside wallet addresses. When they ran the clustering, 8 wallets all resolved to the same residential IP in Ohio.

Eight wallets. Gone. Because of a browser API designed for video calls.

And this isn't some exotic attack. You can go to browserleaks.com/webrtc right now, with your VPN running, and probably see your real IP staring back at you. Try it. Seriously.

The STUN/TURN thing

Quick technical tangent. STUN servers are free relays that just tell you what your IP looks like. TURN servers are paid relays that actually route your traffic. Most WebRTC implementations try STUN first because it's cheaper.

The leak comes from STUN. When your browser contacts a STUN server, it sends a binding request from your actual network interface. The STUN server responds with your mapped address. This whole exchange bypasses HTTP proxy settings entirely.

TURN is different because traffic actually flows through the relay. But browsers prefer STUN, so the leak happens before TURN is even considered.

(Not getting into the full ICE negotiation process here. It's complicated and honestly not that relevant to the privacy angle.)

Why just disabling WebRTC isn't great

First instinct for most people: just kill it. Firefox lets you do this with media.peerconnection.enabled set to false. Chrome doesn't have a native toggle but extensions exist.

Problem is, stuff breaks. Some dApps use WebRTC for peer-to-peer features. Certain DEX interfaces use it for direct order matching. Live support chat on exchanges? Often WebRTC. Discord in the browser? Needs WebRTC for voice.

If you're running browser profiles for different wallets, completely disabling WebRTC in all of them creates another issue: it makes you stand out. Most real users have WebRTC enabled. Having it disabled is itself a signal that you're trying to hide something.

What actually works

The proper fix has a few layers.

First option: fake the WebRTC response. Instead of leaking your real IP or showing no IP at all, return the proxy IP as your WebRTC IP. This is what good antidetect setups do. The browser thinks WebRTC is working normally, websites see an IP that matches your proxy, and nothing looks suspicious.

Second option: block just the local candidate generation. Keep WebRTC functional for actual communication but prevent the enumeration of local network interfaces. This stops the local IP leak without breaking video calls entirely.

Third option: use a browser that handles this per-profile. Each profile gets its own WebRTC policy tied to its proxy. Profile A shows proxy A's IP through WebRTC. Profile B shows proxy B's IP. No cross-contamination.

Raven Wallet takes the third approach. Each browser profile has its own WebRTC configuration. You can disable it completely for profiles that don't need it, or set it to proxy-aware mode where WebRTC responses match the profile's proxy.

Testing your setup

Before and after. Always test.

Go to these sites with your proxy connected:

1. browserleaks.com/webrtc - shows ICE candidates in detail
2. ipleak.net - general leak test including WebRTC
3. whoer.net - checks for consistency between your HTTP IP and WebRTC IP

What you want to see: either no WebRTC IPs listed, or WebRTC IPs that match your proxy IP. What you don't want: your real IP showing up anywhere in the ICE candidates section.

If you're using a VPN or proxy and your real IP still shows up in WebRTC, your entire operational security setup has a hole in it. Doesn't matter how careful you are with everything else.

The bigger picture

WebRTC leaks are just one piece of the browser fingerprinting puzzle. Your IP is one data point. Combined with canvas fingerprints, WebGL renderer strings, timezone, language settings, and screen resolution - it builds a profile that's hard to fake piecemeal.

This is why the browser profile approach works better than individual fixes. Instead of patching 15 different leak vectors one by one, you create isolated environments where everything is consistent. The IP matches the timezone matches the language matches the WebRTC response.

Fair enough, right? One leaky API and months of careful wallet separation goes out the window. Check your setup. Takes two minutes.