WebRTC, DNS and TLS Leaks in Antidetect Browsers: What Gets Past Your Proxy

A proxy changes the IP that a site sees for your page requests. But a browser talks to the network in more ways than page requests. WebRTC asks a server for your public address over UDP, the browser looks up domain names, it opens every secure connection with a TLS handshake, and the TCP connection underneath has a shape of its own. Each of these can tell a site something different from what your proxy says.

This piece goes through the 3 leaks media buyers hear about most, WebRTC, DNS and TLS, plus the TCP layer that few people check. On October 23, 2026 we ran Chrome 156 behind a proxy that logged every connection, looked at what a site could see, and checked the standards, Chromium's own documentation and what antidetect vendors offer in their settings. I've used Dolphin, Linken Sphere, AdsPower and Multilogin in my own work; the facts below come from that test and from the sources listed at the end.

What counts as a leak?

3 different things go by that name. The first is traffic that goes around the proxy, so the site or a server it uses sees your real IP. WebRTC is the classic case. The second is a lookup that goes to the wrong place, such as DNS queries going to your home internet provider. The third isn't a leak of your IP at all: it's a layer the proxy can't change, like the TLS handshake your browser sends or the TCP fingerprint of the proxy server, that disagrees with what your profile claims.

Why it matters for an antidetect browser profile. The first 2 can put your home IP or your provider's country next to a proxy in another country. The third creates exactly the kind of contradiction detection companies score, as our piece on how antidetect browsers get caught explains.

How does WebRTC get around your proxy?

By design. RFC 8828, the standard on how browsers should handle IP addresses in WebRTC, says it in plain words: if the client is behind a proxy "but direct access to the Internet is permitted, WebRTC's STUN checks will bypass the proxy and reveal the public IP address of the client." The same RFC says that "By default, WebRTC traffic should not be sent through proxy servers," because video and audio suffer over the TCP connections proxies use.

Most proxies can't carry it anyway. WebRTC works over UDP. The RFC notes that UDP isn't supported by "all HTTP and most SOCKS" proxies, and Chromium's documentation is explicit about its own side: "In Chrome SOCKSv5 is only used to proxy TCP-based URL requests. It cannot be used to relay UDP traffic." So with a typical HTTP or SOCKS5 proxy, WebRTC either goes around it or doesn't connect at all.

Here's what we saw. We ran a small proxy on our test PC that logged every connection, pointed Chrome 156 at it, opened BrowserLeaks' WebRTC page and also collected WebRTC candidates the way any site's script can. We repeated it with 3 values of Chrome's WebRTC IP handling setting:

• default — 2 candidates: a masked local address ending in .local and our public IP. The public IP came from a STUN request over UDP.
• default_public_interface_only — 1 candidate: our public IP. The same STUN request over UDP.
• disable_non_proxied_udp — No candidates at all. WebRTC had no route it was allowed to use.

Every connection to BrowserLeaks went through our proxy, and the proxy can't carry UDP, so the public IP in the first 2 rows could only have come from a request that went around it. Our proxy ran on the same PC, so its exit IP was the PC's own, and BrowserLeaks reported "No Leak." Behind a real proxy, that same candidate would be your home IP sitting next to the proxy's IP, which is the leak WebRTC tests look for.

Your local IP is mostly safe in Chrome. Since Chrome 76, rolled out in August 2019, Chrome replaces private IP addresses in WebRTC with random names ending in .local, as the masked candidate in our first row shows. Google's announcement says this applies to "all sites except those that have getUserMedia permissions," meaning sites you allowed to use your camera or microphone. The public IP via STUN is the leak that still matters.

What do antidetect browsers do about WebRTC?

They all offer some version of 3 choices. Leave WebRTC as it is, which leaks; replace the public address with the proxy's IP; or switch WebRTC off. Several now add a 4th: block only the UDP traffic that doesn't go through the proxy. That's Chrome's disable_non_proxied_udp, the setting that left our page with no candidates at all behind an HTTP proxy. Octo describes its version as "similar to disabling WebRTC; however, instead of IP spoofing, TCP-based traffic will continue to flow." Here's what the vendors' docs list, checked on October 23, 2026:

