VPN DNS Leak Check: Privacy Risks And Fixes Explained

A VPN can show “Connected” while your DNS requests, WebRTC information, or real IP address still travel outside the protected route. This is why a privacy check should not stop at looking for a changed IP address. A complete check compares the network before and after connection, tests ordinary DNS resolution, examines IPv6 behavior, reviews WebRTC exposure, and verifies that the applications you actually use follow the intended route.

DNS leaks matter because DNS is the lookup stage that turns a domain name into an IP address. Even when the page content travels through a VPN, an operating system, browser, router, or application may send the lookup request to the original network provider. That can reveal which domains your device is trying to reach. The practical goal is not to trust a single green status message, but to confirm each layer independently and fix only the layer that is actually leaking.

What a DNS leak reveals

When you enter a website address, your device normally asks a DNS resolver where that domain is hosted. The resolver may be operated by your home router, internet provider, mobile carrier, a public DNS service, or the VPN application itself. DNS does not usually contain the full page content, but it can create a useful record of the domains requested by a device. For privacy-sensitive browsing, that metadata can be important even when the main connection is encrypted.

A properly configured VPN commonly directs DNS traffic through the same protected route as other selected traffic. The remote resolver may then see the request instead of the local network. However, the exact behavior depends on the client, operating system, protocol, routing mode, IPv6 support, and application settings. A system proxy may cover browsers while leaving another application untouched. A rule-based client may route some domains directly by design. A TUN interface may cover more traffic, but it can also expose configuration conflicts if another network tool is active.

DNS, IP, and WebRTC are different tests

An IP address check asks which public address a website sees for the connection. If the original address is visible after the VPN connects, the tunnel or route is not covering the request correctly. A DNS test asks which resolvers receive domain lookups. Those resolver addresses may be different from the visible exit IP, so a changed IP alone does not prove that DNS is protected.

WebRTC is a browser communication feature used by web applications for real-time audio, video, and peer-to-peer functions. Depending on browser behavior and permissions, WebRTC can expose local interface information or a public candidate address. Modern browsers have reduced some exposure, but the result still depends on browser version, operating system, VPN mode, and WebRTC policy. Treat WebRTC as a separate browser test rather than assuming that a DNS result covers it.

There is also an important privacy limit: a DNS result showing a resolver associated with the VPN route does not mean that the provider cannot see DNS requests. It means that the local network is less likely to receive them. Review the provider’s privacy policy, client behavior, and available DNS settings before treating a result as a complete privacy guarantee.

Prepare a clean baseline before testing

Start with a simple environment. Close extra VPN clients, proxy utilities, browser extensions that modify network traffic, and temporary troubleshooting tools. If two applications attempt to control the system proxy, DNS settings, or virtual network adapter at the same time, the test may reflect a conflict instead of the normal configuration.

Record the initial state while the VPN is disconnected. Use the same browser and the same network for the second test. If possible, note the public IPv4 address, whether an IPv6 address is shown, the DNS resolver names or addresses, and any WebRTC candidates displayed by the testing page. You do not need to publish these results. They are only a comparison reference, and public screenshots may expose information you would rather keep private.

• ✅ Disconnect every other VPN or proxy before starting.
• ✅ Test both the browser you normally use and the application that concerns you.
• ✅ Keep the same Wi-Fi or mobile network during the off/on comparison.
• ✅ Record whether IPv4 and IPv6 are both present.
• ❌ Do not assume that a browser result represents every application on the device.
• ❌ Do not share subscription links, client logs, or personal IP information in public troubleshooting posts.

For a command-line baseline, Windows, macOS, and Linux users can inspect the active DNS configuration with the tools provided by their operating system. Windows commonly uses ipconfig /all, macOS can show resolver details with scutil --dns, and Linux systems may use resolvectl status or a distribution-specific network manager command. These commands show local configuration, not necessarily every request made by every application, so use them as supporting evidence rather than the only test.

Run a complete DNS leak check

First disconnect the VPN and open a reputable DNS leak testing page, an IP checker, and a WebRTC testing page. Use the normal browser profile, but temporarily disable extensions that block scripts or alter DNS behavior if they prevent the test from loading. Record the broad result rather than copying sensitive details into a public document.

Next connect the VPN from the official client or a compatible client such as Clash Verge, sing-box, or Shadowrocket. Wait until the application reports an active connection, then refresh each test page in a new tab. If the client uses a subscription, confirm that the selected configuration is the intended node and that the client has actually activated the system proxy or TUN mode. Importing a subscription successfully is not the same as routing traffic through it.

1. Check the public IP. The address should change from the disconnected baseline when full traffic is expected to use the VPN. If it does not change, inspect the system proxy, TUN setting, routing mode, and application bypass rules.
2. Run a standard DNS test. Look at the resolver organizations and locations shown by the test. A result that still identifies the home router, internet provider, or mobile carrier suggests that DNS requests may be leaving through the original connection.
3. Run the extended DNS test. A short test may query only a small set of resolvers. An extended test sends more lookups and can expose inconsistent routing, especially when several resolver paths are available.
4. Review IPv6 separately. If the VPN handles IPv4 but the operating system keeps an unprotected IPv6 route, websites may see the original IPv6 address or send DNS traffic through that path.
5. Check WebRTC. Compare the candidates with the disconnected baseline. A local address is not automatically a serious leak, but an original public address deserves attention.
6. Repeat in a private window. This helps separate cached results, extensions, and stored permissions from the normal browser configuration. It is a confirmation step, not a replacement for the first test.

