A proxy may cover HTTP traffic while WebRTC uses STUN/ICE over UDP to exchange candidate addresses. This article explains when local and private-network addresses can be exposed and how to keep the network exit and browser environment consistent.
You have bought a proxy, and an IP lookup page shows the expected region and ISP. Your network identity seems clean. But when you open a leak test, the WebRTC section turns red and shows the address of your real ISP connection.
Do not rush to replace the proxy. In most cases, the issue is not proxy quality but traffic the proxy does not control.
A proxy handles HTTP, while WebRTC takes another path
A proxy operates at the network layer. Whether it is implemented as a browser extension or a system-level tunnel, it handles HTTP/HTTPS requests and sends that traffic through the proxy exit.
WebRTC is different. It is a real-time communication capability built into the browser. To find suitable routes for audio/video calls and P2P transfers, it can actively send STUN queries to external servers—essentially asking, “What address do you see for me?”—then package the results as ICE candidates for the webpage. These queries use UDP, a channel independent of the HTTP tunnel.
That creates a mismatch: webpage requests leave through the proxy, while the browser may also report your local address. Assuming that configuring a proxy automatically makes the entire network identity clean is the most common starting point for this problem.
It can expose more than a public IP
ICE candidates commonly contain two kinds of addresses. One is a public address, meaning the exit of your actual ISP connection. The other is a local address, such as a private address beginning with 192.168, and sometimes an address from a virtual network adapter.
A private-network address alone proves little; nearly every computer has one. But it can be stable enough that repeatedly overlapping candidate addresses across several accounts give a platform another signal for associating them with the same device. A public address is more direct: it points to the real ISP and approximate geographic area. How precise that becomes depends on the platform, but the direction is clear: the more genuine the address, the easier the association.
When can a site actually read it?
Not every website tries to read these addresses. Address exchange requires the page to actively create an RTCPeerConnection object, which ordinary content pages generally do not need.
Sites that may do this usually fall into several groups: services that need real-time communication, such as video meetings, online customer support, and some live-streaming pages; sites whose business relies heavily on advertising or anti-fraud; and platforms with mature risk-control systems. The collection happens behind the visible interface, and you normally are not notified about how the collected data is later used.
There is also a case unrelated to the website itself. During the brief interval when a proxy reconnects or switches nodes, a STUN request from the browser may fall back to the local network. The window is short, but long enough for one observation to be recorded.
Three common failure scenarios
Browser-extension proxies usually take over only HTTP/HTTPS requests. UDP remains outside their scope, and selecting a “global” option in the interface does not change that.
A system-wide proxy looks more comprehensive because it covers traffic from the whole device. However, candidate-address collection can bind directly to a local network interface and bypass the system routing table, leaving this part of the tunnel exposed.
The third issue is not purely technical but procedural. Risk-control systems have increasingly treated WebRTC addresses as one of several signals for account association. Data that was previously not measured, or simply ignored, may now be included in a decision.
The goal is a consistent exit path, not merely disabling one switch
There are several general approaches. If a workflow does not need real-time communication at all, disabling WebRTC is the simplest option, at the cost of losing features such as video calls and online customer support.
If those features must remain available, a common approach is to make the address returned at the WebRTC layer consistent with the proxy exit. A more robust approach is to forward STUN requests through the proxy channel as well, so the interface does not expose the local address. For workflows that require P2P or video calls, UDP traffic as a whole needs to use the proxy rather than only the HTTP layer.
A common mistake is to assume that disabling WebRTC alone makes the environment clean. What matters is consistency across the network exit, DNS resolution, IP ownership and ASN, time zone and language, and device characteristics. A mismatch in any one of them can create an anomaly signal; WebRTC is simply one of the easiest pieces to overlook.
Verification is straightforward. Test once after switching nodes and again before putting the environment into normal use: open a leak test and check whether the WebRTC section shows the proxy exit, a local address, or the real public address. A standard IP lookup does not reveal this item.
Browser-engine-level environment isolation can define a separate WebRTC address policy for each environment and pair it with that environment’s network exit. PurpleMark provides this type of capability. If multiple environments share one exit, or if their address policies are inconsistent, the value of isolation is greatly reduced.
This is a technical explanation only. Use relevant tools in accordance with platform rules and local laws.
