A VPN can change the public IP address shown to websites without guaranteeing that every connection detail is hidden. DNS requests may still be sent to the internet provider, a workplace resolver, or a manually configured third-party service. WebRTC can expose local or network-related addresses in a browser, while applications may use their own name-resolution path instead of the operating system’s tunnel. A DNS leak check is therefore useful, but it should be treated as one diagnostic step rather than proof of complete anonymity.
This guide explains how DNS leaks happen, how to test them without misreading normal results, and how to fix the most common causes on Windows, macOS, Android, iOS, and Linux. It also covers official VPN clients, Clash Verge, sing-box, and Shadowrocket, because importing a subscription is only the beginning: the client must also apply the intended DNS policy, traffic mode, and fallback behavior.
What a DNS leak reveals
DNS, or the Domain Name System, translates a hostname such as example.com into an address that a device can connect to. In a normal home connection, the router often forwards these requests to the internet provider’s resolver. The resolver may receive the domain name, the requesting time, and an address associated with the connection. Even when a VPN changes the visible IP address, a resolver outside the VPN path may still observe the domains being requested.
A DNS leak occurs when a request that should follow the VPN’s protected route is instead sent through another resolver or network interface. Common causes include a client that changes only the system proxy, an operating system that retains an old DNS server, split tunneling configured too broadly, an IPv6 path that the client does not handle, or an application that uses its own encrypted DNS service. A sudden network change can also expose a short period of traffic before the tunnel has fully reconnected.
110+
Countries covered
160+
Available routes
5
Supported platforms
7 days
Refund window
The resolver’s name is not always enough to determine whether a leak exists. A provider may operate resolvers in multiple regions, and a test page may label an address according to a database that is not perfectly current. Conversely, seeing a familiar public resolver does not automatically mean the connection is unsafe if the VPN intentionally routes DNS through that resolver inside its tunnel. The important questions are whether the request left through the expected interface, whether the resolver is consistent with the client’s documented design, and whether the result changes when the tunnel is disconnected.
How to run a DNS leak check correctly
Start with a baseline. Disconnect the VPN, open a DNS testing page, and record the resolver organization and approximate location shown by the test. Do not treat the baseline as a security failure; it simply tells you what the network uses without a tunnel. Close unnecessary browser tabs and applications if you want a cleaner comparison, because browsers and software may issue background requests.
Next, connect the VPN using the client and route you normally use. Wait until the client reports that the connection is active, then run the same test again. A meaningful comparison uses the same device, browser, network, and test method. Repeat the check after changing to another route if the service offers several route types, because a client may apply different DNS handling to different profiles.
| Test result | What it may mean | Next verification |
|---|---|---|
| Only the VPN’s expected resolver appears | The basic DNS path is probably following the tunnel | Check after sleep, network switching, and reconnecting |
| The local ISP resolver appears while connected | DNS may be escaping through the physical interface or router | Review client DNS mode, IPv6, and split-tunnel rules |
| Several resolvers from different networks appear | Multiple interfaces, fallback resolvers, or browser-specific DNS may be active | Test with browser secure DNS disabled temporarily and inspect adapters |
| The result is unchanged with or without VPN | The client may not control system DNS, or the test may be using its own resolver | Compare command-line queries and inspect the active connection |
| No result or the page cannot load | The DNS policy may be blocking the test, or the tunnel is not fully connected | Test a normal website, then review client logs and fallback behavior |
A browser test is convenient but not definitive. On Windows, nslookup example.com can show the resolver selected by the operating system. On Linux, resolvectl status and resolvectl query example.com can reveal per-interface DNS settings when systemd-resolved is in use. On macOS, scutil --dns lists resolver scopes. These commands do not replace an external test, but they help distinguish a browser result from an operating-system configuration problem.
Run the test more than once during the same troubleshooting session. Check immediately after connecting, after disconnecting, and after reconnecting following a network change. If the local resolver appears only during reconnection, the issue may be a temporary fail-open window rather than a persistent setting. That distinction matters: the remedy may be enabling a kill switch or blocking traffic until the tunnel is ready, instead of changing every DNS entry manually.
Fix the client and DNS settings
Before changing settings, export or note the current profile if the client supports it. A subscription import usually supplies servers, credentials, and route information, but DNS behavior can remain controlled by local settings. In an official client, look for options named DNS protection, secure DNS, prevent DNS leaks, kill switch, block connections without VPN, IPv6 handling, or split tunneling. The exact names vary by version, so confirm what the switch actually controls rather than enabling every option blindly.
Official client workflow
On Windows and macOS, connect through the official client, enable its DNS leak protection if available, and confirm whether the kill switch is enabled for the networks you use. If the client offers automatic DNS, prefer that for the first test. Manually entering a public resolver can make a test appear consistent while still leaving the request outside the VPN tunnel. After changing the setting, disconnect completely, reconnect, flush local caches, and run both an external test and a command-line query.
On Android and iOS, review the system’s private or encrypted DNS setting as well as the VPN application. Android may have a global Private DNS hostname that continues to influence applications, while browsers can have their own secure DNS preference. iOS applications may use platform networking APIs or application-specific resolvers. If a leak test disagrees with the client status, temporarily disable browser-specific secure DNS, reconnect the VPN, and compare again. Restore the browser setting afterward only if you understand which resolver it uses and whether that behavior matches your privacy goal.
On Linux, check the interaction between NetworkManager, systemd-resolved, the desktop environment, and the VPN client. A tunnel may be active while the default resolver remains attached to the physical interface. Inspect the resolver scope before and after connection, and avoid running two network managers that both rewrite DNS configuration. If you use a graphical client, its log may identify whether it installs a tunnel interface, changes resolver routes, or merely sets a proxy.
Clash Verge, sing-box, and Shadowrocket
Third-party clients expose more routing choices, which also creates more ways to produce an unexpected result. In Clash Verge, review the DNS section, fake-IP or redir-host mode, enhanced mode, and the rules that decide whether a query is sent through the proxy. A fake-IP address shown inside a diagnostic tool is not automatically a leak; the question is whether the DNS query is handled by the configured DNS engine and whether the final connection follows the intended rule. Keep the DNS mode consistent while comparing tests.
sing-box configurations commonly separate DNS servers, routing rules, detours, and final outbound selections. Check the DNS rules before checking the proxy nodes. A DNS server may be defined correctly but still use a direct detour if the rule set sends it outside the tunnel. Also inspect whether fallback or backup resolvers are enabled. A fallback can improve connectivity, but it changes the conditions under which requests leave through another path.
Shadowrocket on iOS provides DNS and routing controls that may differ between global, rule-based, and proxy modes. Review the DNS method, matching rules, and whether a request is treated as direct traffic. When testing, avoid changing the profile, mode, and route at the same time. Make one change, reconnect, clear the relevant cache, and test again. This makes it possible to identify whether the issue came from DNS selection, routing, or the selected server.
- ✅ Use one active VPN or proxy client while troubleshooting.
- ✅ Check IPv4 and IPv6 behavior separately when the network supports both.
- ✅ Test after importing a subscription and again after editing its DNS rules.
- ❌ Do not assume a connected icon proves that every application uses the tunnel.
- ❌ Do not add random DNS addresses without understanding their routing path.
A hands-on troubleshooting sequence
Use the following sequence when the test shows an unexpected resolver. It is deliberately conservative and works across official clients and compatible third-party clients.
- Record the state: Note the operating system, client name, active mode, selected route, and the resolver shown while disconnected and connected.
- Stop competing software: Exit other VPN clients, proxy helpers, network optimizers, and security tools that install virtual adapters or rewrite DNS.
- Reconnect cleanly: Disconnect the profile, wait for the client to finish restoring the network, then connect again. Do not judge the result while the client still says connecting.
- Inspect the active interface: Confirm that the VPN tunnel interface exists and that the default route or DNS route points where the client expects.
- Review DNS rules: Check direct, proxy, fake-IP, encrypted DNS, fallback, and split-tunnel rules. Pay particular attention to rules for local domains and private address ranges.
- Test command-line resolution: Use the operating system’s resolver tools and compare their output with the browser test. A mismatch suggests browser-level secure DNS or application-specific behavior.
- Check IPv6: If IPv6 remains outside the tunnel, either enable proper IPv6 handling in the client or disable IPv6 only as a temporary diagnostic step. Do not leave a network feature disabled without understanding its effect.
- Repeat after a network change: Test after moving between Wi-Fi and mobile data, waking the device, or restarting the client. A fix that works only on the original network is incomplete.
DNS cache flushing can remove stale answers, but it does not repair routing. On Windows, ipconfig /flushdns clears the local resolver cache. On macOS and Linux, the appropriate cache service depends on the operating system and configuration. Restarting a client may be safer than copying a command from an unrelated version. If normal websites fail after enabling leak protection, check whether the selected DNS service is reachable through the chosen route and whether local-network exceptions are required.
DNS is not the only connection detail
WebRTC is a browser communication technology used by calls, meetings, and peer-to-peer features. Depending on the browser and permission state, WebRTC may reveal local interface information or candidate addresses that are different from the public address shown by a standard web request. A DNS test cannot detect every WebRTC behavior. Review the browser’s privacy and WebRTC-related settings, keep the browser updated, and use a controlled test page only when you understand what information it is requesting.
Applications can also bypass system settings. A streaming application, game launcher, messaging client, or security product may use its own resolver, a built-in proxy, or a hard-coded service endpoint. Split tunneling can intentionally send selected applications directly to the internet. That is useful for local services and latency-sensitive software, but it means a whole-device leak test cannot describe every application path.
Local network access is another separate concern. A VPN may deliberately preserve access to private addresses so that printers, NAS devices, or routers remain reachable. Seeing a private address in a local diagnostic result is not the same as exposing your public IP to a website. Evaluate public address, DNS resolver, local-network reachability, and application routing as separate properties.
How to evaluate logging claims
A DNS leak check cannot prove that a provider keeps no logs. It shows the resolver visible during your test, while logging is a policy and operational question. Read the privacy policy for the categories collected, retention periods, account identifiers, support records, payment information, security logs, and the circumstances under which data may be disclosed. “No activity logs” may coexist with limited operational records needed to prevent abuse or maintain an account.
Also distinguish the VPN provider from the DNS operator. If a profile sends queries to an external encrypted DNS service, that operator may have its own policy. Encryption protects the request from observers on the local network, but it does not make the resolver blind to the request. A provider-operated resolver may simplify routing and support, whereas an independent resolver may provide a different policy and different failure behavior.
Account practices matter as well. A service may support Windows, macOS, iOS, Android, and Linux while still identifying an account through login records, subscription credentials, or payment details. No email address may be required for registration, but that does not make activity anonymous if other account or network signals connect sessions. Avoid absolute promises and consider which information you actually need to protect.
For VFVPN, the published service facts include coverage of 110+ countries and 160+ routes, support for Windows, macOS, iOS, Android, and Linux, unlimited simultaneous device count, and a 7-day no-questions-asked refund. Those facts describe availability and plan terms; they should not be interpreted as proof of a particular DNS result or as a guarantee of anonymity. Use the client’s own DNS controls and repeat the checks on the devices and networks that matter to you.
DNS leak check FAQ
If the test shows a public DNS provider, is that automatically a leak?
No. Some VPN profiles intentionally send DNS through a public resolver inside the encrypted tunnel. Check whether the request follows the VPN interface and whether the resolver is expected for that profile. A familiar resolver name alone does not prove that traffic bypassed the tunnel.
Why does my browser test disagree with the operating system?
The browser may have secure DNS, an extension, or application-specific networking enabled. Compare the browser result with the operating system’s resolver tools, temporarily disable browser-specific DNS for diagnosis, and then decide which behavior best matches your requirements.
Should I manually set a DNS server on the router?
Not as a first fix. A manually configured router resolver can affect devices that are not using the VPN, but it does not guarantee that tunneled applications will use it. Start with the client’s DNS and routing policy, then configure the router only when you understand which devices and traffic it controls.
Does a clean DNS result mean I am anonymous?
No. Websites can still use account identity, cookies, browser fingerprinting, WebRTC behavior, application telemetry, and other signals. A clean result means that the tested DNS path did not expose the resolver you were looking for at that moment.
The most reliable troubleshooting habit is to change one variable at a time: client mode, DNS policy, IPv6 handling, browser secure DNS, or split tunneling. Keep a short record of each result and test again after reconnecting or changing networks. This turns a confusing “VPN is connected but the test looks wrong” message into a traceable routing problem, while keeping privacy expectations grounded in what the tools can actually verify.