What a DNS Leak Is and How to Check for One

A DNS leak means the actual content of a page goes through the encrypted tunnel, but the lookup that happens right before it — "what address does this domain point to" — takes another path outside the tunnel. The content itself stays out of reach for anyone watching, but whoever can see that lookup still knows which domains you looked up. That is a specific gap in privacy protection, not the whole thing failing.

This article gives a thirty-second self-check first, then works through the common causes in order, most likely first, and finishes with what to actually do once you find one. The rule stays the same: confirm it with a self-check before deciding whether to touch system or router settings, and do not change several things at once before you know which one matters: change everything together and you will not know which change actually fixed it.

What a DNS leak actually is

Every time you browse normally, your device first has to turn a domain name into a numeric address, and that step is DNS resolution; "DNS" in everyday use refers to this layer. Without a VPN, that lookup goes straight to the resolver your carrier assigns. With a VPN connected, that same lookup should normally travel through the tunnel too, reaching a resolver on the far end.

A "leak" is when that lookup does not follow the tunnel and keeps going to a local or carrier resolver instead. The actual content — a page, a video — may genuinely be encrypted in transit, but the domain lookup slips out on its own, and whoever can see that request can still piece together a record of which sites you visited, just not what was on them. This is exactly why "connected to a VPN" and "all traffic is in the tunnel" are not the same statement, and this particular layer is the one most likely to get overlooked — it is nothing like a page failing to load. A leak usually produces no symptom at all: everything feels completely normal day to day, and the only way to notice is to go and check deliberately.

That is exactly why this layer is easy to ignore: nothing stutters, nothing throws an error, there is no warning of any kind — checking for it yourself is the only way to know.

A thirty-second self-check

The simplest method is to search for "DNS leak test," open any page that runs this kind of check, and run it once while connected. The page usually lists the region and provider of the resolver it found: compare that against your actual broadband or mobile carrier. If it shows a resolver in the tunnel's region, there is no leak; if it still shows your local carrier's name, the lookup really did slip out.

Two small details are easy to miss while testing: run the check only after the connection has been stable for a few seconds, since testing the instant it connects can still catch the state from before the switch — and if you use both a computer and a phone, test each separately rather than assuming one result applies to both, especially if they are not on the same network.

If you would rather confirm it from the command line, you can check the resolver address currently in use directly:

# macOS / Linux
scutil --dns | grep nameserver

# Windows
ipconfig /all | findstr /R "DNS"

If the address in the output falls in a range your local carrier commonly uses, rather than one belonging to the tunnel's region, that also indicates a leak. Either method is enough on its own; there is no need to run both.

Common causes, most likely first

Plenty of people have, at some point, manually entered a fixed DNS address in the system or the router to solve a different problem, like speeding up a specific site. Once that setting exists, it usually takes priority over whatever the client is trying to take over, so lookups follow the manually entered address and bypass the tunnel.

How to confirm it: think back on whether a DNS address was ever entered manually in network settings, or check the router's admin page for a similar custom entry. How to fix it: switch that setting back to automatic and let the client take over this layer itself, then test again.

Some tools only handle the data content of pages and apps, treating the domain lookup as a separate matter it never brings into the tunnel at all. In this case the data itself looks completely normal while the lookup travels outside the tunnel the whole time, and there is very little on the surface that would tip you off.

How to confirm it: if a custom DNS setting has been ruled out and the self-check still shows a leak, this layer simply never being taken over is the likely explanation. How to fix it: this is really a question of how the client itself is built, and there is not much to adjust on your end; switching to a client that routes DNS through the tunnel too is the more direct fix.

Some browsers ship their own encrypted DNS feature that bypasses system settings entirely and sends lookups straight to a server the browser itself specifies. The feature is meant to protect privacy, but if the server it points to has nothing to do with the VPN's tunnel, the practical effect is opening up a brand-new leak path instead.

How to confirm it: look in the browser's settings for anything related to "secure DNS" or "encrypted DNS," check whether it is switched on, and see which provider it points to. How to fix it: there is no need to turn the feature off entirely: point it at a server reachable through the tunnel, or disable it temporarily and let the system handle it, then decide after testing.

IPv6 is another gap that is easy to miss

With the three causes above ruled out, there is one more case worth watching for on its own: a device with both IPv4 and IPv6 connectivity, where only the IPv4 side got taken over by the tunnel. DNS lookups and actual connections over IPv6 can both bypass the tunnel entirely — the same underlying pattern as above, a lookup taking another path, except this time the connection itself leaks along with it.

This is the same root cause behind IP still shows China after VPN, just showing up two different ways across the two articles: there it is an IP check that never changes, here it is a DNS test reporting a leak, and both trace back to the IPv6 path never being handled. IPv6 has become the default on a growing share of mobile networks and home broadband over the last few years, so this kind of partial leak is not some rare edge case anymore — it is easier to run into than it used to be.

If the self-check shows a leak and IPv6 looks like the likely cause, try turning IPv6 off temporarily in the system's network settings and testing again as a comparison: if the leak disappears, that confirms it; if it is still there, the cause is one of the three above and has nothing to do with IPv6, so there is no need to leave it switched off.

What to do once you find a leak

Working through the three causes above in order pins down most leaks to a specific layer: check first for a manually entered DNS address in the system or router, then whether the client itself ever routes DNS through the tunnel, then whether the browser turned on its own encrypted DNS. After changing the relevant setting, rerun the self-check to confirm rather than assuming it is fixed just because you changed something.

If all of these are ruled out and the self-check still shows a leak, send support a screenshot of the test result along with your device model and OS version — that gets you an answer faster than continuing to guess, and makes it easier for them to tell whether it is specific to a particular version.

In summary

A DNS leak means domain lookups are taking a path outside the tunnel. What leaks is a record of which sites you visited, not the content of the pages themselves. A thirty-second self-check combined with working through the three causes by likelihood resolves most cases on your own, and IPv6 is the one corner still worth checking once the common causes are cleared.

If you would rather not re-run this check every time you get a new device or join a new network, the real fix is having the client manage this layer itself. FastOrange is built to route DNS through the tunnel automatically, with nothing to configure on the system or the router by hand. If you have worked through the steps above and still cannot confirm it, contact support with the test result attached, which makes it much faster to pin down which layer the problem is actually in. More on this area is covered under security as well.