Why a Proxy Can Still Expose an IP: WebRTC Leak Testing and Protection

A normal IP page shows the proxy exit, yet a WebRTC test lists another public address, a private subnet, or a random .local name. Does that prove the proxy failed?

It depends on what the second value represents, which ICE candidate type produced it, and whether WebRTC traffic actually left through an unintended route. Treating every address on a test page as a real-IP leak creates false positives. Testing only ordinary HTTP traffic can miss a separate UDP or IPv6 route.

This guide uses the W3C WebRTC specification and official WebRTC documentation to build a repeatable test. It also maps the five WebRTC modes currently implemented by PurpleMark. The purpose is privacy, authorized testing, and responsible account operations—not evasion of platform rules.

Reviewed in July 2026. Browser engines, network policies, and proxy capabilities change. Retest the actual environment after every material configuration change.

1. A web proxy and WebRTC can use different paths

An HTTP proxy normally carries HTTP and HTTPS requests. WebRTC establishes audio, video, screen-sharing, and peer data connections. To work across NAT and firewalls, its ICE process gathers possible connection addresses from local interfaces, STUN-discovered NAT mappings, and TURN relays, over transports such as UDP or TCP.

If a browser proxy covers only web requests and not the UDP, IPv6, or sockets used by ICE, STUN may observe the original network's public mapping. This is the basis of the leak—not a deliberate WebRTC back door.

2. Read the ICE candidate type first

Type	Meaning	How to interpret it
`host`	Candidate from a local interface	May be private IPv4, IPv6, or an mDNS name; alone it does not prove public-IP exposure
`srflx`	Server-reflexive mapping discovered through STUN	An unexpected ISP public IP here is the classic leak signal
`prflx`	Peer-reflexive candidate learned during connectivity checks	Often appears during a real connection, not every static test
`relay`	Address allocated by a TURN server	This is the relay's address, not the endpoint's public IP

The W3C notes that ICE candidates can reveal location, connection method, and local topology, and can increase fingerprinting surface. Applications can reduce disclosure to peers by using relay-only transport. See the W3C IP-address privacy section.

Modern browsers may replace local addresses with mDNS .local names. Such a name usually means a host address was obscured; it is not another public IP.

3. Five common causes behind a proxy

The proxy covers only HTTP/HTTPS. WebRTC UDP sockets follow the system route.
The proxy does not actually carry UDP. Protocol, client, server, or plan support may differ.
IPv4 is proxied while IPv6 remains direct. A test can show proxy IPv4 and original IPv6 together.
Split tunneling or bypass rules apply. PAC rules, security software, extensions, and enterprise policies may exclude a process or protocol.
The result is misclassified. A private address, mDNS name, proxy exit, and TURN address are not equivalent evidence.

4. A reproducible leak test

With the proxy off, privately record the ISP IPv4 and IPv6 as a baseline.
Enable the proxy, restart the target profile, and confirm HTTP, IPv4, IPv6, and DNS exits.
Open a WebRTC test that exposes ICE candidate type and protocol.
Classify each address as private, mDNS, proxy exit, TURN relay, or original ISP.
Close the profile fully, restart, and repeat after each change.
If the business uses WebRTC, test an actual call or data channel as well as candidate gathering.

MDN's candidate type reference defines the four types.

Observation	Evidence-based conclusion
`srflx` contains the original ISP public IP	Clear WebRTC public-address exposure risk
`srflx` contains only the proxy exit	STUN observed the proxy path in this test
Only `relay` is present	Traffic is represented by a TURN relay address
Private IPv4 or `.local` is present	A host candidate or mDNS mapping exists; this alone is not a public-IP leak
Original IPv6 appears beside proxy IPv4	IPv6 is not being handled consistently
No candidates appear	WebRTC may be disabled, blocked, broken, or unreachable; test functionality before concluding

Media permission is not always required to gather candidates, so denying microphone access is not proof that no address can be exposed.

5. Reduce address exposure without guessing

Use a trusted system-wide tunnel when all application traffic must share one exit, and verify its UDP, IPv6, split-tunnel, and failure behavior. For HTTP or SOCKS proxies, confirm how the specific client and service handle UDP.

