A VPN client can display “Connected” while DNS requests, IPv6 traffic, or browser discovery features still use a path you did not expect. That does not automatically prove that a service is unsafe, nor does a clean result prove absolute privacy. It means that different traffic types need to be tested separately. A useful DNS leak check therefore compares the resolver, address family, and browser behavior before and after the VPN connection, using the same device and network whenever possible.
This guide explains how DNS leaks happen, how to test DNS, IPv6, and WebRTC, and how to apply targeted fixes on Windows, macOS, Android, iOS, and Linux. It also covers official VPN applications and compatible clients such as Clash Verge, sing-box, and Shadowrocket. The goal is not to promise perfect anonymity. The goal is to identify mismatches, understand their cause, and verify whether a configuration change solved the specific problem.
What a DNS leak really means
DNS, or the Domain Name System, translates a domain such as example.com into an IP address. When you open a website, the browser usually needs a DNS answer before it can establish a connection. If the VPN tunnel carries the web connection but the DNS query still goes to the resolver supplied by your local broadband or mobile network, the setup has a DNS leak in the practical sense used by VPN testing.
The problem is not limited to the resolver address itself. A client may connect successfully but fail to apply its DNS settings to every application. A browser can retain cached answers, a device can prefer IPv6 over IPv4, or a manually configured resolver can remain active outside the tunnel. Split tunneling can also be intentional: some applications may be sent directly while others use the VPN. In that case, a result that looks like a leak may actually reflect a rule you configured.
There are several common causes:
- ✅ The VPN client connects, but the operating system keeps using the original network DNS server.
- ✅ IPv6 remains enabled while the VPN only handles IPv4 traffic, allowing some requests or connections to bypass the tunnel.
- ✅ A browser or security application uses its own encrypted DNS service instead of the VPN-provided resolver.
- ✅ A proxy-compatible client handles application traffic but does not control every system resolver request.
- ❌ A single “Connected” label is not enough evidence that DNS, IPv6, and browser discovery all follow the same route.
DNS over HTTPS and DNS over TLS can encrypt a DNS request between the device and a resolver, but encryption alone does not answer the routing question. If the browser sends an encrypted request directly to its own resolver, the VPN provider may not see it, and the local network may see a connection to that resolver. Whether that is desirable depends on your privacy model and configuration. The important point is consistency: know which component is resolving names and which interface carries the request.
Prepare a reliable leak test
Testing is more useful when you establish a baseline first. Disconnect the VPN and record the network conditions, then reconnect it and repeat the same checks. Use the same Wi-Fi or mobile connection, the same browser profile, and the same device. Changing several variables at once makes it difficult to tell whether a result came from the VPN, the network, or a browser setting.
Before connecting, note the public IPv4 address shown by a reputable IP-checking page and inspect the DNS servers reported by the operating system. You do not need to publish these values. They are simply a reference for comparison. Also note whether the device has an IPv6 address. A normal-looking IPv4 result does not rule out IPv6 traffic, because both address families can be active at the same time.
On desktop systems, built-in commands provide useful clues:
- On Windows, run
ipconfig /allto inspect adapters and DNS servers, then usenslookup example.comto see which resolver answers the query. - On macOS, run
scutil --dnsto inspect resolver configuration. If available,dig example.comcan show the responding server and answer details. - On Linux,
resolvectl statusshows per-interface resolver settings on systems using systemd-resolved. You can also usedig example.comfor a direct query test.
These commands do not replace a full leak-testing page, because an operating system may display several resolvers and applications may use different paths. They are valuable because they reveal local configuration before you interpret a browser result. On Android and iOS, system-level inspection is more limited, so the VPN application’s DNS, kill-switch, and always-on settings deserve closer attention.
Next, connect the VPN without changing other settings. Wait for the client to finish connecting, then repeat the IP, DNS, and IPv6 checks. If you use Clash Verge, sing-box, or Shadowrocket, confirm whether the profile is operating as a system VPN, a system proxy, or an application-specific proxy. A system proxy may not capture every request made by the operating system or by applications that ignore proxy settings.
What to record during testing
| Test area | Baseline question | VPN-connected question | What a mismatch may indicate |
|---|---|---|---|
| Public IP | Which address and region does the network expose? | Does the expected VPN exit appear? | The VPN may not be carrying all traffic, or the application may be bypassing it. |
| DNS resolver | Which resolver answers normal domain queries? | Does the resolver match the intended VPN or privacy setup? | The operating system, browser, or another application may be resolving directly. |
| IPv6 | Does the network assign an IPv6 address? | Is IPv6 handled by the tunnel or disabled consistently? | IPv6 may be using the physical interface outside the VPN. |
| WebRTC | What local or public candidates does the browser expose? | Does the browser reveal an address unrelated to the intended route? | Browser media discovery may expose network information separately from ordinary web traffic. |
Test DNS and IPv6 step by step
Begin with a normal DNS query rather than a specialized test. Open a few unrelated domains, clear the browser cache if you need a clean comparison, and run the command appropriate for your operating system. Look at the resolver identity, not only the final IP address returned for a domain. A website’s hosting provider may be located in a different country from the DNS service, so the destination IP alone is not a reliable DNS diagnosis.
Then use a DNS leak test that performs multiple lookups. A single query can miss behavior caused by caching, resolver selection, or an application’s own DNS implementation. A broader test may list several resolvers. Compare the result with your baseline and with the VPN provider’s documented behavior. Some services intentionally use third-party public resolvers, while others send DNS through a tunnel-managed resolver. The result is only suspicious when it conflicts with the configuration you intended to use.
For IPv6, first determine whether the network and device have an IPv6 address. On Windows, ipconfig can show IPv6 addresses; on macOS and Linux, the network interface details provide the same information. A browser-based IP test can also reveal whether IPv6 connectivity exists. Disconnecting and reconnecting the VPN is important because some clients apply IPv6 handling only during tunnel establishment.
If IPv6 appears when the VPN is connected, check the client documentation for IPv6 support, IPv6 blocking, or leak protection. Do not assume that disabling IPv6 in the operating system is always the best answer. If your network, applications, or work environment require IPv6, disabling it may create a different problem. The safer approach is to use a tunnel and client combination that explicitly handles IPv6, or to disable it consistently only when that matches your requirements.
Also inspect route behavior. On Windows, route print can help show whether a default route or an IPv6 route remains attached to the physical interface. On macOS, netstat -rn provides routing information, while Linux users can check ip route and ip -6 route. Routing tables are technical, but they can explain why an apparently correct DNS setting does not prevent traffic from leaving through another interface.
Check WebRTC in your browser
WebRTC is a browser technology used for real-time audio, video, and peer-to-peer communication. To establish a connection efficiently, it can gather network candidates through mechanisms such as ICE. Depending on browser behavior, operating system settings, and the active network interfaces, a WebRTC diagnostic page may display local addresses or public candidates that are not visible in a normal page-load test.
WebRTC is not the same as a DNS leak. It can reveal network information through browser media APIs even when ordinary DNS queries use the expected resolver. It is also not automatically a vulnerability: many real-time applications need candidate discovery to function. The practical question is whether the browser exposes more information than you want it to expose in your chosen environment.
To test it, close unnecessary VPN and proxy profiles, connect the VPN you normally use, and open a WebRTC leak-testing page in the browser. Review every candidate category reported by the page. Compare the result with the VPN-connected public IP and with the baseline. Repeat the test in a private browsing window only as a comparison; private browsing can change extensions and stored state, but it does not guarantee that WebRTC behaves differently.
Possible responses include using the browser’s built-in WebRTC privacy controls, applying a reputable extension, or disabling features that you do not need. Browser settings change over time, and extensions can affect video calls, screen sharing, and collaboration tools. Test the websites you rely on after making a change. A configuration that hides candidates may also prevent a meeting application from selecting an efficient media path.
Browser-level controls do not fix DNS or IPv6 leaks elsewhere on the device. Likewise, a clean WebRTC result does not confirm that a command-line tool, game, mail client, or background service follows the browser’s route. Treat each result as evidence about one layer, not a certificate for the entire device.
Fix the leak with targeted settings
Start with the least disruptive correction. If the official VPN client has a DNS leak protection, kill switch, or “use VPN DNS” option, enable it and reconnect. Some clients apply these options only after the tunnel restarts. Check whether split tunneling is enabled, and review which applications or domains are excluded. A deliberate bypass is not a leak, but it should be documented so that later tests are interpreted correctly.
If you use a subscription-based client, update the subscription and confirm that the imported profile is current. A subscription link can contain server, protocol, routing, and DNS-related settings, but importing it does not guarantee that the host application will enable system-wide capture. Clash Verge, sing-box, and Shadowrocket may expose different modes, such as global routing, rule-based routing, or proxy-only operation. Read the client’s mode description and verify the operating system VPN permission where applicable.
Protocol choice also matters, although it cannot repair a misconfigured resolver by itself. Shadowsocks is commonly used as a proxy protocol, while VMess, Trojan, Hysteria2, and WireGuard have different transport and client integration characteristics. A protocol may work well in one official or compatible client and behave differently in another because DNS handling, TUN support, IPv6 policy, and route rules are separate features. Choose a protocol supported by the client, then verify the actual traffic path rather than assuming the name guarantees a result.
- ✅ Enable the client’s DNS protection or tunnel-managed DNS option when available.
- ✅ Review split-tunnel and rule-based routing entries for browsers, DNS tools, and security software.
- ✅ Use TUN or system-VPN mode when you need broader device traffic capture and the client supports it.
- ✅ Reconnect after changing DNS, IPv6, routing, or kill-switch settings.
- ✅ Retest on both Wi-Fi and mobile data if the privacy requirement covers both networks.
- ❌ Do not run two VPN clients at the same time unless you understand their route precedence.
- ❌ Do not add random public DNS servers as a fix without checking who will receive your queries.
- ❌ Do not treat a browser extension as a replacement for system-level VPN routing.
On Windows, check the adapter priority, DNS assignment, and kill-switch behavior after reconnecting. On macOS, inspect the active network service and any custom DNS entries. Android users should review Always-on VPN and “Block connections without VPN” where supported, while remembering that application exclusions can override the general policy. iOS relies heavily on the VPN profile and application capabilities; if a compatible client cannot provide the required system behavior, an official client with a full system VPN profile may be more suitable. Linux users should inspect NetworkManager, systemd-resolved, firewall rules, and the client’s TUN configuration together.
Verify the fix with a second round of tests
After changing one group of settings, disconnect and reconnect the VPN, then repeat the same DNS, IPv6, WebRTC, and public-IP checks. Avoid changing several unrelated options before testing. If the result improves, keep a short record of the working mode, profile, browser, and network type. This makes future troubleshooting faster when a client update or network change modifies the behavior.
Test more than one domain and, where appropriate, more than one application. A browser may use encrypted DNS while a command-line tool uses the operating system resolver. A video application may use UDP and WebRTC while a normal website uses TCP or QUIC. If only one application exposes an unexpected path, investigate that application’s proxy and DNS preferences before changing the entire device.
Also test the failure case. Temporarily disconnect the VPN or change to a deliberately unavailable route, then observe whether applications stop, reconnect directly, or continue through a permitted bypass. This helps confirm whether a kill switch is doing what you expect. Do this only when you can safely interrupt active downloads, calls, or work sessions. A kill switch may block traffic during reconnection, which is usually a feature rather than a fault, but it can affect real-time tasks.
No diagnostic page can observe every background process, and public test results can change with browser updates, resolver policies, or network conditions. Use the results as configuration evidence, not as an absolute security certification. Privacy also depends on the service’s policies, account practices, endpoint security, browser fingerprinting, malware protection, and the websites you visit.
FAQ: DNS leak testing and VPN privacy
Why does my VPN say connected when a DNS test still shows my local provider?
The VPN may be carrying ordinary web traffic while the operating system or browser sends DNS requests through a separate resolver. Split tunneling, custom browser DNS, IPv6, and proxy-only modes are common explanations. Check the client’s DNS protection setting, review exclusions, reconnect the tunnel, and compare the resolver shown by both a browser test and a system command.
Will changing to a public DNS server fix a VPN leak?
Not necessarily. A public resolver can change who receives your DNS queries, but it does not automatically place those queries inside the VPN tunnel. It may also conflict with the browser’s encrypted DNS setting or with the client’s own resolver policy. First decide which resolver should handle requests, then confirm its route after connecting the VPN.
Should I disable IPv6 whenever I use a VPN?
Only if disabling it is appropriate for your network and applications. If the VPN does not support IPv6 and the device continues to use IPv6 outside the tunnel, disabling IPv6 can prevent that specific path. However, a VPN with proper IPv6 handling may be a better solution, especially where IPv6 is needed. Test after making the change instead of assuming it worked.
Does a clean WebRTC result mean there is no DNS leak?
No. WebRTC and DNS are separate mechanisms. A browser can hide or limit WebRTC candidates while the operating system still uses an unintended DNS resolver. Run separate tests for DNS, IPv6, WebRTC, and the public IP, then interpret each result according to the routing mode and privacy settings you intentionally selected.
A careful leak check is a repeatable maintenance task rather than a one-time badge. Recheck after changing VPN clients, importing a new subscription, enabling split tunneling, updating a browser, switching between Wi-Fi and mobile data, or changing IPv6 settings. When the test results match your documented configuration, you have a clearer and more defensible privacy setup without relying on absolute claims.