A VPN can appear to work while part of your connection still reveals information outside the encrypted tunnel. The most common examples are DNS requests sent to the local network, WebRTC candidates exposing a direct interface in a browser, and applications that bypass the system proxy entirely. These are often called leaks, but the word needs a precise meaning: a DNS leak is not simply “seeing a DNS server” in a test result. The important question is whether the resolver, query path, and visible network identity match the privacy policy you intended to use.

This guide explains how to test DNS and WebRTC behavior, how to read the results, and how to apply fixes at the VPN client, operating-system, browser, and application levels. It also covers common situations involving official VPN clients, Clash Verge, sing-box, Shadowrocket, split tunneling, IPv6, and manually configured DNS. A test result is useful only when you know which traffic was actually routed through the VPN, so the process below begins with a clean baseline and ends with a second verification.

DNS Leak Test Guide: Check and Fix VPN Privacy Gaps

What a DNS Leak Really Means

DNS translates a hostname such as example.com into an IP address. When you open a website, the browser or operating system generally needs DNS resolution before it can create the connection. Without a VPN, those queries may go to your home router, mobile carrier, workplace resolver, public DNS provider, or an encrypted DNS service configured in the browser. A VPN can protect this part of the process by redirecting DNS through the tunnel to a resolver selected by the VPN service or by your own secure configuration.

A DNS leak occurs when a DNS query escapes the intended path. For example, the VPN tunnel may carry web traffic while the operating system continues sending queries to the local router. Another possibility is that a browser uses its own DNS-over-HTTPS provider while the rest of the device uses the VPN resolver. That may prevent the local network from seeing the query, but it can still conflict with a policy that requires all resolution to use the VPN provider or a specified regional resolver.

There are several results that are easy to misunderstand. A test may show a provider name that is different from the VPN brand because the VPN uses an upstream resolver. That is not automatically a leak. Likewise, seeing multiple resolver addresses is not proof of a problem if they all belong to the expected tunnel or provider. The meaningful checks are whether the resolver belongs to the local network, whether the apparent region is inconsistent with the selected route, whether queries continue after the tunnel is disabled, and whether different applications produce different results.

It is also useful to separate DNS privacy from DNS integrity. Privacy asks who can observe the domain query. Integrity asks whether the answer has been modified, redirected, or poisoned. A VPN can improve the path to a resolver, but it does not make every destination safe, remove malicious browser extensions, or guarantee that a domain itself is trustworthy. Use encrypted transport, updated software, and normal browser security practices together.

Prepare a Clean Baseline Before Testing

Testing is much easier when you record the state of the device before changing anything. First disconnect the VPN and note the network you are using: home Wi-Fi, a mobile hotspot, office Wi-Fi, or another managed connection. Open a DNS leak testing page from a reputable provider and run both the standard and extended test if available. Record the resolver organization, country or region, IP address family, and whether the result changes between the two modes.

Next check your public IPv4 and IPv6 addresses separately. If IPv6 is enabled locally but the VPN supports only IPv4, an application may reach the internet through the native IPv6 route. This is not always labeled as a DNS leak, but it is a related tunnel-coverage problem. Also note whether the browser has Secure DNS or DNS-over-HTTPS enabled. Browser-level encrypted DNS can make the browser’s result differ from the operating system’s result, so the setting must be included in your notes.

Do not test while another proxy application is running. Quit duplicate VPN clients, system-wide proxy tools, traffic filters, and network acceleration programs. On desktop systems, check whether a manual proxy is configured. On Android and iOS, look for an existing VPN profile, private DNS setting, content filter, or enterprise management profile. A stale profile can intercept traffic even after its visible application has been closed.

After recording the baseline, connect the VPN and wait for the client to report that the tunnel is ready. Close and reopen the test page rather than relying on an old result. Run the DNS test again, then visit several ordinary websites and repeat the test after changing to another permitted route. A single successful page load is not enough evidence, because cached DNS records may hide a resolver problem.

Run DNS and WebRTC Tests Step by Step