• Dolphin{anty} — Off, Real, Without UDP, Altered, Manual. Altered.
• AdsPower — Replace, Forward, Disabled, Real, plus a Proxy UDP option. Disabled.
• Octo Browser — Based on IP, Real, Disabled, plus a Disable UDP option. Based on IP.
• Multilogin — Masked, Custom, Real, Disabled. Masked.
• Linken Sphere — Adaptive, Fake, Direct, N/A, Off. Adaptive.
• Kameleo — Automatic, Manual, Block, Off. Automatic is marked recommended.
• GoLogin — Based on IP, Off. Not stated.
• Incogniton — Altered, Real, Disabled, Only proxy. The docs say keep Altered.
• Hidemyacc — Altered, Disable, Real. Altered.

Most vendors tell you to replace, not switch off. Dolphin marks Off as "not recommended," and its blog warns that with WebRTC disabled "the source of traffic may become more suspicious about you, since ordinary users usually do not do so." Kameleo says Block "can appear suspicious, as most users do not block WebRTC," and Octo writes that "fully disabling WebRTC may look rather suspicious." Check Point's October 2026 report lists "WebRTC suppression patterns" among the indicators platforms should look for, and GoLogin adds a practical cost: "Off disables WebRTC entirely, which some sites require enabled to function correctly."

AdsPower is the exception. Its default is Disabled. AdsPower says that "instead of blocking the browser API (which websites can detect), AdsPower intercepts traffic," so that "Websites interpret the block as a firewall or network restriction." If you use AdsPower with static proxies, decide consciously whether you want that default or Replace.

Replacing isn't invisible either. AdsPower describes its Replace mode as "Good for general use, but advanced sites may detect the replacement." Linken Sphere goes further: "Partial WebRTC functionality during substitution is one of the side effects actively used by anti-fraud systems to detect multi-accounting," and it adds that the mechanism "in most anti-detect browsers is implemented similarly." No mode leaves no trace. Replacing keeps the profile closest to an ordinary Chrome with WebRTC on, and it's the default at most of the vendors above.

With rotating proxies, the replaced IP has to follow the proxy. Multilogin's Masked mode does: "If the proxy IP changes while the profile is running, the WebRTC value updates too." Linken Sphere has a Live mode "designed for dynamic proxies with timer rotation" that keeps WebRTC, languages, geo and time zone matched to the current IP. Hidemyacc fixes the WebRTC address at launch, so with a rotating proxy it says "the safest option is to select Disable." If your antidetect's docs don't say, rotate the proxy during a test session and run a WebRTC test again.

How can DNS give you away?

A DNS leak test shows who resolves your lookups. BrowserLeaks describes its test as finding "which DNS servers your browser is using to resolve domain names" by resolving 50 random domain names, and warns that "faulty VPN/proxy software can lead to your device sending DNS requests directly to your ISP's server." If those servers belong to your home provider while your proxy sits in another country, the site has learned where you really are.

With the right proxy type, Chrome resolves names at the proxy. Chromium's proxy documentation: "When using an HTTP proxy in Chrome, name resolution is always deferred to the proxy," and with SOCKS5 "name resolution is always done proxy side." Our proxy log confirmed it: Chrome asked the proxy to connect to host names, not to IP addresses it had looked up itself. The exception is SOCKS4, where "name resolution for target hosts is always done client side," which sends your lookups to your own resolver. Use HTTP or SOCKS5 proxies, not SOCKS4.

Other parts of the browser can still look up names themselves. Chromium's design notes on SOCKS proxies warn that "There are other components of Chrome which may issue DNS resolves directly and hence bypass this proxy server," and name "the DNS prefetcher" as the most notable. That note is old, so treat it as a reason to test rather than a diagnosis: run a DNS leak test inside every new profile with its real proxy.

Antidetects send DNS through the proxy by default. Dolphin: "The DNS comes from the proxy — meaning it uses the DNS server provided by your proxy provider." Octo: "By default (if the value is empty), the proxy or VPN DNS server will be used." Kameleo: "DNS resolution is also handled by the proxy." Octo and Linken Sphere also offer a custom DNS field, and Linken Sphere warns: "We do not recommend making changes to the DNS settings unnecessarily."

