Most WebRTC leak guides focus on desktop browsers - Firefox about:config, Chrome extensions, Puppeteer flags. Mobile gets a footnote at the end, if it's covered at all. But mobile proxy usage has grown significantly, and the WebRTC leak situation on iOS and Android is meaningfully different from desktop - different controls, different defaults, different failure modes.
This guide covers mobile specifically: how to test for WebRTC leaks on iOS Safari and Chrome for Android, what the results mean, and the exact steps to fix them. No desktop content recycled here.
Why Mobile WebRTC Leaks Differently Than Desktop
The core mechanism is the same as desktop - WebRTC's ICE candidate gathering queries STUN servers and collects IP addresses from all available network interfaces, potentially exposing your real IP even when proxy traffic is routing correctly. But the mobile-specific layer adds complications.
iOS Safari has no about:config. The fine-grained control that Firefox gives you on desktop simply doesn't exist on iOS. Safari's WebRTC behavior is controlled by Apple, and the settings available to users are limited to what Apple exposes in the browser UI or system settings.
Chrome on Android can't be configured via extensions. The Chrome extension ecosystem that desktop users rely on for WebRTC control doesn't apply to Chrome on Android. Mobile Chrome has a flags menu (chrome://flags), but the options there have changed between versions and aren't guaranteed to persist across updates.
Mobile apps bypass browser WebRTC settings entirely. If you're using a proxy through a native mobile app rather than a mobile browser, browser-level WebRTC settings are irrelevant - the app controls its own WebRTC behavior. This is a separate problem from browser-based WebRTC leaks.
IPv6 exposure is more common on mobile. Mobile carrier networks are further along in IPv6 deployment than most residential broadband. An iOS device on a 5G carrier connection likely has an IPv6 address, and if your proxy only tunnels IPv4, that IPv6 address will appear in WebRTC ICE candidates as a direct leak vector.
Step 1: Run the Test on Your Mobile Device
Before configuring anything, establish a baseline - what does your current mobile browser configuration actually expose?
Open your mobile browser and navigate to the NodeMaven WebRTC Leak Test - no account or setup needed. The test runs automatically on page load: it triggers WebRTC's ICE candidate gathering in your browser and displays every IP address collected, labeled by type.
Here's what to look at in the results. Each candidate is shown with its type - host candidates are local network addresses (your LAN IP or an mDNS hostname like a3f2c1d0.local), while srflx (server-reflexive) candidates show your public IP as seen by a STUN server. The srflx candidates are the ones that matter. If your real carrier IP appears there while your proxy is active, WebRTC is leaking around the proxy tunnel.
Run the test twice: first with no proxy active to record your real IP as a baseline, then with your proxy on. In the second test, srflx candidates should show your proxy's exit IP - or be absent entirely. If your real IP still appears in the second test, the proxy isn't routing WebRTC traffic and the fix steps below apply. The tool also flags IPv6 candidates separately, which is important on mobile since carrier networks are further along on IPv6 than most home broadband.
What you're looking at in the results:
The test displays ICE candidates gathered by your browser - the IP addresses WebRTC collected from your network interfaces. Each candidate is labeled with its type:
host candidates - local network addresses (your LAN IP like 192.168.x.x, or an mDNS hostname like a3f2c1d0.local on modern browsers)
srflx (server-reflexive) candidates - your public IP as seen by the STUN server. This is the critical one. If your real ISP-assigned public IP appears here while you're using a proxy, you have a leak.
relay candidates - TURN server relay addresses, generally not a privacy concern
Run the test twice: once without any proxy active (to establish your baseline real IP), and once with your proxy active. In the second test, the srflx candidates should show your proxy's exit IP, not your real IP. If they still show your real IP, WebRTC is leaking through the proxy configuration.
iOS Safari: What the Test Shows and How to Fix It
iOS Safari's WebRTC behavior has specific characteristics that differ from desktop Safari and from Android Chrome.
What iOS Safari typically exposes:
iOS Safari does not expose local IP addresses through WebRTC ICE candidates in the same way Chrome does - Apple implemented restrictions on local IP candidate generation in Safari 14 and later versions. However, public IP exposure through srflx candidates is still possible when using a proxy, because Safari can still contact STUN servers directly via the device's real network connection rather than through the proxy tunnel.
The result: on iOS Safari with a proxy configured, you may see your proxy IP in HTTP requests while WebRTC srflx candidates still show your real carrier IP.
Step-by-step fix for iOS Safari:
iOS Safari's WebRTC controls are accessed through the Advanced settings, not through the browser itself:
Open Settings on your iPhone or iPad
Scroll down to Safari
Tap Advanced
Tap Feature Flags (iOS 16+) or Experimental Features (older iOS)
Find WebRTC mDNS ICE Candidates and toggle it on if it isn't already - this replaces local IPs with mDNS hostnames
Look for ICE Candidate Restrictions - keeping this enabled limits which candidates Safari generates
For iOS 15 and earlier, the path is slightly different:
Settings → Safari → Advanced → Experimental Features
Toggle ICE Candidate Restrictions to on
For iOS Safari users, the fix is going into the phone's Advanced Settings and toggling off WebRTC mDNS ICE candidates - this controls how Safari handles local IP exposure through WebRTC peer connections.
Important limitation on iOS Safari:
Even with these settings configured, Safari's protection is partial - it limits local IP exposure but may still leak your public IP in some configurations. The fundamental issue is that Safari can still send STUN requests outside the proxy tunnel. The most reliable fix for public IP leaks on iOS Safari is using a VPN-based proxy client (like Shadowrocket) that routes UDP traffic - including WebRTC STUN requests - through the tunnel at the network level, rather than relying on browser-level settings alone.
Re-test after configuration:
After changing the iOS Safari settings, close all Safari tabs, reopen, navigate back to the WebRTC leak test, and check whether srflx candidates now show your proxy IP or are absent entirely. If your real IP still appears in srflx candidates, the browser-level fix is insufficient and a network-level solution (VPN-based proxy app) is needed.
Chrome for Android: Flags, Limitations, and Fixes
Chrome on Android shares the same underlying WebRTC implementation as desktop Chrome, but the configuration options available on mobile differ.
Step 1: Check Chrome flags
In Chrome for Android, navigate to chrome://flags in the address bar. Search for "WebRTC":
enable-webrtc-hide-local-ips-with-mdns - when enabled, replaces local IP candidates with mDNS hostnames. This is enabled by default in recent Chrome versions.
disable-webrtc-encryption - keep this at default (encryption enabled).
Search for "IP handling":
Look for WebRTC IP Handling Policy if it appears in your Chrome version. Setting this to "Disable non-proxied UDP" provides maximum protection by preventing WebRTC from making any UDP connections that don't go through the configured proxy.
Not all of these flags are present in every version of Chrome for Android - Google has added and removed flags across versions. If the flag isn't present, proceed to Step 2.
Step 2: Use Brave for Android instead of Chrome
If you need reliable WebRTC leak protection on Android and Chrome's mobile flags don't provide it, Brave for Android is the most practical alternative. Brave blocks known fingerprinting scripts by default and has built-in WebRTC leak protection in its privacy settings.
In Brave for Android:
Tap the three-dot menu → Settings
Go to Privacy and Security
Find WebRTC IP Handling Policy
Set to Disable Non-Proxied UDP
This is the same setting available in desktop Brave, now accessible directly in the mobile UI without extensions.
Step 3: Proxy configuration matters for Android WebRTC
Android's system proxy settings configure HTTP/HTTPS traffic but don't affect UDP. WebRTC uses UDP for STUN requests, which means system-level proxy settings don't prevent WebRTC leaks on Android.
For Android, the reliable solution is a VPN-based proxy app (Shadowrocket, or a proxy provider's own app if they offer one) that routes all traffic - including UDP - through the tunnel. When UDP is tunneled, STUN requests go through the proxy network and report the proxy's IP rather than your real IP.
Re-test after configuration:
After changes in Chrome for Android, navigate back to the WebRTC leak test. Clear the browser cache first (chrome://settings/clearBrowserData) and reload. The srflx candidates in the test results should show your proxy IP, show only mDNS hostnames (a UUID followed by .local), or be absent entirely.
The IPv6 Problem on Mobile
Mobile devices on 5G and LTE networks frequently have IPv6 addresses. If your proxy only tunnels IPv4 traffic, your IPv6 address will appear in WebRTC ICE candidates as a leak - even if everything else is configured correctly.
The WebRTC leak test shows IPv6 candidates separately. If you see an IPv6 address in the results that matches your carrier's IPv6 assignment, you have an IPv6 leak.
Fixes for IPv6 WebRTC leaks on mobile:
On iOS: Settings → Cellular → (your carrier) → IPv6 - some carriers allow you to disable IPv6 here. Not all carriers expose this setting.
On Android: The IPv6 setting location varies by Android version and manufacturer. On some devices: Settings → Network & Internet → your connection → Advanced → IP version. On others, IPv6 can only be controlled at the router level (if on Wi-Fi) or through a VPN that forces IPv4-only mode.
The more reliable fix: use a VPN-based proxy client that handles both IPv4 and IPv6 - or one that enforces IPv4-only mode to eliminate the IPv6 surface area entirely.
Comparing Mobile Browser WebRTC Leak Behavior
Firefox for Android is worth noting: unlike Chrome on Android, Firefox mobile retains the about:config interface. Navigate to about:config in the Firefox Android address bar, search for media.peerconnection.enabled, and set it to false to disable WebRTC entirely. This is the most complete fix available on any mobile browser - at the cost of breaking any WebRTC-dependent functionality (video calls, etc.).
Pre-Flight Check: Mobile Proxy Session Verification
Before running any mobile proxy workflow, run a quick two-step check. The NodeMaven tools work the same on mobile and desktop - open them directly in your mobile browser with the proxy active.
Navigate to the NodeMaven WebRTC Leak Test and confirm no srflx candidates show your real IP. Then open the NodeMaven DNS Leak Test and confirm your DNS resolver matches your proxy's location, not your carrier's. Both tests take under a minute together and confirm that your session is isolated at the WebRTC and DNS layers - not just at the HTTP layer.
When Browser-Level Fixes Aren't Enough
If you've applied all the browser-level settings and the WebRTC leak test still shows your real IP, the issue is at the network layer - WebRTC's UDP traffic is bypassing the proxy tunnel, and browser settings can't intercept it.
At that point, the fix is network-level proxy routing: a VPN-based proxy client that intercepts all traffic at the device's network interface, including UDP. This routes WebRTC STUN requests through the tunnel so the STUN server returns the proxy's IP rather than your real carrier IP.
For iOS, Shadowrocket is the standard tool for this. For Android, Shadowrocket is also available, alongside alternatives like Clash for Android or your proxy provider's native app if they offer one.
The browser-level settings are worth applying regardless - they handle local IP exposure and reduce the WebRTC surface area. But for public IP leaks through STUN on mobile, network-level routing is the reliable fix.
