DNS Leaks on Mobile Proxies — How They Happen, and How We Found Ours

A proxy can be exiting from exactly the right place and still tell the world where you really are. DNS is a separate path from your traffic, and it does not automatically follow the tunnel just because your bytes do.

We know this specifically rather than abstractly, because we shipped a fleet-wide DNS leak. Our exit addresses were correct, our dashboards were green, traffic left through the carrier exactly as designed, and the hostname lookups did not. The story is below in full, including the part where nothing in our monitoring noticed.

This page covers what a leak is, why it breaks connections rather than merely exposing them, the one-character cause behind most of them, and a two-minute test you can run against any provider — including us.

What a DNS leak actually is

A DNS leak is when your traffic exits through the proxy but the hostname lookups that precede it are answered by a resolver outside the proxy path. The destination logs the proxy's address. A third party logs every hostname you asked for, in order. Both statements are true at the same time.

Every connection to a name begins with a lookup. Before your client can open a socket to example.com, something has to turn that name into an address. That "something" can sit in one of three places, and which one it is decides whether you are leaking.

Notice that the third column is identical in all three rows. This is the entire trap. The test everybody runs — "what is my IP through the proxy?" — cannot distinguish between these cases. It returns the right answer in all of them, which is why leaks survive so long in production.

The full path a request takes is covered in how mobile proxies actually work; the relevant part here is that the tunnel carries bytes, and a hostname is not bytes until someone resolves it.

Why a leak breaks connections, not just privacy

The privacy cost is obvious: a resolver holding a timestamped list of every hostname you visited is a complete browsing history under a different name. The under-discussed cost is routing. Large sites answer DNS differently depending on where the query originated, so a leaked lookup does not just reveal your location — it changes which server you connect to.

Content delivery networks and any platform running geo-aware DNS return an address for an edge node close to the resolver that asked. That is the point of the mechanism: put the user on the nearest server. It works perfectly, and against you, when the resolver is in the wrong place.

What that produces in practice:

• Correct IP, wrong edge. Your connection arrives at an edge node chosen for a network hundreds or thousands of miles away from the IP it is coming from.
• Slow connects and long handshakes, because the path is not the one the routing was optimised for.
• Intermittent failures that look like a broken proxy. A request works, the next one hits a different edge in the set and does not, and refreshing "fixes" it. This is the classic works-then-mysteriously-fails signature.
• Inconsistent behaviour between a hostname and a literal IP. This one is worth testing directly, because it isolates the resolution layer from everything else: if dialling by IP is stable and dialling by hostname is not, the fault is in resolution, not connectivity.

There is also the correlation problem. Any system comparing where the query came from against where the connection came from sees a contradiction a real phone would never produce. A genuine subscriber resolves through their carrier and connects through their carrier. Those two facts agree by construction, and when they disagree, something is proxying.

The usual cause: socks5 versus socks5h

Most client-side leaks come down to one character in the scheme. socks5:// instructs your client to resolve the hostname locally and hand the proxy a bare IP address. socks5h:// hands the hostname itself to the proxy and lets the far end resolve it. The h means "resolve at the proxy", and it is the single most common misconfiguration in proxy work.

The behaviour differs across the tools you are likely to use:

Two things follow from that table that people routinely get wrong.

First, an HTTP proxy using CONNECT does not have this failure mode for HTTPS traffic, because the hostname is in the request by protocol design. That is a genuine point in its favour and one of the few places where the SOCKS5 versus HTTP choice has a security consequence rather than an ergonomic one.

Second, socks5h:// only moves the problem one hop. It stops your machine from resolving, and it hands the job to the proxy. Whether that is an improvement depends entirely on where the proxy resolves, which brings us to our own bug.

How we found our own DNS leak

We had a fleet-wide DNS leak. Hostname resolution was happening on our relay infrastructure rather than on the phone, so DNS queries reflected the datacenter's network while the traffic itself correctly exited through the device's cellular connection. Customers using socks5h:// — the correct setting — were still leaking, one layer further along than they expected.

Structurally it was the second row of the table above. The exit IP was a carrier address, the tunnel worked, rotation worked. Every check we had measured the traffic path, and the traffic path was fine. The lookup path resolved in a datacenter, and nothing in the system compared the two.

The fix was to move resolution onto the device: the hostname travels through the tunnel unresolved, the phone performs the lookup over its own cellular connection, and the socket is opened to whatever the carrier's resolver returned. After the change, DNS-leak tests show the mobile carrier, which is what a real mobile connection looks like from the outside.

Two lessons are worth stating plainly, because both cost us something.

A proxy can be exiting from exactly the right place and still leak. We were not routing traffic wrong. The exit was correct, verifiable, and carrier-issued. DNS is simply a different path, and correctness on one says nothing about the other. Any architecture that resolves names anywhere other than the exit point has this bug available to it, whether or not it has shipped yet.

We did not find this from monitoring. Someone ran a leak test. There is no dashboard reading that would have surfaced it, because every metric we collected described the traffic path. This is the uncomfortable part of the story and the reason it is on this page: the failure was invisible from the inside and obvious from the outside, and the only difference between those two states was somebody spending two minutes on a test page.

We now treat "fixed" as meaning we have the output of a leak test in front of us, not that the code change deployed. Those are different claims and we have been wrong about the gap between them before.

