Conduct WebRTC Leak Test: Prevent IP Leaks
A working proxy does not automatically protect every browser connection. Use a WebRTC leak test to verify routing, prevent unexpected IP exposure, and keep your web presence secure and consistent. Here is a full guide showing how to do that.
What is WebRTC
WebRTC (Web Real-Time Communication) is an open standard that lets browsers and apps exchange live audio, video, and data without plugins. It commonly uses UDP for low-latency communication but also supports TCP and relay-based connections.
To establish connections, WebRTC gathers ICE (Interactive Connectivity Establishment) candidates: possible network endpoints containing an address, port, and transport protocol. These candidates are the source of all potential leaks.
If discovery uses an unprotected route, these candidates can expose an IP outside your intended proxy or VPN connection.
Why proxies leak via WebRTC
A WebRTC leak happens when browser connectivity discovery exposes an address your routing setup should conceal. WebRTC leak test helps you reveal that.
A webpage starts WebRTC candidate gathering.
The browser contacts a STUN server to discover its public-facing address.
If that connection bypasses your proxy, STUN observes your ISP address.
The browser may expose that address to webpage JavaScript through an ICE candidate.
Remember that:
Browser proxy settings do not necessarily cover WebRTC traffic.
A correctly enforced full-tunnel VPN should carry this traffic; WebRTC does not inherently defeat VPN encryption.
Why WebRTC leaks can reveal you
An exposed public IP can reveal your network provider and approximate location, but not your name or exact address. It may also enable:
Correlation between otherwise separate browser sessions.
Location-based restrictions.
Additional verification or account review.
These are possible consequences, not guaranteed outcomes. Still, it’s worth being cautious and conduct WebRTC leak tests regularly.
Exercise caution and always test DNS leaks and WebRTC leaks. Read about proxy and data security to know more.
Difference between DNS and WebRTC leaks
DNS leaks concern where domain lookups travel; WebRTC leaks concern which addresses connectivity discovery exposes. Neither test replaces the other.
Dimension | DNS Leak | WebRTC Leak |
Layer & protocol | System/app name resolution; UDP/TCP 53, DoH, DoT | Browser/app connectivity; ICE, STUN, TURN, commonly UDP |
Leaked information | Queried domain names; resolver sees query source | Local or public IPv4/IPv6 addresses |
Who learns it | Resolver; network observers if DNS is unencrypted | Page scripts, peers, or discovery servers |
Primary risk | Exposure of domain-lookup activity | Unintended network identification and session correlation |
Scope | System-wide, application-specific, or browser-specific | WebRTC-enabled browsers and applications |
Trigger mechanism | DNS resolution outside the intended protected path | WebRTC gathering candidates or checking connectivity |
A DNS test usually identifies recursive resolvers, not your device’s public IP. An unexpected resolver warrants investigation; its country alone doesn't prove a leak.
How to test for WebRTC leaks
Basically, a WebRTC leak test is to check whether your real IP appears in any browser-visible ICE candidates. Specific services can help, such as BrowserLeaks, IPLeak, or the official WebRTC tool Trickle ICE on GitHub.
1. Check your actual IPv4 and IPv6 without proxy/VPN
Close sensitive work sessions before disconnecting protection.
Open IPLeak.
Record your direct public IPv4 and any available IPv6.
Keep these baseline addresses private.
“No IPv6 detected” means that the test did not establish IPv6 connectivity, not that IPv6 can never become available.
2. Launch your proxy/VPN network and check your IP again
Connect your VPN or configure your CyberYozh App proxy in the intended browser profile or client.
Open a fresh test tab.
Confirm the public IP changed to the expected exit.
Check IPv4 and IPv6 separately.
A changed browsing IP confirms that the connection’s route changed, but WebRTC leaks may still be present.
3. Open BrowserLeaks, IPLeak, or WebRTC’s Trickle ICE
Choose a WebRTC leak test online:
BrowserLeaks: inspect “Your WebRTC IP” and the SDP log.
IPLeak: use its combined DNS WebRTC leak test.
Trickle ICE: a WebRTC project sample; click “Gather candidates” and inspect the address/type columns. It is a diagnostic sample, not a comprehensive privacy certification.
4. Check whether your physical IP is present in outputs
Compare WebRTC leak test results against your baseline:
Direct ISP public IP appears: investigate an IP leak.
Expected proxy/VPN exit appears: consistent with protected routing.
192.168.x.x or 10.x.x.x: private-network information, not your public identity.
A .local hostname: local-address obfuscation, not proof of public-IP protection.
No candidates or an error is inconclusive. Retest with another tool after reconnecting. If none of these tools show leaks, then you’re safe. To know how to prevent leaks, keep reading.
How to prevent WebRTC leaks
Disable WebRTC when unnecessary, or enforce protected routing when calls and real-time applications must remain functional. Blocking non-proxied UDP helps, but does not replace WebRTC leak test to understand what’s going on.
Explore how to ensure your proxy IP won’t be banned, including IP leak prevention and other methods.
In ordinary browsers
Use the relevant browser setup guide, then apply the appropriate control:
Firefox desktop: about:config → media.peerconnection.enabled → false. This disables WebRTC.
Chrome: use a maintained privacy extension supporting disable_non_proxied_udp.
Brave: search Settings for “WebRTC IP Handling Policy”; choose “Disable Non-Proxied UDP.”
Microsoft Edge: use a compatible WebRTC privacy extension or managed policy; retest.
Safari: use enforced device-level VPN routing; do not rely on old experimental-menu instructions.
Opera: select non-proxied UDP blocking where available, or use a maintained compatible extension.
In antidetect browsers
Follow the antidetect browser instructions.
Assign the proxy to the profile, then inspect its WebRTC settings. Choose disabled mode if unnecessary; otherwise use the vendor’s protected-routing option.
Labels such as “Altered” differ between products: changing displayed candidates alone does not establish that network traffic is protected.
Test each profile afterward.
In proxy clients
Follow the proxy client instructions. Then:
Import your CyberYozh credentials.
Enable TUN/full-routing mode when supported.
Verify upstream UDP support.
Route DNS through the intended path
Disable unwanted direct fallback.
System-proxy mode alone is not equivalent to a device-wide tunnel. Retest the actual browser configuration for WebRTC leaks after that.
System firewall setting
Consult the relevant OS settings guide.
Use a VPN kill switch in your Wi-Fi settings, or add outbound rules that restrict protected applications to the tunnel or proxy client. Cover both IPv4 and IPv6. It will disable all non-proxied (direct) traffic, minimizing WebRTC leak risk.
Best practices for operating with WebRTC leaks
Test the exact work profile, not merely your default browser; browser permissions, extensions, proxy assignments, and routing rules can differ between environments.
Repeat checks after browser updates, client changes, network switching, and reconnects; successful testing validates a particular configuration, not every possible future state.
Verify DNS and IPv6 independently; disabling WebRTC does not repair unrelated resolver routing or prevent ordinary connections from bypassing your protected network path.
Test failure behavior before production work: disconnect the tunnel and confirm protected applications stop connecting rather than silently falling back to direct access.
Preserve required functionality: test calls and screen sharing after restrictions, then document the working configuration without storing proxy passwords or publicly sharing baseline addresses.