Interpret common results correctly

Fix DNS routing on each platform

The safest fix is usually to let one correctly configured VPN client control DNS for the traffic it handles. Avoid changing several layers at once because it becomes difficult to identify which setting solved the problem. Make one change, reconnect, clear caches, and repeat the same comparison.

Windows

In a Windows client, look for options such as remote DNS, secure DNS through the tunnel, DNS hijacking protection, or a TUN-based DNS mode. Names vary by application. If you use system proxy mode, remember that it mainly affects software that respects Windows proxy settings. An application using its own resolver, a browser’s separate secure DNS feature, or a direct socket connection may not follow that proxy.

If the client offers TUN mode, enable it only after confirming that the application has the required permissions and that no other virtual adapter is competing with it. TUN mode can provide broader coverage for applications that ignore the system proxy, but it does not automatically correct an incorrect DNS rule. Review whether DNS requests are redirected to the VPN interface and whether local network exceptions are intentional.

macOS and Linux

On macOS, inspect the active resolver after connecting and check whether the VPN client has created a tunnel-specific DNS service. Some applications may maintain their own DNS-over-HTTPS connection, while others follow the system resolver. If a browser’s secure DNS setting is enabled, test with that setting documented, not randomly changed, so you know which resolver path the browser is using.

On Linux, NetworkManager, systemd-resolved, desktop environments, and VPN clients may all participate in DNS selection. A sing-box or other TUN configuration should define how DNS queries are routed and which domains are resolved directly. Check the active interface, policy rules, and resolver status after the tunnel starts. If resolvectl status still shows only the physical interface for all lookups, investigate the client’s DNS integration rather than changing public DNS addresses repeatedly.

Android and iOS

On Android, the VPN permission screen and the client’s per-app routing list are especially important. A DNS test in the browser may pass while an excluded application continues to use the direct network by design. Review battery restrictions as well, because a client stopped in the background cannot protect traffic after the tunnel disappears. Android’s Private DNS setting can also interact with the client, so document whether it is automatic, provider-specific, or disabled before comparing results.

On iOS, check the VPN profile permission, on-demand behavior, and any per-app or managed-network rules. Browser WebRTC behavior is controlled partly by the operating system and browser implementation, so a WebRTC result may differ from a desktop browser. Shadowrocket and similar compatible clients can apply detailed routing rules, but a rule that intentionally sends a domain or application directly will appear as a bypass during testing. That is not necessarily a configuration failure; it must match your intended policy.

Fix WebRTC and IPv6 exposure

WebRTC is not the same as DNS, and blocking every real-time browser function may create unwanted side effects. Start by reviewing browser permissions and privacy controls. If you do not use browser-based voice or video features, stricter WebRTC controls may be acceptable. If you do use them, choose a setting that limits public address exposure without disabling required communication, then repeat the WebRTC test after restarting the browser.

Do not treat a private LAN address as equivalent to your public IP. Local candidates can reveal information about the device’s network interface, but the privacy impact differs from exposing an internet-routable address. The meaningful question is whether the original public route or an address associated with the physical connection is visible to the test page.

IPv6 deserves a deliberate decision. Some VPN clients support IPv6 routing; others handle only IPv4. If your network provides IPv6 and the client does not, the operating system may prefer the unprotected route for selected connections. You can choose a client and configuration that properly handles IPv6, or disable IPv6 when that is suitable for the device and network. Do not disable it blindly on managed networks or systems that require IPv6 for internal services. After any change, test both address families again.

• ✅ Prefer a client with explicit DNS and IPv6 handling options.
• ✅ Keep WebRTC policy consistent with the browser features you actually need.
• ✅ Review per-app and split-routing exclusions before labeling a result as a leak.
• ❌ Do not use several DNS-changing utilities at the same time.
• ❌ Do not assume that changing to a public DNS address alone protects the request from the local network.

Advanced routing and protocol notes

Protocol choice can affect stability and coverage, but it does not by itself prove that DNS is protected. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and WireGuard-based configurations still depend on the client’s DNS and routing implementation. A protocol may establish a reliable tunnel while the operating system continues to resolve domains through the physical interface. Always test the complete client configuration instead of judging by the protocol name.

Rule-based clients deserve special attention. A configuration may use direct rules for local services, streaming domains, software updates, or selected applications. In that case, a DNS request may intentionally be resolved directly even though other traffic uses the VPN. Read the rule order and DNS mode together: a domain classified as direct, a fake-IP strategy, or a fallback resolver can produce different test results.

Some clients provide fake-IP or enhanced DNS modes. These can improve rule matching by returning synthetic addresses to applications, while the client performs the real lookup internally. A conventional DNS testing page may not display the same resolver pattern as a basic system configuration. Use the client log, DNS mode description, and an independent IP comparison together. The objective is consistent policy enforcement, not making every diagnostic page display an identical format.

For payments, account access, and public Wi-Fi, use the strictest practical routing profile. Avoid changing nodes repeatedly during a login or payment session, and do not mix a browser proxy with a separate system VPN unless you understand the route. After reconnecting, refresh the test pages and confirm that the browser did not retain a direct connection through an extension or cached resolver result.

Frequently asked questions