You set up an antidetect browser, connected a proxy, spoofed the fingerprint — and several accounts still got linked and banned. A frequent but underrated cause is a DNS leak. This is when the traffic itself goes through the proxy, but the domain-name resolution requests escape the tunnel and reach your real ISP's DNS servers. To anti-fraud systems this is a direct signal: the IP is one thing, but the "real" network node is something else entirely. In this guide we break down the mechanics of a DNS leak and close it step by step at the browser, OS and proxy levels.

What a DNS leak is and why it's dangerous

When a browser opens a site, it first asks a DNS server: "what is this domain's IP?". If that request goes directly to your internet provider's DNS instead of through the proxy, an observer sees the user's real geography and provider — no matter which IP the proxy shows.

What it means for multi-accounting

  • Account linking — if all profiles resolve DNS through one real provider server, the platform sees a shared network footprint.
  • Geographic anomaly — proxy in one country, DNS resolver in another: a clear risk-scoring trigger.
  • Deanonymization — in critical scenarios DNS requests reveal the real provider and region regardless of the proxy.

Where the leak comes from

There are several sources, and you must close all of them at once — one open hole nullifies the rest.

HTTP proxy without DNS proxying

Many HTTP proxies resolve the domain on the client side, meaning the DNS request leaves your OS directly. SOCKS5 with remote DNS, by contrast, passes the domain name to the proxy server and resolution happens on its side — no leak.

System DNS over the tunnel

Even with a correct proxy, the operating system may simultaneously contact the DNS configured in its network settings (for example public resolvers or the router's DNS). The browser tunnel does not intercept this.

WebRTC and DNS-over-HTTPS inside the browser

Modern browsers can make their own DNS queries via DoH bypassing system settings, and WebRTC can reveal local addresses. Both features must be kept under control in multi-accounting.

How to close a DNS leak: step by step

Close it sequentially at three levels.

Level 1. The right proxy

Use proxies that resolve DNS on their side. Mobile proxies from turbon.rent run on physical SIM cards of real carriers in 17 countries via GoIP/Simpool infrastructure: traffic and DNS go through the carrier's mobile network, and IP rotation is performed on demand via API. Domain resolution happens on the mobile channel's side, not your home provider's.

  • Choose SOCKS5 with remote DNS, not HTTP.
  • One profile — one dedicated mobile channel, with no sharing between accounts.
  • Before a session, rotate the IP via API so each account gets a fresh address.

Level 2. Browser settings

  • In the antidetect browser, enable DNS over proxy (Proxy DNS / Remote DNS).
  • Disable the browser's built-in DNS-over-HTTPS or route it through the tunnel — otherwise the browser bypasses the proxy.
  • Set WebRTC to Disabled or Alter so local addresses don't leak.
  • Sync timezone and language with the mobile proxy's geolocation.

Level 3. Operating system

  • Launch profiles only through the antidetect browser with the tunnel — don't open target sites in a regular browser.
  • Check that the system has no hardcoded public DNS that the OS uses as a bypass.
  • For team work use cloud profiles with locked proxies to rule out an accidental system resolve on someone else's machine.

Leak verification checklist

After setup, always test the configuration before the first account login.

  • Run a DNS leak test — all resolvers must belong to your proxy's carrier/region, not your home provider.
  • Run a WebRTC leak test — only the proxy IP is visible, the local address is hidden.
  • Cross-check IP geolocation, timezone and browser language — they must match.
  • Make sure the number of detected DNS servers is small and stable run to run.

Frequently asked questions

Is a DNS leak possible if I use a mobile proxy?

If the proxy is set to remote DNS and the browser doesn't make its own DoH queries as a bypass — no. A leak usually arises from an HTTP proxy with local resolution or from DNS-over-HTTPS inside the browser. Mobile proxies on physical SIMs resolve domains on the mobile network's side, which closes the main leak channel.

Is it enough to switch DNS to a public resolver?

No. Changing the system DNS doesn't help: the requests still go past the proxy tunnel and reveal that your real node differs from the proxy IP. The solution is to resolve DNS on the proxy's side, not locally.

How often should I check for leaks?

Before every new profile+proxy pairing and after any update to the antidetect browser or OS. Updates often reset WebRTC and DoH settings to their defaults.

A DNS leak is a quiet but fatal account-linking factor. Close it at all three levels and verify before launch. For a stable setup connect mobile proxies from turbon.rent with remote DNS, physical SIMs in 17 countries and IP rotation via API, and for registering accounts on clean numbers use OTP activations from turbon.rent.