If you are evaluating a provider — including this one — the correct response to any architectural claim about DNS is to test it yourself. Here is how.

Test any provider for this in two minutes

You are checking two facts independently: what the destination sees, and who answered your lookups. A leak is any case where those two answers come from different networks. It takes one command and one browser tab, and it works against any provider regardless of what their documentation says.

Step 1 — confirm the exit IP. Send a request through the proxy and record the address the destination reports.

curl -x socks5h://user:pass@your-proxy-host:port https://api.ipify.org

Step 2 — check who answered the DNS. Open a DNS-leak test page in a browser configured to use the same proxy, and read the organisation or ASN behind each resolver it lists. Any leak-test page that reports the resolvers used will do; you are reading the network they belong to, not the individual addresses.

Step 3 — compare the two. Look up the organisation behind the exit IP from step 1 and compare it against the resolvers from step 2. Same carrier network means resolution is happening at the exit. Anything else is a leak, and which thing else tells you which layer is responsible.

Step 4 — isolate the layer. Repeat step 2 with socks5:// and again with socks5h://. If the resolvers change, the fault was client-side and you have just fixed it. If they stay in a hosting network with both, resolution is happening at the provider and no client-side setting will move it.

Interpreting the result:

Two practical notes. Run the test inside the profile you actually work in — an anti-detect profile carries its own DNS setting, which is why the AdsPower and GoLogin setup pages cover resolution and not just the connection fields. And run it more than once, since a single result can catch a cached answer rather than a live lookup.

What fixing DNS does not fix

Removing a DNS leak removes one contradiction: the location implied by your lookups no longer disagrees with the location implied by your IP. That is a prerequisite for looking like a real mobile client. It is not a result on its own, and it is a small part of what a detection system actually weighs.

Three things it explicitly does not address:

WebRTC is a separate path. It uses UDP, does its own address discovery, and can enumerate addresses without touching your proxy at all. Correct DNS does nothing about it — that is a different leak with a different test.

IP reputation is unrelated. Clean DNS on an address with a bad history is still a bad address. What actually drives reputation scoring is carrier classification and abuse history, not resolver consistency.

Fingerprinting is untouched. Canvas, fonts, screen metrics, timezone and TLS characteristics travel with your client. Twenty profiles sharing one fingerprint remain one identity no matter how correctly each of them resolves.

There is also an honest cost to on-device resolution: the lookup now crosses a cellular link, so first connections to a new hostname take marginally longer than they would against a datacenter resolver. And the device's resolver cache becomes a thing that can go stale — if SOCKS5 with a hostname starts failing in hundredths of a second while the same request to a literal IP succeeds, that signature is a stale cache, not a network fault.

How we handle DNS now

Hostnames travel through the tunnel unresolved and are resolved on the device, over the same cellular connection that carries the traffic. The query goes to the carrier's resolvers, the answer reflects the carrier's view of the network, and the phone connects to whatever edge a real subscriber on that network would have been given.

The limits, stated openly. We cannot stop your own machine from resolving locally if you configure socks5:// — that decision is made in your client before anything reaches us. We do not control what an anti-detect browser does inside a profile you built. And our egress is IPv4-only today, which is a genuine gap on the small number of platforms that specifically expect mobile clients to arrive over IPv6.

What we will do is answer the question. If you ask where resolution happens on our infrastructure, the answer is the device, and the two-minute test above will confirm or contradict that without taking our word for it. A provider who cannot tell you where their DNS resolves has the same blind spot we had — the difference is whether anyone has run the test yet.

Frequently asked questions

What is a proxy DNS leak?

It is when your connections exit through the proxy but the hostname lookups that precede them are answered by a resolver outside the proxy path. The destination sees the proxy's address, while a third-party resolver sees the full list of hostnames you requested. Traffic and DNS travel independently, so one can be correct while the other is not.

How do I test whether my proxy is leaking DNS?

Send traffic through the proxy and check two things separately: the exit IP the destination logs, and the organisation behind the resolvers that answered your lookups. If the resolvers belong to your own ISP, your client is resolving locally. If they belong to a hosting provider, the proxy is resolving in a datacenter. Only carrier resolvers match a genuine mobile exit.

What is the difference between socks5:// and socks5h://?

With socks5://, your client resolves the hostname itself and hands the proxy an IP address, so every lookup goes to your local resolver. With socks5h://, the hostname is passed through the proxy and resolved at the far end. The h stands for hostname resolution at the proxy, and it is the setting most people get wrong.

Can a proxy leak DNS even when the exit IP is correct?

Yes, and this is the case people miss. The exit IP tells you where the TCP connection came from. It says nothing about where the lookup that produced that connection was answered. We had exactly this on our own fleet: traffic exited via the phone's carrier connection while hostname resolution was still happening upstream.

Why would a DNS leak cause a site to fail rather than just leak information?

Because large sites use DNS to steer you to a nearby server. If your query is answered based on the resolver's location rather than the proxy's, you get an address for an edge node near the resolver. The connection then arrives at that edge from an IP on the other side of the country, which produces slow handshakes, occasional misroutes, and intermittent failures.

Does fixing a DNS leak make me undetectable?

No. It removes one contradiction — DNS location disagreeing with IP location. WebRTC can still expose addresses over a separate UDP path, browser fingerprinting is untouched, and IP reputation is a different question entirely. Consistent DNS is a prerequisite, not a result.