Start with the VPN client’s normal configuration. Do not immediately enable every privacy switch, custom DNS address, kill switch, and split-tunnel rule. The first run should tell you what the default profile does. In the test page, look for the resolver organization and location rather than focusing only on the number of entries. Compare the result with the VPN’s selected exit region and with the disconnected baseline.

1. Disconnect and test once. Save the baseline resolver and address-family results.
2. Connect the VPN. Confirm that the client shows an active tunnel and that no second VPN is enabled.
3. Flush or refresh local state. Reopen the browser, and clear the system DNS cache when appropriate.
4. Run a standard DNS test. Check the resolver organization, region, and returned addresses.
5. Run an extended DNS test. Additional queries can reveal a resolver path that a small test misses.
6. Run a WebRTC leak test. Compare local, private, public, IPv4, and IPv6 candidates where the browser exposes them.
7. Test another browser or application. A browser extension or Secure DNS setting may change the result.
8. Disconnect and repeat. This confirms that the reported resolver was not cached or unrelated to the VPN state.

WebRTC deserves separate attention. WebRTC is used for browser-based calls, screen sharing, peer connections, and real-time media. During connection negotiation, a browser may expose candidate addresses that help establish a peer-to-peer path. A local private address such as a home-network address is not the same as your public IP, but it can still reveal network information. A public candidate that belongs to the underlying connection is more concerning if your privacy goal is to hide that address from a website or peer.

Modern browsers have reduced some forms of exposure, and browser privacy settings vary. A WebRTC test may show a VPN address, a local interface, a host-masking candidate, or no useful candidate at all. The correct interpretation depends on what the test page labels and on the application’s needs. Blocking all WebRTC can break browser calling, collaboration, or video services, so prefer a browser setting that limits unwanted local-address exposure when you still need real-time features.

Fix Leaks in the VPN Client

The first repair should normally be made in the VPN client, because it is the component that knows whether the tunnel is active. Look for settings named DNS leak protection, use VPN DNS, secure DNS, prevent DNS outside the tunnel, or similar wording. Enable the option only after understanding whether it replaces the system resolver, redirects port 53 traffic, handles encrypted DNS, or applies a firewall rule. Names differ between official clients and third-party front ends.

Enable a kill switch if your privacy requirement is stronger than simple convenience. A kill switch should prevent selected traffic from leaving through the ordinary interface when the VPN disconnects, but implementations vary. Some block all network traffic; others block only traffic covered by the profile. Test it deliberately by connecting, starting a request, and then stopping the tunnel according to the client’s documented control. Do not assume that a desktop kill switch automatically protects a phone or another device.

Review split tunneling carefully. If the browser is excluded from the VPN, its DNS queries and WebRTC candidates may reflect the normal connection. If only selected applications use the tunnel, test both an included and an excluded application so you know the boundary. Per-app routing is useful for local services and performance, but it changes the answer to the question “Is this device protected?” The more accurate question becomes “Which application traffic is protected under this profile?”

Protocol choice can affect how DNS is handled. WireGuard commonly uses a virtual interface and system routing, while Shadowsocks, VMess, Trojan, and Hysteria2 may be presented through a local proxy or a tun mode depending on the client. A local proxy may cover applications that honor system proxy settings but miss applications that connect directly. Clash Verge and sing-box can provide stronger system-wide coverage when TUN mode is configured correctly, but TUN mode also requires correct permissions, route rules, DNS hijacking behavior, and exclusions.

Fix DNS at the Operating-System Level

Windows checks

On Windows, inspect the active adapter and VPN adapter in the network settings. A manual DNS server configured on the physical Wi-Fi or Ethernet adapter may remain visible to applications if the VPN does not override it. Check the VPN client’s DNS protection first, then review adapter priority, IPv6 status, and any network filter installed by security software. After making changes, flush the DNS cache and restart the browser. The command ipconfig /flushdns clears cached answers, but it does not repair routing by itself.

macOS checks