Browser policy can restrict non-proxied UDP. The tradeoff may be slower connections, TURN relay use, or broken real-time features. Completely disabling WebRTC is reasonable when the feature is unnecessary, but it will affect conferencing, voice, screen sharing, remote support, and data-channel applications.

WebRTC application developers can set RTCIceTransportPolicy to relay and provide TURN. This limits candidate disclosure to the peer but adds latency, bandwidth cost, and relay capacity requirements. See the official peer connection guide.

Test DNS and IPv6 separately. Fixing WebRTC does not prove DNS uses the intended resolver, and disabling IPv6 without analysis is not a universal remedy.

6. PurpleMark's five WebRTC modes

Mode	Current behavior	Appropriate test scenario
Forward (`forward`)	Applies the configured forwarding/STUN behavior	When WebRTC functionality must remain; retest against the real proxy
Replace (`replace`)	Uses WebRTC IPv4 information matching the active proxy exit	When page-visible WebRTC information should align with the proxy
Real (`real`)	Keeps the computer's real WebRTC network information	Local network diagnostics where hiding the address is not required
Disable (`disable`)	Prevents sites from reading WebRTC parameters	Privacy-first workflows that do not need WebRTC features
Proxy UDP (`proxy_udp`)	Blocks non-proxied UDP and uses the proxy when supported	Environments with compatible proxy and kernel; requires Patch 2.8.2.0+

Configure the proxy first, select a mode based on functional need, save and fully restart the profile, then check HTTP, IPv6, DNS, ICE candidates, and a real call if applicable. Record the client version, proxy type, date, and result.

Neither Replace nor Proxy UDP is a universal guarantee. Proxy capability, operating-system routing, kernel version, and the site's implementation still determine observable behavior.

7. Authorized teams need isolation and auditability

For legitimate brand, regional, testing, or client accounts, separate profiles reduce crossed cookies, wrong proxies, and accidental sign-ins. Record each account's owner, approved region, proxy custodian, WebRTC mode, last test, and recovery owner.

WebRTC protection is not an enforcement-evasion tool. A consistent address does not make spam, deceptive engagement, or ban avoidance compliant. PurpleMark supplies profile isolation and configuration controls; authorization, content, and policy compliance remain the operator's responsibility.

8. Troubleshooting checklist

Does ordinary web traffic use the expected proxy?
Are IPv4 and IPv6 both routed as intended?
What type is each ICE candidate?
Does any srflx candidate show the original ISP public IP?
Is another address private, mDNS, proxy, or TURN?
Does the proxy explicitly support UDP and is it enabled?
Are split-tunnel, PAC, extension, or firewall rules involved?
Was the profile fully restarted and retested?
Do required real-time features still work?
Was the result recorded with the configuration version?

9. Frequently asked questions

Is `192.168.x.x` proof of a WebRTC leak?

It is a private address and may be a host candidate. It is not proof that the ISP public address was exposed. Check srflx and the selected candidate pair.

Is a `.local` address safe?

It usually reflects mDNS obfuscation of a local interface. That reduces direct local-address disclosure but says nothing conclusive about public IPv4, IPv6, or relay paths.

Can a system VPN still leak?

A correctly configured system tunnel typically covers more traffic than an HTTP-only extension, but split tunneling, IPv6, fail-open behavior, and exclusions can still create another route. Test it.

Does disabling WebRTC solve everything?

It blocks WebRTC functionality but does not repair DNS leaks, malicious extensions, malware, or other network paths.

Does a green test mean an account is safe?

No. It describes what one page observed at that time. Account security also depends on credentials, authorization, recovery methods, behavior, and platform rules.

Conclusion

A WebRTC leak is not simply “a second address appeared.” Reliable diagnosis compares the normal web exit, ICE candidate type, UDP and IPv6 routing, the proxy exit, and the original baseline. An unexpected ISP public address in a srflx candidate is much stronger evidence than a private or TURN relay address.

The fix is also a system, not one switch: tunnel capability, browser policy, proxy UDP, IPv6, and required application functionality must be verified together. Stable configuration, repeatable testing, and auditable records are more dependable than constantly randomizing an environment.