DNS Leak Test: Find Out Where Your Queries Really Go
- A Resolver Name Is a Clue, Not a Packet Trace
- Freeze the Disconnected Baseline First
- Make the Connected Test Change One Thing
- A Different Resolver Can Still Be Inside the Tunnel
- Browser Tests Cannot Acquit Every App
- Leaks Like the Moment Between Two Networks
- Fix the Controller, Not the Label
- End With the Same Test That Found the Problem
Your VPN says Connected. The public IP looks right. Then a DNS test prints the name of your home internet provider. That one line can expose a real routing mistake—or send you chasing a leak that never happened.
Imagine the test at 11:47 p.m. on hotel Wi-Fi. Your browser asks for a site's address before opening the encrypted page. You need to know who received that lookup, how it traveled, and whether the result differs from the route you intended.
A reliable DNS leak test is a comparison, not a screenshot: disconnect, record the baseline, connect, test again, then reproduce the result across browsers, servers, and network changes.
A Resolver Name Is a Clue, Not a Packet Trace
DNS turns a name such as example.com into the address a device needs for a connection. The query can disclose the requested domain and source addressing information to the resolver. The IETF's DNS privacy analysis also notes that DNS may take a different path from the application traffic it enables.
That doesn't mean a lookup reveals the exact page, search phrase, message, or contents later protected by HTTPS. It can still create a revealing domain-level history: asking for a health clinic's domain says less than an exact URL, but it may say more than you wanted a network observer to know.
Without a VPN, the resolver may be run by your ISP, router, employer, mobile carrier, or a service you selected. With a VPN, many apps send DNS through the tunnel to the provider's resolver or a documented partner. The expected answer depends on your configuration.
Follow the observers. On an ordinary unencrypted DNS route, the local network can see the lookup and the resolver receives it. With DNS correctly carried inside a full-device VPN tunnel, the local network sees the encrypted connection to the VPN server; the VPN-side resolver or its partner handles the query. With DNS over HTTPS, the chosen public resolver receives an encrypted lookup—but you still need to establish whether that encrypted connection traveled inside or outside the VPN tunnel.
That is why “I see Cloud Company X” isn't a diagnosis. The organization may host the VPN's resolver, operate a public resolver selected by your browser, or appear in an imperfect IP-registration database.
A small VPN gateway can be useful when you deliberately want router-level control over the route and resolver for devices that lack native apps. It also adds another DNS setting to document and test.
- Sits on a wired network as a dedicated gateway for OpenVPN or WireGuard traffic
- Can run VPN client and server roles together for remote access and protected outbound browsing
- Has no Wi-Fi radio, making it best for pairing with an existing router or access point
If you move the VPN to a gateway, write down which devices use it, which DNS server the gateway assigns, and what happens when its tunnel is down. Centralizing the route can make behavior consistent, but only if the bypass and failure states are visible.
Freeze the Disconnected Baseline First
Turn the VPN off. Close or pause noisy background apps if practical, then open a reputable testing page such as DNSLeakTest. Run the standard test and the extended test.
Record the time, network, device, browser, resolver addresses, organization labels, and countries shown. Also record the ordinary public IP and whether the browser has custom secure DNS enabled. This baseline can reveal network details, so don't post it in a public troubleshooting forum without masking addresses.
The baseline may not name your ISP. A browser could use a custom public resolver; the operating system could use an encrypted DNS profile; the router could forward requests upstream; or a work profile could enforce its own choice. Check settings before declaring the test wrong.
Chrome, for example, can use the current service provider or a custom resolver. Google's Secure DNS documentation says automatic mode may fall back to an unencrypted lookup if secure lookup fails, while a custom provider behaves differently. Managed-device and parental-control policies can also affect the feature.
Write the baseline down anyway. You need a known “before” state even when it isn't the one you expected.
Make the Connected Test Change One Thing
Connect to one nearby VPN server and wait for the app to settle. Confirm that the public IP changes to the expected VPN route. Open a new private window so cached site state is less likely to confuse the comparison, then run the same standard and extended DNS tests.
Normally, you expect the ISP resolver from the disconnected baseline to disappear and a resolver associated with the VPN or its documented partner to appear. Country labels may not match the exit location because DNS infrastructure and IP registration aren't perfect geographic maps.
Run a second test surface, such as BrowserLeaks DNS, before changing any setting. Agreement between two pages strengthens the observation. Disagreement is a prompt to investigate what each test generates and what the browser caches; it isn't permission to average the results.
Switch to one other VPN server and repeat. One clean exit doesn't prove every server, protocol, or application path is clean. One surprising exit doesn't prove the whole service leaks.
A Different Resolver Can Still Be Inside the Tunnel
DNS over HTTPS encrypts the client-to-resolver exchange. RFC 8484 specifies that encrypted transport and server authentication. It does not say the selected resolver must belong to your VPN.
Suppose the browser is configured to use a public DoH service. The test may show that service rather than CyberGhost, NordVPN, or another provider. If the browser's encrypted connection to the DoH resolver itself travels through the VPN tunnel, the hotel and home ISP still do not see the clear DNS query. The VPN provider sees the connection to the resolver, and the resolver sees the query. That differs from the provider's default design, but it isn't necessarily a leak outside the tunnel.
Now suppose the operating system routes that DoH connection around the VPN because of a split rule or competing network profile. The local network can observe the connection to the public resolver, though not the encrypted query contents; the destination route may still use the VPN. That may violate your intended threat model even though the lookup remains encrypted.
If the site traffic still uses the VPN, the website sees the VPN exit address in both cases; the VPN provider sees the DoH connection only on the inside-tunnel route, while the local network or ISP sees that encrypted connection only on the bypass route.
The resolver remains an observer either way. The IETF's guidance for DNS privacy services says encrypted transport doesn't prevent the resolver operator from seeing query data in principle. Encryption changes who can observe the path. It doesn't erase trust.
Browser Tests Cannot Acquit Every App
A web test exercises lookups generated in a browser. It doesn't directly prove how a game, mail client, operating-system updater, smart television, or background service resolves names.
Repeat the test in every browser you rely on, especially one with custom secure DNS. If only one browser shows the unexpected resolver, start with that browser's policy and settings. If every browser shows it, move outward to the operating system, VPN app, router, and network.
Deeper testing can use operating-system diagnostics or a packet capture to inspect destinations and interfaces. That evidence is stronger but easier to misread. Encrypted DNS deliberately hides the query contents, and seeing packets to a resolver doesn't alone tell you which application caused them or whether they traveled inside another encrypted interface.
Capture only your own authorized traffic, note every interface involved, and avoid uploading raw traces that may contain private addresses, hostnames, or tokens. If that sounds unfamiliar, a clean baseline and two web tests are safer evidence to send privately to provider support.
Leaks Like the Moment Between Two Networks
Keep the connected test page ready, close the laptop lid, wait, wake it, and run the test again. Move from home Wi-Fi to a phone hotspot. On mobile, switch between Wi-Fi and cellular. Interrupt the tunnel and observe whether traffic stops or silently uses the ordinary route.
A stable connection can look perfect while the transition leaks. The operating system may regain an ordinary route before the VPN app restores its tunnel. A reactive kill switch may behave differently from a setting that blocks all non-VPN traffic whenever the app is disconnected.
Test the state before login, after reboot, after sleep, and during a server change. Record the first public IP and resolver that answer after each transition. “It reconnects quickly” is less important than what escaped during those seconds.
Router DNS adds another observer. Your device may ask the router, the router may forward to an ISP or public service, and a router-level VPN may apply only to selected clients. Draw those arrows before changing settings.
Fix the Controller, Not the Label
Competing controllers cause many surprises: manual DNS entries, browser DoH, security suites, parental controls, corporate profiles, ad blockers, another VPN, split tunneling, IPv6 policy, and router-level forwarding.
Change one component at a time. First enable the VPN app's supported DNS leak protection and reconnect. Temporarily remove an unnecessary custom resolver. Test another documented protocol and nearby server. Update the VPN app and operating system. Repeat the same baseline and connected probes after each change.
If one browser differs, disable its custom secure DNS for one test or set it to follow the operating system. If a security product manages DNS, decide which tool should own the route. Two “privacy” features fighting over one resolver can create a result neither interface explains.
Don't permanently disable IPv6 because one test printed an IPv6 address. Confirm whether it belongs to the direct connection or the VPN path and use the provider's supported IPv6 handling. Blindly removing the protocol can hide the symptom while breaking connectivity or leaving the real routing conflict untouched.
When asking support, include the device, OS and app versions, VPN server, protocol, network type, browser secure-DNS state, and masked before-and-after results. “DNS leaks” is vague. “The disconnected ISP resolver reappears only after macOS wakes on this Wi-Fi” is actionable.
A network controller can make router-level DNS and VPN policy easier to centralize in a larger setup, but it is not a cure by itself. Buy network hardware only when you are prepared to own its routes, updates, and failure tests.
- Runs UniFi Network management for a consolidated view of devices, traffic, and gateway settings
- Combines gigabit routing, intrusion detection and prevention, and multi-WAN support in a compact console
- Manages separate UniFi access points rather than broadcasting Wi-Fi on its own
Whatever hardware owns the policy, export or record the working rules before an update. The useful outcome is not a more elaborate dashboard; it is a baseline you can restore and a transition test you can run again.
End With the Same Test That Found the Problem
After the fix, recreate the original failure. Run the disconnected baseline, connect to the same server, use the same browser, and repeat the transition that exposed the resolver. Then test one second server, browser, and network.
A clean result means the observed resolver path now matches your design in those tested states. It doesn't certify every app forever. Save the working settings and retest after major browser, VPN, router, or operating-system updates.
The goal isn't a page full of unfamiliar company names. It's a route you can explain: who received the DNS query, whether the local network could read it, whether it stayed inside the protection you intended, and what changes when the tunnel fails.