WebRTC leaks are one of the most insidious problems in multi-accounting. You've configured proxy, verified through whoer.net that IP changed — but anti-fraud platform still sees your real address. Reason in 70% of cases — WebRTC, technology that bypasses proxy by architectural design. Let's understand leak mechanics and methods to close them at level sufficient for professional work.

What is WebRTC and why it bypasses proxy

WebRTC (Web Real-Time Communication) is browser API for peer-to-peer video calls, audio communication and direct data transfer between browsers. To establish P2P connection, WebRTC uses ICE protocol, which during candidate determination collects all device IP addresses:

  • Local IP (192.168.x.x or 10.x.x.x from LAN)
  • Real public IP from provider
  • IP via STUN/TURN servers

Critically: this process happens bypassing proxy. Proxy routes HTTP/HTTPS traffic, but WebRTC uses UDP at network level — proxy doesn't intercept it. This is not a bug, it's architectural feature.

Types of WebRTC leaks

Real public IP leak

Most critical type: JavaScript through WebRTC gets your real IP from provider, despite proxy. Site sees two IPs simultaneously — one from proxy (HTTP), other real (WebRTC). Anti-fraud immediately flags this discrepancy.

Local IP leak

Less critical, but informative: site sees your internal IP (192.168.1.x). Local IP alone doesn't reveal identity, but combined with other parameters helps identify device (e.g., multiple profiles with same 192.168.1.5).

IPv6 leak

If device has IPv6 configured and provider provides it, WebRTC can reveal IPv6 address even if proxy uses IPv4. IPv6 addresses often static and unique to device.

How to check WebRTC leaks

Verification algorithm:

  • Launch anti-detect browser profile with configured proxy
  • Open browserleaks.com/webrtc
  • "Local IP Addresses" section: should not show real local IP (or only non-informative IPv4 like 192.168.x.x)
  • "Public IP Addresses" section: should show only proxy IP, not real
  • Additionally: ipleak.net — comprehensive IP, DNS and WebRTC check

Methods to close WebRTC leaks

Method 1: Disable WebRTC in anti-detect browser

All popular anti-detect browsers have built-in WebRTC setting. This is simplest and most reliable method:

  • Dolphin Anty: in profile settings → WebRTC → "Disable" or "Replace with proxy IP"
  • AdsPower: Security Settings → WebRTC → Disable / Replace
  • GoLogin: profile settings → WebRTC → Disabled or Real IP of proxy
  • Octo Browser: similar setting in Security section

"Replace with proxy IP" mode preferable to full disable for services using WebRTC (video calls, some games): browser reports proxy IP instead of real — looks like legitimate user.

Method 2: Browser extensions for regular Chrome

If working through regular Chrome (not anti-detect), use extensions:

  • WebRTC Network Limiter (official from Google)
  • uBlock Origin with enabled WebRTC blocking option
  • WebRTC Control

But remember: in multi-accounting context regular Chrome without anti-detect browser is already principal problem, WebRTC is not only vulnerability.

Method 3: Configuration via about:flags (Firefox)

In Firefox (and GoLogin FlowerBrowser if available): about:config → media.peerconnection.enabled → false. Completely disables WebRTC at browser level.

Method 4: Firewall rules at OS level

For full guarantee on critically important tasks: configure Windows or macOS firewall to block UDP traffic not going through proxy. This is system-level protection, but requires technical expertise and complicates network configuration.

WebRTC and mobile proxies

Important note: when using SOCKS5 proxy, WebRTC leaks especially likely, because many browsers tunnel through SOCKS5 only HTTP/HTTPS, not UDP. When using mobile proxies via SOCKS5:

  • Always enable WebRTC replacement in anti-detect browser
  • Check browserleaks.com/webrtc after each proxy change
  • Ensure proxy settings have "tunnel DNS through SOCKS5" — this closes DNS leaks often accompanying WebRTC leaks

Leak chain: WebRTC + DNS + Canvas

In practice, WebRTC leak rarely comes alone. With misconfiguration, simultaneously exposed:

  • WebRTC: real IP
  • DNS: real provider DNS servers instead of proxy DNS
  • Timezone: system time zone doesn't match proxy time zone

For anti-fraud system, such "bouquet" of mismatches — definite suspicion signal. Each parameter must be checked separately.

Check-list before starting work

  • Anti-detect browser profile launched with proxy
  • browserleaks.com/webrtc → Public IP = proxy IP (not real)
  • browserleaks.com/dns → DNS = proxy DNS or neutral (8.8.8.8)
  • ipleak.net → no IPv6 leaks
  • browserleaks.com/timezone → matches proxy region
  • whoer.net → anonymity score 80%+

Relevance in 2026

In 2026, some anti-fraud systems do additional control: check if WebRTC enabled in browser, and if disabled — raise suspicion level (non-standard behavior). "Replace with proxy IP" mode elegantly solves this: WebRTC works, but shows "correct" IP.

WebRTC leaks are solvable problem, but requiring conscious control. Proxy configuration alone insufficient: need anti-detect browser with proper WebRTC settings and mobile proxy with clean IP. Reliable foundation provided by turbon.rent — choose mobile proxies with needed geolocation and close WebRTC at browser profile level.