VPN Leak Test Guide: Check DNS, WebRTC, And IP Privacy

What a VPN leak test can and cannot prove

An IP check normally reports the public address visible to a website. Before connecting, record the result only as a baseline. After connecting, reload the same type of test and compare the visible address, approximate region, and network provider information. A different exit address generally indicates that ordinary browser traffic is leaving through the VPN route, but it does not by itself prove that every application uses that route.

A DNS leak test examines which DNS resolvers receive domain-name queries from your device. When you type a website name, an application must usually resolve that name to an address before making a connection. If the query goes to the resolver supplied by the local Wi-Fi network or internet provider while the rest of the traffic uses the VPN, the website request may still work, but the DNS path is not being handled as expected. DNS results can also vary because some services use several resolvers or return a provider name rather than a precise physical location.

A WebRTC check focuses on browser real-time communication features. WebRTC supports functions such as voice, video, and peer-to-peer connection negotiation. Depending on the browser, operating system, permissions, and network design, a WebRTC session may reveal local interface information or an address that is different from the normal browser exit address. A result showing a private local address is not automatically the same as exposing your public internet address, so interpret the result carefully.

Tests are snapshots, not permanent guarantees. A browser update, client update, network change, split-tunneling rule, or newly granted permission can alter the result. Repeat the checks after changing networks, importing a new subscription, switching clients, or enabling an application-specific bypass.

Prepare a clean and repeatable test

Start with a simple setup. Close private browser windows that may have old connections, pause downloads and large synchronisation tasks, and note whether another proxy, security product, or corporate network profile is active. Do not run two VPN or proxy clients at the same time. They may install competing routes, change DNS settings in different ways, or make the final result difficult to interpret.

Use the same browser for the before-and-after comparison, but do not assume that one browser represents every application on the device. A desktop VPN client may protect system traffic while a browser extension controls only browser requests. Conversely, a browser setting may affect WebRTC without changing the route used by a separate application. Write down the client name, selected protocol, selected route, browser, and network type before you start.

On Windows and macOS, first test from a normal home or office connection, then repeat after connecting to the VPN. On Android and iOS, check whether the operating system displays an active VPN indicator and whether the client has permission to create a VPN profile. A subscription import alone does not establish protection: the client must successfully connect, and the system must accept its VPN configuration.

If you use a subscription link, update it through the client’s normal subscription function rather than editing route entries manually. A subscription can contain different protocol types, including Shadowsocks, VMess, Trojan, Hysteria2, or WireGuard-compatible configurations, but the client must support the format and core that you import. If you are uncertain about importing a subscription, see the setup guide before comparing test results.

Check public IP visibility first

Begin with the VPN disconnected. Open a reputable IP-checking page and record the address and network details shown. This is your local baseline. You do not need to publish the address, screenshot the full result, or paste it into a public support channel. Treat addresses and account-related screenshots as private information.

Connect the VPN client, wait for the connection status to become active, and refresh the test. The visible address should normally change to the VPN exit address or to an address associated with the selected route. The displayed country or city may not exactly match the route name because databases are updated at different times and may identify the registered location of a network rather than the physical location of the equipment.

Perform a second check in a private window or after clearing the page cache if the first page appears unchanged. A cached page cannot reliably tell you what the current connection is doing. If the old address remains visible in a fresh check, inspect the client mode, route selection, and any bypass list. A global mode usually sends more traffic through the VPN than a rules-based mode, while a rules-based mode may intentionally leave local or selected domains outside the tunnel.

Also test an application that matters to your normal work. A browser result may look correct while a desktop application uses its own network stack, proxy setting, or direct connection. If the client supports a kill switch, understand its scope: some kill switches block selected traffic when the VPN disconnects, while others may cover more system traffic. Read the client description instead of assuming that every kill switch behaves identically.

• ✅ Record the disconnected baseline before changing the network.
• ✅ Recheck in a fresh page after the client reports an active connection.
• ✅ Compare the route mode and bypass list when the original address remains visible.
• ❌ Do not publish your address, subscription link, or account screenshot while asking for help.

Test DNS requests and resolver behavior

DNS testing should be performed both before and after the VPN connection. A test page may list one resolver, several resolvers, or only broad provider information. Focus on the pattern: does the result identify the local network or internet provider when the VPN is active, or does it show resolvers consistent with the VPN route? The exact provider name is not always decisive because VPN services may use shared infrastructure, third-party DNS resolvers, or different resolver addresses for different routes.

Run the test more than once after allowing the page to complete its full result. Some browsers cache DNS responses, and some operating systems keep a local DNS cache. A single old result may therefore reflect a request made before the VPN connected. Closing and reopening the browser, flushing the operating-system DNS cache where appropriate, and then repeating the test can help separate stale information from a current leak.

On Windows, inspect the client’s DNS or network protection settings and check whether the client offers DNS leak protection. On macOS, review the active network service and any custom resolver profile, but avoid changing several system settings at once. On Android and iOS, check whether a private DNS feature, content filter, enterprise profile, or security application is intercepting DNS. These features may be legitimate, but they can make the observed resolver different from the one expected by the VPN client.

Encrypted DNS and a VPN solve related but different problems. DNS over HTTPS or DNS over TLS can protect a DNS request between the device and a resolver, but it does not automatically route all other traffic through the VPN. A browser’s secure DNS option can also send browser DNS queries through its own resolver while other applications use the operating system. Decide which behavior you want, then test the actual configuration rather than relying on a label such as “secure DNS.”

