A VPN can show “connected” while a browser request still takes a route you did not expect. DNS lookups, WebRTC connection checks, IPv6 traffic, browser settings, and split-tunnel rules can each affect what a website or test page sees. A result that looks unusual is not automatically proof of a leak, but it is a reason to check the test conditions and trace the request path.
This guide explains how to test DNS and WebRTC behavior, how to read common results, and which settings to review before changing anything. It focuses on diagnosis rather than promising that one setting or browser will guarantee privacy in every network environment.
What DNS and WebRTC Tests Actually Show
DNS, the Domain Name System, translates a website name into an address that a device can connect to. When you enter a domain in a browser, the browser or operating system usually asks a DNS resolver for the corresponding address. Depending on the operating system, browser, VPN client, and network configuration, that request might travel through the VPN, use a resolver selected by the VPN, or follow a separate route.
A DNS leak test observes which resolvers appear to answer its test queries. It does not necessarily reveal every DNS request made by every application, and a displayed resolver name may identify an organization or network rather than a precise physical location. The important question is whether the observed resolver and route match your intended configuration. Seeing a familiar public DNS brand, for example, does not by itself establish whether a VPN is or is not handling the request.
WebRTC is a set of browser technologies used by web applications for real-time communication, such as audio, video, and direct peer connections. To establish a connection, a browser may use network information gathered through ICE procedures and STUN servers. A WebRTC test checks what address information a test page can obtain through those mechanisms. Depending on browser protections and the network, the page may see a public address, a private local address, an obfuscated local name, or no useful address at all.
These checks answer different questions. A DNS result concerns name resolution; a WebRTC result concerns address information exposed during browser networking. A clean result in one category does not prove that the other is clean, nor does either test establish that all traffic from every application uses the VPN. Treat the output as a snapshot of the tested browser and connection at that moment.
DNS
Resolver path
WebRTC
Browser address exposure
IPv4 / IPv6
Address-family behavior
Repeat
Check after changes
The distinction matters when interpreting a report. A browser could use a resolver associated with the VPN while a WebRTC check reveals an address from another interface. Conversely, a WebRTC test might show no unexpected address while DNS requests still use a resolver selected by the local network. Review each category separately, then consider the routing rules that apply to the browser.
Run a Controlled Leak Check
A useful test starts with a known baseline and changes one variable at a time. Avoid running several privacy extensions, proxy tools, or VPN clients simultaneously during diagnosis. Each can change browser behavior or system routing, making it harder to determine which setting produced the result.
- Record the current connection state. Note whether the VPN client is disconnected or connected, which route or profile is selected, and whether the browser uses any proxy or privacy extensions. Do not publish screenshots containing account details, subscription information, or other personal data.
- Check the baseline with the VPN disconnected. Open a reputable DNS and WebRTC test page in the browser you normally use. Record the resolver organization and the address categories shown, without assuming that every displayed address is sensitive or unexpected. This baseline helps you compare what changes after the tunnel connects.
- Connect the VPN and wait for the client to finish connecting. Confirm the client reports an active connection, then reload the test page. If the client supports a system-wide mode, use it for the comparison rather than relying on a browser-only proxy setting. A connection indicator confirms the client’s connection state, not necessarily the route of every browser request.
- Run the DNS check and WebRTC check separately. Some test pages combine several checks or use labels that are not self-explanatory. Read the details for resolver names, address families, and the method used to obtain a WebRTC result. If the page offers a standard and an extended DNS test, use both only when you understand what each is asking.
- Repeat in a clean browser context. Try a private window or a separate browser profile with extensions disabled, while remembering that private browsing does not change the network route by itself. If the result differs, investigate browser extensions and site permissions before editing operating-system DNS settings.
- Change one setting, then test again. For example, check the VPN client’s DNS option first, reconnect, and repeat the same test. If you change DNS, browser privacy controls, IPv6, and routing rules together, you will not know which change mattered.
For more context about choosing a service and its available connection options, you can review VPNGF while keeping the leak test itself separate from any marketing claim. A test page reports what it observed; service descriptions and client settings explain the intended configuration. Neither replaces checking the actual route on the device you use.
After testing, close the diagnostic page if you do not need it, restore any temporary browser changes, and note the exact settings that produced a result. This is especially useful if the issue appears only on a particular Wi-Fi network, browser profile, or connection type. A comparison is most informative when the test page, browser, device, and route remain consistent.
Interpret Common Results Without Jumping to Conclusions
Test pages use different labels and methods, so compare the underlying details instead of relying only on a red warning badge. A result can indicate a configuration that deserves investigation without proving that an outside party can see all of your browsing activity. Check what the test actually observed, which browser made the request, and whether the observed resolver or address matches the network you intended to use.
| Observation | Possible explanation | What to check next |
|---|---|---|
| Resolver appears associated with your ISP | The operating system or browser may be using a resolver outside the intended VPN path, or the resolver’s organization label may not describe the route precisely. | Compare with the disconnected baseline, inspect the VPN client’s DNS settings, and test again after reconnecting. |
| Resolver appears associated with a VPN or public DNS provider | The request may be using a resolver selected by the tunnel, browser, or operating system. The displayed organization alone does not show every routing detail. | Confirm that the resolver is consistent with the configuration you intended and check whether the browser uses its own secure DNS option. |
| WebRTC shows an address you did not expect | The browser may be exposing an address through its connection-discovery process, or the test may be showing an address from another active interface. | Repeat with extensions disabled, inspect browser WebRTC controls, and check whether the address belongs to the connected route or a local interface. |
| A private address or local network name appears | Some browsers or test methods can reveal local-network information, while others mask it or show an obfuscated name. This is different from identifying a public exit address. | Check the browser’s current WebRTC privacy behavior and decide whether the site needs local-device discovery features. |
| IPv4 and IPv6 results do not match | The tunnel may handle one address family differently, or the local network may provide IPv6 connectivity that the VPN configuration does not route. | Review the client’s IPv6 support and leak-protection options; do not assume disabling IPv6 is necessary or safe for every network. |
| The result changes between refreshes | Resolvers, browser connection candidates, network interfaces, or test-page behavior may vary. A changed result is not automatically evidence of a persistent leak. | Keep the same browser and route, repeat the check, and compare the detailed resolver and address information rather than the summary label. |
One common source of confusion is an expected change in resolver identity. A VPN may route DNS requests to a resolver different from the one used by the local network, and a browser’s secure DNS setting may use a resolver chosen independently. The key is to determine which component selected that resolver and whether the request follows the privacy policy you intended.
Another is treating a private address as equivalent to a public address. Local addresses identify an interface within a private network and are not directly interchangeable with the public address a remote site uses to reach you. Even so, some people prefer to limit local network details available to web pages. Browser controls can help, but disabling WebRTC entirely may break calling, conferencing, or other real-time features.
Review Browser, DNS, and VPN Settings
If a repeated test shows behavior you did not intend, begin with the component most likely to control it. The browser may use its own secure DNS or proxy configuration; the operating system may have a manually selected resolver; and the VPN client may provide DNS handling or routing rules. These settings can overlap, so changing them without a plan can create new problems or make the original issue harder to reproduce.
Browser controls
Look for settings named Secure DNS, DNS over HTTPS, proxy, or WebRTC privacy. Browser-managed secure DNS can send queries to a resolver chosen in the browser rather than one provided by the operating system or VPN. Whether that request is protected by the tunnel depends on the browser’s routing and the VPN’s configuration. If a test result changes when secure DNS is enabled or disabled, investigate the selected resolver and route instead of assuming either setting is universally safer.
WebRTC controls vary by browser and version. Some browsers limit which local addresses are exposed or use obfuscated names; extensions may also modify connection behavior. Review the browser’s built-in privacy options first. If you disable or restrict WebRTC, verify that essential conferencing, voice, or peer-to-peer features still work. Do not install an unfamiliar extension just because its description claims to stop every leak.
DNS and routing controls
Check whether the VPN client offers a DNS mode, DNS leak protection, or an option to use a service-provided resolver. Keep in mind that labels differ between clients, and a DNS option may affect only requests routed through that client. In rule-based mode, a domain or application can be sent directly according to the active rules. A browser using a direct route may therefore behave differently from one routed through the VPN, even while the client itself remains connected.
Also inspect operating-system DNS settings, proxy settings, and any other network software that can alter routes. Avoid running two VPN or proxy clients at the same time during a test; competing virtual adapters, system proxies, or DNS policies can produce confusing results. If the issue occurs only on a work or managed device, check organizational policy before changing network configuration.
IPv6 deserves a separate check. Some VPN configurations carry IPv4 traffic but do not provide the same handling for IPv6, while some networks offer IPv6 independently. A mismatch can lead to unexpected address information or connection failures. Prefer a documented client option that addresses IPv6 routing. Turning IPv6 off at the operating-system level can affect local services and may not be the appropriate fix.
- ✅ Compare the same browser and test page before and after connecting.
- ✅ Check browser-managed secure DNS as well as the operating system and VPN DNS settings.
- ✅ Review rule-based routing to see whether the browser is sent direct or through the tunnel.
- ✅ Test IPv4 and IPv6 behavior separately when the page reports both.
- ❌ Do not assume that a connected status proves every application uses the VPN.
- ❌ Do not change several network settings at once or run competing proxy clients during diagnosis.
Confirm the Fix and Keep Results in Context
After changing a setting, reconnect the VPN if the client requires it, reload the test page, and repeat the same checks. Confirm that the result is consistent across more than one refresh and, if practical, compare it in a clean browser profile. If a change resolves the issue, test ordinary browsing and any applications that rely on real-time communication or local network discovery. Privacy controls should be compatible with the functions you need, not merely produce a reassuring test-page summary.
If results remain inconsistent, collect useful diagnostic context: device operating system, browser name and version, VPN client and mode, whether secure DNS is enabled, and the exact test category that changed. Share only the minimum information needed with a support team, and remove public addresses, account identifiers, and configuration secrets from screenshots or logs. A resolver organization or a single test result is not enough to diagnose every routing problem.
Testing has limits. A browser test evaluates requests made by that browser under the conditions of the test; it does not audit every application, background service, or network interface on the device. Network changes, software updates, browser profiles, and split-tunnel rules can all change the observed behavior. Repeat the checks after a meaningful configuration change, but avoid treating one page as a permanent privacy certification.
For everyday use, keep the VPN client and browser updated, use routing rules deliberately, and avoid layering unknown extensions or network tools without understanding their effect. When a warning appears, identify whether it concerns DNS, WebRTC, IPv6, or another route before taking action. That method is more reliable than toggling settings at random—and it helps preserve both privacy controls and the web features you depend on.