How to Run a VPN DNS Leak Test

A DNS leak test looks easy: open a page, press a button, read a list of addresses. In practice, people run it once, see something that looks fine or alarming, and either relax or panic without knowing what the output means. The test itself is just a mirror. How you set up the experiment decides whether the reflection is useful.

This article is a method, not a definition. If you need an introduction to what DNS leaks are and why they matter, read what a DNS leak is first. Here we assume you know the idea and want to do it properly: take a baseline, test under the conditions where leaks actually happen, read the results correctly and know what to do next.

What a DNS leak test actually measures

Every time you open a website, your device first asks a DNS resolver to translate the name into an address. Without a VPN that question goes to the resolver your network gave you, usually run by your internet provider, which means it can see which names you ask for. With a VPN, those questions should travel inside the tunnel to a resolver chosen by the VPN service. A leak is when some of the questions still go out the old way.

A leak test tricks your device into asking for many unique names that only the test server knows about. The server records which resolver delivered each question, then shows you the list. So the page does not look at your VPN. It looks at who handed it the questions. That is why interpretation matters: the list is the answer to "who asked on behalf of my device?" and you need to know whom you expected.

Two facts help you read it.

1. The address on the list is the resolver, not you. It tells you which server did the asking.
2. The owner of the resolver is the key. An address belonging to your internet provider or your home router is the signal. An address belonging to the VPN service, or to the public resolver you picked, is the expected result.

For a plain explanation of the lookup process, see how DNS works or the RFC 1035 specification for the formal details.

Step 1: take a baseline before you connect

Most failed tests fail at step one, because people never saw what "normal" looks like on their own connection.

1. Disconnect the VPN completely, not just pause it.
2. Close extra browser windows and any other app that makes network requests.
3. Open a leak test page and run the standard test, then the extended one if available.
4. Write down the resolvers, who owns them and the country they appear in.
5. Note your visible public IP address.

Your baseline might show your internet provider's resolver, your router's address or a public resolver you configured earlier. It is now your reference list. Anything that appears there should not appear in the next test, unless you deliberately chose to keep it.

Keep the baseline for each network you use. The result at home differs from the result in a cafe, and the VPN should hide both.

Step 2: connect and test in a clean state

Now connect the VPN and test with these controls.

1. Wait until the app clearly shows a connected state.
2. Open a new private browsing window. Old tabs may have cached lookups.
3. Visit the test page and run the standard, then the extended test.
4. Record the new list of resolvers and owners.
5. Compare it with the baseline.

You can read the outcome using this table.

What you see	What it likely means	What to do
Resolvers owned by the VPN service only	The tunnel carries DNS	Pass for this scenario
Public resolver you chose in the VPN app	The app uses a resolver you set	Pass if it was your intent
Same resolvers as your baseline	DNS goes outside the tunnel	Treat as a leak
A mix of the two groups	Some lookups bypass the tunnel	Treat as a leak and investigate
Your browser's chosen resolver	The browser has its own DNS	Check browser DNS settings
Nothing or an error	Test blocked or page failed	Retry on another network

A single result is a data point. The next steps show whether it holds.

Step 3: test where leaks actually appear

DNS leaks are rarely constant. They happen at transitions, when software is deciding where to send traffic. Run the same test in these situations.

1. After switching servers. Change the location in the app, wait for the new connection, and repeat the test.
2. After switching networks. Move from Wi-Fi to mobile data or between two Wi-Fi networks and test again.
3. After sleep or hibernation. Close the laptop lid, reopen it and run the test as soon as the network returns, then again a minute later.
4. After a short disconnect. Briefly turn Wi-Fi off and on and test once the VPN reconnects.
5. With IPv6 on and off. Some networks give your device both IPv4 and IPv6, and DNS questions may leave over the one the VPN does not cover. See the IPv6 leak explainer for how to tell.
6. With the browser's secure DNS on and off. Browsers can use their own encrypted DNS and ignore the system resolver. Our article on DNS over HTTPS vs a VPN explains how the two interact.
7. With split tunneling on. Apps you exclude from the tunnel will also use outside DNS. That is expected, but test to confirm it applies only to the apps you chose.

If a leak appears in only one of these situations, you have already learned what to fix.

Step 4: go beyond the web page

A test page measures your browser's lookups. Other software can behave differently, so cross-check from the command line or with a second app.

