WebRTC and DNS: Why a Proxy Alone Is Not Enough

A proxy hides the real IP address for the browser’s HTTP and HTTPS traffic. But the browser has other “ways” to reveal the real IP. Two of them are worth checking separately: WebRTC and DNS.

WebRTC and DNS are normal parts of the browser and the network. The problem begins when network checks show inconsistency: the site is opened through a proxy, but a WebRTC or DNS leak test points to a different route.

WebRTC: Why It Exists in the First Place

WebRTC is used for peer-to-peer audio and video calls, screen sharing, and data transfer between browsers. To find a working path between two sides, WebRTC uses ICE. MDN describes ICE candidates as possible network connection paths through which clients can communicate either directly or through an intermediate server: WebRTC connectivity. ICE itself is specified in RFC 8445.

This is where the risk of deanonymization appears. RFC 8828 explicitly states that WebRTC can reveal more information about the local network to a web application than a normal HTTP request. The document lists understandable cases: additional public IPs when multiple network interfaces are present, private NAT addresses, and bypassing a classic application proxy via STUN when direct internet access is allowed.

Put simply: if an ordinary page sees only the proxy IP, WebRTC can reveal the real IP address if it is configured poorly.

What a WebRTC Leak Looks Like

The scenario looks like this: HTTP traffic goes through the proxy, but WebRTC gathers ICE candidates through a different route.

In the paper One Leak Will Sink A Ship, the author tested browsers and VPN services and showed that the WebRTC API could expose IP addresses to a website through JavaScript even with a VPN enabled. The research is old, so it should not be read as a one-to-one description of every modern browser. But it explains the class of problem well: WebRTC does not operate in exactly the same layer as an ordinary page request.

Why It Is Not Always a Good Idea to Just Disable WebRTC

Disabling WebRTC completely is the most heavy-handed option. Sometimes it works, but it comes at a cost: calls, screen sharing, data channels, and any checks where the service expects the WebRTC API to work may break.

Even Chrome does not reduce the issue to “enable/disable.” Chrome has a webRTCIPHandlingPolicy policy that controls how WebRTC traffic is routed and how much local address information is revealed to websites. Chrome Extensions documentation lists the available modes, including disable_non_proxied_udp: chrome.privacy API. Chrome Enterprise also has a separate policy for WebRTC IP handling: Chrome Enterprise policy.

The conclusion is simple: the right goal is not to break WebRTC, but to make sure it does not expose a route that contradicts the profile.

DNS: Where Mismatches Can Appear

DNS translates a domain name into an IP address. Cloudflare explains it briefly: DNS translates human-readable domains like example.com into IP addresses that machines use: What is DNS?.

A DNS leak is a situation where the main traffic goes through a VPN or proxy, but DNS requests take a different route. Mozilla explains this with the VPN example: DNS requests can go outside the protected tunnel if the VPN is configured incorrectly or does not route DNS through its own network: What is a DNS Leak?.

With a proxy, the same logic matters: where exactly the domain is resolved. Curl documentation clearly shows the difference between local and remote DNS. socks5:// means SOCKS5 with local name resolution, while socks5h:// means SOCKS5 with name resolution performed on the proxy side: everything curl: Proxies.

It is important to be precise here: a normal website does not always directly see your DNS resolver. So it is not accurate to say that “any website instantly knows your DNS.” The more accurate statement is this: a DNS leak shows that the network route is not configured fully. This can be detected through DNS leak tests, your own infrastructure, or systems that control their own domains and network logs.

What We Check in 0detect

For us, WebRTC and DNS are part of one unified network profile. If the profile works through a proxy, the rest of the network parameters must be aligned with it and not create conflicts.

In our profile creation documentation, network settings are separated into a dedicated “Connection” section: you can attach a proxy to the profile, choose a proxy from the list, and configure DNS. For DNS, there is a “Real” mode: if the profile uses a proxy, DNS is derived according to that proxy; if there is no proxy, your own address is used; and if necessary, DNS can be set manually: Create Profile.

The same general profile settings also include language, time zone, and geolocation. According to the documentation, these parameters are selected by default with the external IP taken into account. This is not directly about WebRTC, but it reflects the same principle: IP, DNS, time zone, language, and geolocation should all tell one coherent story.

For automation, order matters as well. In Local API, the proxy is created separately, attached to the profile via POST /profile/set/proxy, and only then is the profile launched: Proxy. This reduces the risk of a situation where the script has already opened the browser while the network profile still does not match the profile configuration.

Summary

WebRTC can reveal more network information than a normal HTTP request. DNS can go through the wrong route if name resolution is configured locally or bypasses the proxy.
A good profile is not “a proxy on top of a browser.” It is a browser whose network settings, fingerprint, and geography do not contradict one another.