A resolver in another country isn't automatically a leak. In our own run without any proxy, BrowserLeaks found Google's public DNS servers answering from a different country than our IP. Public resolvers do that. What gives you away is your home provider's resolver next to a proxy IP somewhere else.

What does the TLS handshake say?

Your proxy passes the handshake through untouched. With an HTTP or SOCKS5 proxy, the browser opens the encrypted connection to the site itself and the proxy only tunnels it. Cloudflare describes TLS fingerprints as identifying "TLS clients based on how they initiate connections," and notes that JA4 "improves on JA3 by sorting ClientHello extensions." Chrome has shuffled the order of those extensions since early 2023, which broke the older JA3 method, so JA4 sorts them before hashing.

We tested what a fake Safari sends. We gave Chrome 156 a Safari on macOS user agent and opened BrowserLeaks' TLS page and the tls.peet.ws API. The user agent said Safari. The JA4 said t13d1517h2_8daaf6152771_cb7bf5808d99, identical to the same browser with a Chrome user agent, and the HTTP/2 fingerprint was identical too. FoxIO, the company that created JA4, lists that exact string as Chrome's JA4 in its README. The older JA3 hash changed from one connection to the next, which is the shuffling at work.

Vendors say the handshake should stay as it is. Octo: "Octo's TLS behavior is identical to that of modern Chrome," and it warns that "manually disabling important TLS extensions can break fingerprint consistency." Kameleo says JA4 fingerprints "are determined by the profile at creation and remain fixed for the lifetime of that profile," so the handshake stays consistent across sessions. Some antidetects also offer a switch to disable TLS cipher suites; by Octo's logic, leave it off unless a specific site needs it, because a Chrome that drops ciphers no longer sends Chrome's handshake.

So a profile that claims another browser needs another engine. A Chromium kernel sends a Chromium handshake whatever the user agent says, unless the vendor patches the network stack as well. That's why some vendors ship separate engines for other browsers, such as AdsPower's Firefox-based FlowerBrowser and Kameleo's Junglefox. For most media buyers the simple answer is to claim Chrome on a Chromium kernel and keep its version current.

QUIC is the next layer vendors are working on. QUIC, the UDP-based transport behind HTTP/3, has its own fingerprint: FoxIO lists a separate QUIC JA4 for Chrome. Linken Sphere enables QUIC support by default and says that "Recently, anti-bot systems have been paying more and more attention to its support," while Kameleo states that it "does not support UDP-based proxies." If your proxy carries only TCP, QUIC can't go through it.

What does the TCP connection say?

It shows the proxy, not you. Every TCP connection has a fingerprint too: how the connection opens, window sizes, options. FoxIO, describing its JA4T method, says: "When a device is connected through a Proxy, the TCP fingerprint of the proxy is seen on the server side, not the client," and that JA4T "also helps to identify intermediary proxies, VPNs, load balancers, tunneling, etc."

Detection companies compare it with the profile. Fingerprint, which sells device identification to sites, has an OS mismatch check that compares "the network signature of the request" with the operating system of the client. A Windows profile whose connections arrive from a proxy server with a different operating system is that mismatch. You can't change the TCP layer from inside the browser; it depends on the proxy. Look at your proxy's TCP fingerprint on BrowserLeaks or tls.peet.ws and factor it into which proxies you use for which profiles.

How do you test a profile for leaks?

Run 4 checks inside the profile, with the proxy you'll really use:

1. WebRTC. Open a WebRTC leak test. The public IP it finds should be your proxy's IP, or there should be none if you chose to switch WebRTC off. Your home IP means the mode is wrong.
2. DNS. Open a DNS leak test. None of the resolvers should belong to your home provider.
3. TLS. Open a TLS test and compare the JA4 with the browser your profile claims. A profile claiming Firefox or Safari shouldn't show Chrome's fingerprint.
4. TCP. Look at the proxy's TCP/IP fingerprint and note what operating system it suggests.

Repeat after every change. A new proxy, a new proxy type or a kernel update can change any of these results. For what these test sites can and can't tell you, see What Fingerprint Checkers Really Check.