• Ask a name and see who answers. Tools such as nslookup or dig show which server answered. Run one against a made-up subdomain of a domain you control or a known name and look at the "Server" line.
• Check the configured DNS. In your system network settings, see which resolver addresses the VPN adapter uses. On Windows, ipconfig /all lists them. On macOS, scutil --dns shows resolver order. On Linux, check the resolver configuration for your system. The platform guides on Windows DNS leaks and Mac DNS leaks cover the details.
• Capture traffic if you are comfortable. A packet capture on the network interface, filtered for DNS on port 53, shows whether plain lookups leave the machine outside the tunnel. This is the most direct evidence, but it needs some skill.
• Use a second device. If you can, test from a phone and a laptop on the same account. If only one leaks, the app or the operating system settings on that device are the cause.

Our overview of how to test a VPN places the DNS test alongside IP, kill switch and speed checks, and the browser-focused guide to browser leak tests explains what those pages can and cannot reveal.

Reading false alarms and false comfort

Not every surprise is a leak, and not every clean result is clean.

False alarms

• The test shows a resolver in a country different from the one you expect. Large resolver operators use many locations, and the test may show whichever answered.
• The test shows several addresses from one operator. That is normal load spreading.
• The resolver belongs to a public service you configured in the VPN app. That is your choice, not a leak.
• A corporate or school VPN intentionally uses the organisation's resolver. Check the policy of the network you are on.

False comfort

• The page shows only the resolver of the VPN but you tested once, in a stable state, and never repeated it.
• The IP address looks right, which tells you about traffic, not about DNS.
• Your browser's secure DNS hides the leak from the web page but not from other apps.
• A cached lookup meant the test never needed a new question.

Remember that a clean result proves behaviour at the moment of testing. It does not guarantee the next hour.

Three worked examples

The laptop that leaks after sleep. Mia tests at her desk and sees only the VPN's resolver. Later she closes the lid, reopens it in a cafe and tests again straight away. The list now includes the cafe's resolver for about thirty seconds before correcting itself. She learns that her laptop answers DNS before the VPN has reconnected. She enables the app's automatic protection setting and avoids opening new tabs until the status shows connected.

The browser with its own DNS. Jonas runs the test and sees a public resolver he does not recognise. The VPN app is on and the system DNS is correct. After checking, he finds that his browser's secure DNS option points to a public resolver. He decides he wants lookups to follow the VPN, so he sets the browser to use the system resolver. The next test shows only the VPN's resolver.

The IPv6 detour. Aiko's home network gives her IPv6 as well as IPv4. Her baseline shows her provider's resolver on both. With the VPN on, the IPv4 list is clean, but the extended test still shows her provider on IPv6. She turns off IPv6 on the network adapter, retests and sees a clean list. She also notes this for the next network, since each network behaves differently.

What to do when you find a leak

1. Reconnect and repeat. Disconnect fully, reconnect, wait for the connected state and retest. A single bad result after a transition may not recur.
2. Update the app and operating system. Fixes for leaks are common in updates.
3. Look for a DNS or leak-protection setting in the app, and enable it if it is off.
4. Disable the competing path. Turn off IPv6 on the adapter, or disable the browser's own DNS, if the test pointed there.
5. Check split tunneling. Make sure the app under test is not excluded.
6. Clear the DNS cache on the device so that old lookups do not skew the results.
7. Try another network. If the leak appears only on one Wi-Fi network, the router may be hijacking DNS. Compare with mobile data.
8. Contact support with your baseline, the leaking list, the situation in which it appeared and the app version.

If you use the free VPNclient app with an XPASS pass, the My Pass page and the help guides explain setup and troubleshooting. The guide to checking if your VPN is working walks through basic checks in a more general way.

Limits of any leak test

• A test page can only see what reaches its own server.
• It cannot prove that no leak will ever occur.
• It does not test your applications that use their own DNS methods.
• It cannot tell you what your VPN provider does with the lookups it receives. That is a question of the provider's terms and trustworthiness.
• A test run on a network that blocks the test site will show nothing at all.

Treat the test as one measurement in a routine: baseline, connect, test, stress the transitions, repeat after updates.

Summary

A good DNS leak test starts with a baseline taken without the VPN, then compares a clean, connected state against it. Read the results by who owns the resolvers, not by how many there are or where they appear to be. Repeat the test after switching servers and networks, after sleep, with and without IPv6 and with the browser's own DNS on and off, because leaks mostly happen at transitions. Cross-check with a command-line tool where you can, and when a leak shows up, work through the fixes in order.

If you would like a prepaid pass to run these checks on your own devices, you can see the options on the pricing page.