Why can a DNS leak happen when a VPN appears connected? A VPN connection usually creates an encrypted path between your device and a remote server, but that does not automatically guarantee that every DNS request follows the same path. DNS, or the Domain Name System, translates a domain such as example.com into an IP address. If your browser or operating system sends that lookup to the local router, internet provider, workplace resolver, or a manually configured public DNS service, the request may reveal which domains you are trying to access even though your visible IP address has changed.
A DNS leak is therefore different from a failed VPN connection. The tunnel may show as connected, websites may load, and an IP checker may display the VPN server while DNS requests still leave through another route. This is especially easy to miss on laptops that move between home Wi-Fi, office networks, mobile hotspots, and public access points. Split tunneling, manual DNS settings, IPv6, browser features, and a second network client can all affect the result.
What a DNS leak reveals
When you enter a web address, your device normally needs to resolve the domain before it can establish a connection. The DNS resolver may record the requested domain, the time of the request, and information about the network that sent it. DNS does not normally contain the full page URL, form content, or message text, but the domain itself can still disclose useful context. A resolver seeing requests for a banking service, a work platform, a medical website, or a private organization may learn more than you intended to share.
DNS requests are only one part of the privacy picture. Your public IP address can suggest the network or region from which traffic appears to originate. IPv6 can expose a separate address if the VPN handles only IPv4. WebRTC can reveal local or public address candidates to a browser application when its policy allows that behavior. Cookies, browser fingerprinting, account logins, and application telemetry remain separate issues and are not automatically solved by a VPN.
DNS
Domain resolution path
IP
Visible network address
IPv6
Additional address family
WebRTC
Browser address exposure
For banking and other sensitive services, privacy checks should not be confused with security guarantees. A VPN can protect traffic on an untrusted Wi-Fi network when the tunnel is correctly established, but you should still use the bank's official application or website, verify the address carefully, enable account protections, and avoid entering credentials into a page reached through an unexpected link. For remote work, company policy may require a particular VPN, DNS resolver, device configuration, or endpoint security tool. Do not replace those controls with a personal configuration without approval.
Common causes of DNS leaks
One common cause is a client that changes the route for ordinary web traffic but leaves DNS configured at the operating-system level. The VPN tunnel may carry the browser's connection while the resolver remains the one assigned by the local router. This can happen when the client has no DNS override, when the override fails silently, or when the system gives priority to another network interface.
Another cause is split tunneling. Split tunneling intentionally sends selected applications or destinations outside the tunnel. It can be useful for local printers, corporate resources, or services that reject traffic from a remote exit. However, if the DNS process is placed outside the tunnel, domain lookups may be exposed even when the final application connection uses the VPN. Review whether the client applies split rules to DNS as well as application traffic.
IPv6 is another frequent source of confusion. A VPN can successfully provide an IPv4 address while the device continues to use its normal IPv6 route. In that situation, an IPv6-capable website may see the ISP or local network address, and DNS behavior may differ between address families. Disabling IPv6 temporarily can be a diagnostic step, but it is not always the best permanent solution. A better long-term configuration is a client and network design that handles both IPv4 and IPv6 consistently.
Browsers and operating systems can also maintain their own encrypted DNS settings. DNS over HTTPS, DNS over TLS, private DNS modes, security software, and enterprise profiles may direct queries to a resolver that the VPN client does not control. Encrypted DNS protects the request between the device and that resolver, but it does not necessarily place the request inside the VPN tunnel or hide it from the resolver itself.
Finally, two networking tools can interfere with one another. Running a VPN, a proxy client, a traffic filter, a security suite, and a second tunnel at the same time can create competing routes and DNS policies. Compatible clients such as Clash Verge, sing-box, and Shadowrocket may expose detailed DNS settings, but their behavior depends on the selected mode, rules, fake-IP or redirection design, and the underlying operating system. Importing a subscription does not automatically make every DNS option safe or compatible.
- ✅ Confirm whether the VPN client claims to protect DNS and IPv6, not only ordinary traffic.
- ✅ Review split-tunnel rules for both applications and DNS requests.
- ✅ Check whether browser Secure DNS or system Private DNS overrides the VPN policy.
- ✅ Close other VPN, proxy, firewall, or traffic-redirection tools before testing.
- ❌ Do not assume an encrypted DNS resolver is automatically a VPN-routed resolver.
- ❌ Do not treat a changed IP address as proof that DNS and WebRTC are also protected.
How to test DNS, IP, and WebRTC exposure
Testing is most useful when you compare the same device and browser before and after connecting. First, disconnect the VPN and note the visible public IP, the apparent region, and the DNS resolver organizations shown by a reputable DNS leak test. Do not focus only on the number of results. Look at who appears to be answering the requests and whether the results are consistent with the network you deliberately selected.
Next, connect the VPN and wait until the client reports a stable connection. Run an IP check in the same browser, then run a DNS leak test in a separate tab. A healthy result normally shows that the public IP has changed as expected and that DNS results are associated with the VPN route or the DNS policy you intentionally selected. A result that shows your local internet provider, office resolver, or home router deserves investigation.
Then test IPv6 separately. Some check pages display IPv4 and IPv6 independently, while others require you to inspect the full result. If the VPN provides an expected IPv4 address but the test still shows a familiar IPv6 address from your local network, the tunnel is not covering both address families. Record the result rather than repeatedly refreshing it, because resolver selection can change during a session.
WebRTC needs a browser-specific check. WebRTC is a collection of browser communication technologies used by voice, video, and peer-to-peer applications. Depending on browser permissions and implementation, a page can observe network candidates that are not visible in a normal IP check. Test in a private browser window with no unnecessary extensions, and compare the candidates shown before and after connecting. A browser extension or privacy setting that limits WebRTC may reduce exposure, but it can also affect meetings and collaboration tools.
Do not test only one website. A DNS result can be cached, a browser can use Secure DNS, and a client can apply different rules to different domains. Use a small set of independent checks, then repeat after changing one setting at a time. Avoid public “leak test” pages that ask you to install unknown software, paste your subscription link, or upload configuration files.
| Check | What it examines | Warning sign | Useful next step |
|---|---|---|---|
| Public IP | The address and apparent network seen by a website | Your normal ISP or local network still appears | Reconnect and inspect the selected route and kill-switch behavior |
| DNS resolver | Which resolver receives domain lookups | Results identify the local ISP, router, or workplace resolver | Enable the client's DNS protection or review system DNS priority |
| IPv6 | Whether a separate IPv6 route remains active | A familiar IPv6 address appears outside the VPN route | Use a client with IPv6 support or diagnose IPv6 separately |
| WebRTC | Browser network candidates used by real-time communication | Unexpected local or public candidates are displayed | Review browser privacy settings and WebRTC-related extensions |
A practical step-by-step fix workflow
Start with a clean baseline
Write down the current network type, operating system, browser, VPN client, and whether another proxy or security tool is active. Disconnect the VPN and perform the IP, DNS, IPv6, and WebRTC checks. This establishes what the local network looks like before the tunnel is enabled. If the device already has unusual DNS behavior when disconnected, fix that separately instead of attributing every result to the VPN.
Review the client DNS settings
Open the VPN client's connection or advanced network settings. Look for options described as DNS leak protection, use VPN DNS, secure DNS, remote DNS, or route DNS through tunnel. The exact labels vary by platform. On Windows and macOS, also inspect whether the client creates a virtual adapter and whether the system shows the VPN interface with a higher DNS priority. On Android, check the interaction between the client and the system Private DNS setting. On iOS, remember that VPN behavior is implemented through system network extensions, so the app's permission and on-demand status matter.
Do not select several unrelated DNS modes simply because they sound more private. Choose one deliberate policy, reconnect, clear the browser's DNS cache if appropriate, and test again. A resolver should be selected based on trust, availability, and compatibility with the VPN design. A public resolver may improve consistency, but it is still a third party that can see the queries sent to it.
Check routing and split tunneling
Temporarily switch to a full-tunnel or global mode for diagnosis. This removes many rule-related variables. If the leak disappears, inspect the split-tunnel rules, DNS mode, and applications excluded from the tunnel. In Clash Verge or sing-box, review the DNS server definitions, fake-IP or redirection mode, rule providers, and whether DNS requests are sent through the intended outbound group. In Shadowrocket, inspect the DNS and routing options rather than relying only on the imported subscription defaults.
For ordinary users, a simple and clearly documented rule set is easier to audit than a complex configuration assembled from several sources. If you use a subscription link, import it only into a client you trust, keep the link private, and check whether an update changes DNS or routing settings. A subscription can deliver configuration, but it does not remove the need to understand the client's active mode.
Handle IPv6 and browser rules
If the IPv6 check exposes a local address, first determine whether the VPN client supports IPv6 protection. If it does, enable the documented option and test again. If it does not, temporarily disabling IPv6 can help confirm the cause, but consider the effect on work systems, local services, and websites before making that permanent. Do not disable security features blindly on a managed device.
For WebRTC, review the browser's site permissions, privacy controls, and approved extensions. A setting that blocks all WebRTC can interfere with browser calls, while a setting that allows every candidate can reveal more network information than you want. If remote work depends on browser-based meetings, test the result with the actual conferencing service and follow your employer's policy.
Reconnect and retest after each change
Disconnect the VPN, close the browser, reconnect, and repeat the same checks. Also test after switching from home Wi-Fi to a mobile hotspot or public Wi-Fi, because interface priority and captive portals can change DNS behavior. If the issue returns only on one network, the local router, DHCP settings, IPv6 service, or captive portal may be involved.
- Record the baseline IP, DNS, IPv6, and WebRTC results.
- Close competing VPN and proxy applications.
- Use full-tunnel mode and enable the client's DNS protection.
- Reconnect and repeat all checks in the same browser.
- Reintroduce split tunneling or browser settings one change at a time.
- Test again after changing network environments.
Privacy settings for common scenarios
During banking sessions, prioritize a trusted device, the official bank address or application, and a stable connection. A VPN can reduce exposure on public Wi-Fi, but frequent exit-region changes may trigger a bank's fraud controls or additional verification. If the bank blocks a selected route, do not keep changing settings while entering sensitive information. Disconnect, use the bank's approved access method, and verify the account through a known channel.
For remote work, ask whether the organization requires its own VPN, DNS suffixes, internal resolver, or endpoint agent. A personal VPN may interfere with internal name resolution, certificate checks, device management, or collaboration tools. If a company client must remain active, avoid running a second tunnel unless the administrator explicitly supports that arrangement. Split tunneling can be useful, but only when the policy is understood and approved.
On public Wi-Fi, confirm that the captive portal has completed before starting the VPN. Some networks require an initial connection to a login page and may behave unpredictably when all traffic is forced into a tunnel immediately. Once access is authorized, connect the VPN, verify DNS and IP behavior, and avoid using unknown certificate prompts or downloading configuration files from the Wi-Fi landing page.
On mobile devices, battery optimization and background restrictions can stop a client from maintaining the tunnel after the screen turns off. On desktop systems, sleep and wake events can leave stale routes or resolver entries. Enable the platform's official always-on or kill-switch option only after understanding how it affects local access, emergency connectivity, and work applications. A setting that blocks traffic during reconnection can improve privacy, but it can also appear as a network failure.
- ✅ Use the official client or a compatible third-party client with readable DNS and routing controls.
- ✅ Recheck privacy behavior after sleep, wake, network changes, and client updates.
- ✅ Keep banking, workplace, and personal traffic policies separate when their requirements differ.
- ✅ Preserve a known-good configuration before changing advanced DNS or rule settings.
- ❌ Do not paste a private subscription link into a leak-test or configuration-conversion website.
- ❌ Do not disable endpoint protection or workplace controls merely to force a connection.
When a DNS leak keeps returning
If the leak returns after every reconnect, check whether the VPN client has permission to create its virtual interface and whether the operating system is restoring an older DNS priority. On Windows, inspect the active adapters and verify that the VPN interface is present after connection. On macOS, review the active network service and any profiles installed by security or workplace software. On Android and iOS, confirm that the VPN permission remains enabled and that another always-on VPN is not taking control.
Next, update the client from its official source and compare the behavior with a clean configuration. An imported profile may contain an outdated DNS address, a rule that deliberately sends DNS direct, or a protocol feature that the current client does not fully support. If you use Shadowsocks, VMess, Trojan, Hysteria2, WireGuard, or another protocol, remember that the protocol transports traffic; DNS handling is still determined by the client, routing mode, and system integration.
If the problem appears only on one router, inspect DHCP-provided DNS, router-level filtering, IPv6 advertisements, and captive-portal behavior. Avoid changing router settings on a workplace or shared network without authorization. If the problem occurs across several networks and clients, collect logs without including passwords or subscription credentials, note the operating system and client version, and contact the provider or administrator. A useful support report includes the exact test type, the resolver organization shown, whether IPv6 was enabled, and whether full-tunnel mode changed the result.
DNS leak FAQ
Is DNS over HTTPS enough to prevent a DNS leak?
Not by itself. DNS over HTTPS encrypts the connection between your device and the selected resolver, which can prevent a local network from reading the DNS request directly. However, the request may still bypass the VPN tunnel, and the resolver can still process it. Treat Secure DNS as one part of a routing policy, not as proof that the VPN covers every request.
Does a changed IP address prove that there is no leak?
No. An IP check examines the address visible to the test website, while a DNS test examines the resolver handling domain lookups. IPv6 and WebRTC can also produce separate results. Run all relevant checks from the same environment and compare the organizations and address families, not just whether one displayed address changed.
Should I permanently disable IPv6?
Not automatically. Disabling IPv6 can be a temporary diagnostic measure when a VPN handles only IPv4, but it may affect local services, workplace networks, and websites. Prefer a VPN client and configuration that correctly handles IPv6. If you must disable it, understand the device and network consequences first.
Why does the leak appear only on one Wi-Fi network?
Different networks can advertise different DNS servers, IPv6 routes, DHCP priorities, captive portals, and security policies. A VPN client may behave correctly on one network but lose control of a resolver or interface on another. Compare the baseline and connected results on each network, then inspect the local router or administrator policy rather than changing several VPN settings at once.
Final takeaway: A connected VPN is only the starting point for a privacy check. Verify the DNS path, public IP, IPv6 route, and browser WebRTC behavior; use a clear full-tunnel baseline; then add split tunneling and advanced rules carefully. This method makes it easier to protect sensitive sessions on public Wi-Fi while avoiding false confidence from a single test result.