Check WebRTC exposure in your browser

WebRTC behavior is browser-specific, so test every browser that you use for sensitive or account-related work. Connect the VPN first, open a WebRTC leak-checking page, and inspect the addresses it reports. Compare public results with the normal IP-check result and distinguish private local interface addresses from public addresses. A private address such as one used inside a home network may reveal local network structure but is not the same as revealing your public exit address.

WebRTC can also be affected by browser permissions and by the application that starts the call. A meeting site may ask for microphone, camera, or network permissions, and denying an unrelated permission does not necessarily disable every WebRTC function. If privacy is important, review the browser’s site permissions, extension list, and WebRTC-related controls. Use extensions only when you understand what they modify; an extension can add another party that sees browsing activity or can become incompatible after a browser update.

On Chromium-based browsers, Firefox, Safari, and mobile browsers, the available controls are not identical. Some settings reduce exposure, some force WebRTC through a proxy, and some can interfere with video calls or browser-based collaboration. Do not change a hidden advanced preference without recording its original value. After changing a setting, retest both a WebRTC page and the services you actually use.

A browser-level WebRTC result does not automatically describe native mobile applications. A video-call application may use its own networking implementation, and an iOS or Android app may follow operating-system VPN rules differently from a browser tab. If your concern is a particular application, test that application’s behavior and review whether the VPN client supports application-level routing or split tunneling for it.

Apply practical fixes without breaking normal traffic

When a test suggests a problem, change one variable at a time. First confirm that the VPN client is fully connected and that the selected route is not marked as bypassed. Next update the subscription through the client, reconnect, and repeat the IP, DNS, and WebRTC checks. If several route types are available, compare them carefully, because a protocol may have different support in the operating system or third-party client you are using.

Enable the client’s DNS protection option if it provides one, and check whether the operating system has another DNS manager, private DNS profile, or security application taking precedence. If you set a custom resolver manually, document it before testing. Removing an old custom entry or disabling a conflicting network filter may solve the issue, but a workplace or school device may require that profile, so ask the administrator before making changes.

Enable a kill switch when you need the device to stop selected traffic during an unexpected disconnection. Then test the failure behavior deliberately: disconnect the VPN in a controlled situation, see which applications stop, and reconnect before resuming ordinary work. A kill switch that blocks all connectivity may be inconvenient on a local network, while a narrow rule may not cover every application. The useful setting is the one whose scope you understand.

For browsers, review WebRTC controls and permissions, remove extensions you no longer need, and retest after every browser update. For mobile devices, confirm the VPN profile is still installed, disable battery restrictions that prevent the client from maintaining a connection when appropriate, and verify that the system has not switched to another VPN profile. On desktop systems, check that no second proxy tool starts automatically with the operating system.

Repeat the process on public Wi-Fi and mobile networks

A configuration that works at home may behave differently on hotel, café, airport, or campus Wi-Fi. Captive portals often require a short unauthenticated connection before normal internet access is allowed. If the VPN starts before the portal is completed, the sign-in page may not load. Connect to the Wi-Fi, complete the portal using the minimum information required, then activate the VPN and repeat the three checks.

Public Wi-Fi can also change DNS settings, block certain protocols, or interrupt idle connections. If one protocol does not connect, try a supported alternative in the client rather than repeatedly toggling unrelated system settings. A route that works on one network may not be suitable on another, so note the network type when comparing results.

On cellular networks, test after switching from Wi-Fi to mobile data and again after returning to Wi-Fi. Android and iOS may display an active VPN icon while an application still has its own behavior, especially when split tunneling, private DNS, or an application-specific profile is enabled. Check the client’s connection log for useful categories such as authentication, subscription update, DNS, or route failure, but remove account identifiers before sharing logs.

Use the VPN’s kill switch or always-on option only after confirming how it affects emergency access, local printers, casting devices, and captive portals. Security controls should be predictable rather than merely enabled. If the device is managed by an employer or school, follow its network policy and do not install an unapproved profile.

• ✅ Complete a public Wi-Fi captive portal before activating the VPN when necessary.
• ✅ Repeat IP, DNS, and WebRTC checks after changing between Wi-Fi and mobile data.
• ✅ Review split tunneling and private DNS on mobile devices.
• ❌ Do not share raw connection logs containing usernames, subscription links, or account identifiers.

VPN leak test FAQ

Does a different IP address mean there is no leak?

No. It confirms only that the test page saw a different public address for that request. You should still check DNS resolver behavior and WebRTC results, and you should test important applications separately if they may use their own network path.

Why does a DNS test show several providers?

VPN infrastructure can use multiple resolvers, and a test page may combine results from several requests. Shared infrastructure and database differences can also affect the displayed provider. Compare the result with the client’s intended DNS policy and repeat it after clearing stale browser or system data.

Is a private WebRTC address automatically dangerous?

Not necessarily. A private address can identify a local interface or network range without revealing your public internet address. The important question is whether an unexpected public address is exposed and whether that behavior affects the browser or application you actually use.

What should I do if results are inconsistent?

Return to a simple setup: one client, one browser, one route, and no second proxy. Reconnect, update the subscription, check permissions, and test each category separately. If the issue remains, record the platform, client, protocol, route mode, network type, and test result without sharing credentials.