On macOS, review the active network service and VPN configuration under network settings. Custom DNS servers, encrypted DNS profiles, content filters, and applications that create their own network extension can change the result. If you use a proxy client in TUN mode, confirm that the system granted the required permission and that the active profile is the one being tested. Switching from Wi-Fi to another interface can also leave an old service active, so verify the current route rather than checking only the preferred service.

Android, iOS, and Linux checks

Android’s Private DNS setting can override or interact with a VPN’s DNS design. For a controlled test, note whether it is set to Off, Automatic, or a named provider, then compare results with the VPN connected. Android VPN profiles may also use per-app allow and disallow lists. iOS handles VPN and DNS profiles through system settings and may retain a configuration installed by another application. Test after moving between Wi-Fi and cellular data because the active interface can change the result.

On Linux, inspect the resolver manager, network namespace, active routes, and the interface created by the VPN or TUN client. NetworkManager, systemd-resolved, a local caching daemon, and containerized applications can each have different DNS behavior. A command such as resolvectl status can show per-link DNS information on systems using systemd-resolved. For a proxy-based setup, also test a direct command-line application and one program configured to use the proxy; they may not share the same path.

Browser and Application-Specific Fixes

Browser Secure DNS is a frequent source of confusing results. If it is enabled with a fixed provider, the browser may send DNS-over-HTTPS directly to that provider instead of using the VPN’s DNS path. This can be appropriate if your policy is simply to prevent the local network from reading DNS queries, but it may be inconsistent with region-sensitive routing or a VPN-level resolver policy. Test three states where available: automatic, disabled, and a named provider. Keep the option that matches your threat model and does not bypass required routing rules.

Browser extensions can also interfere. Privacy extensions, proxy extensions, antivirus web filters, and corporate security tools may intercept DNS or create their own connections. Disable them temporarily during diagnosis, then re-enable them one at a time. If only one browser shows a different result, the issue is probably inside that browser rather than in the operating system tunnel.

Applications such as command-line tools, game launchers, video clients, virtual machines, containers, and developer tools may ignore the system proxy. Some support HTTP or SOCKS proxies; others need TUN mode or an application-specific configuration. A browser test cannot certify these programs. Run a DNS lookup, open a target connection, and check the application’s own proxy or network log where available. If the application has an embedded DNS resolver, system-level DNS changes may not affect it.

For Clash Verge and sing-box, inspect rule order as well as DNS settings. A domain rule may send the connection through one outbound while a DNS rule resolves it through another path. Fake-IP and redirection modes can be useful, but they introduce additional moving parts: local listeners, exclusions, fallback servers, and compatibility rules. Change one setting at a time and repeat the same connected and disconnected comparison. For Shadowrocket, verify whether the profile uses rule mode or global mode and whether the current Wi-Fi or cellular interface has a separate exception.

How to Judge the Final Result

A successful repair should be reproducible. Reconnect the VPN, refresh the browser, run the DNS test again, check WebRTC, and test one application outside the browser. Then disconnect the VPN and confirm that the result returns to the baseline. If the connected result remains unchanged, the VPN may not control DNS or the browser may be using its own resolver. If the result changes only after restarting the browser, cached state or a browser-level service may be involved.

Keep an evidence table for each configuration. Record the VPN client or compatible client, protocol or mode, selected route, DNS setting, IPv4 status, IPv6 status, browser Secure DNS state, and the observed result. Avoid relying on a single test website because test implementations differ. A second reputable checker can help confirm the observation, but different labels do not always represent different network behavior.

• ✅ The connected test shows only resolvers consistent with the selected privacy policy
• ✅ The public address and IPv6 behavior match the tunnel design
• ✅ WebRTC does not expose an unwanted direct public candidate
• ✅ Important applications follow the same route as the browser, or their exceptions are intentional
• ✅ Disconnect behavior is understood and protected by the intended kill-switch policy

YJVPN supports Windows, macOS, iOS, Android, and Linux, and its network includes more than 90 countries and 200 routes. Those figures describe platform and network availability, not a guarantee that every route or application will produce the same DNS result. Whether you use an official client, a subscription-compatible client, or a third-party tool, perform the checks on the device and route you actually plan to use.

DNS and WebRTC Leak FAQ