Check your VPN connection without trusting a single green badge

A VPN app saying “connected” is a useful status, but it does not answer every question about how your browser and other applications are using the connection. A small set of checks can reveal mismatches without turning the exercise into a competition between alarming leak-test websites.

Test with ordinary, non-sensitive browsing. Do not open private accounts or confidential material while deliberately disconnecting the VPN to see what happens.

You are checking the setup on your own device, not proving that the provider keeps no logs or that every application is anonymous. Those are different claims and require different evidence.

Write down the behavior you expect

Decide whether the VPN is meant to cover the whole device or only a browser. Check whether split tunneling excludes any apps or websites.

Record the VPN server location, the platform and any custom DNS setting. A browser using its own encrypted resolver may produce a different DNS result from the one you expect from the VPN app.

A corporate VPN may intentionally route only work traffic. Do not treat that policy as a defect or change it without authorization. Ask the administrator what the expected route should be.

The VPN limitations guide is a useful first step if you are not sure which problem the VPN is intended to solve.

Compare the public IP before and after connecting

Using a trustworthy connection-check page, note the public IP shown with the VPN disconnected. Close sensitive activity before making this baseline check.

Connect to the intended VPN server, wait for the app to confirm the connection and refresh the check. For a full-device VPN carrying that browser's traffic, the visible public address should normally change to an address associated with the VPN route.

Do not rely solely on the city label beside the address. Location databases can be imprecise or outdated. The relationship between the baseline and connected addresses matters more than whether a map pin looks perfect.

If nothing changes, check whether you are using a browser-only tool, an excluded application, another network interface or a page showing cached results. Diagnose the configuration before buying another subscription.

Check DNS with the provider's explanation beside you

A DNS test reports resolvers involved in its test queries. It does not directly display your entire browsing history or prove who can read every connection.

Mullvad's DNS troubleshooting guide explains that browser DNS settings, custom resolvers and other network software can affect its expected results. It also distinguishes a failed test from a reported leak.

Proton's DNS guide similarly describes conflicts with manual DNS configuration. Its infrastructure may involve third-party network names, so an unfamiliar company label alone is not enough to diagnose the route.

Use the instructions for the provider and platform you actually use. Do not copy system-wide commands from an unrelated guide merely to make a particular test display a green result.

Interpret a different resolver carefully

A result showing your ordinary internet provider's resolver while you expected the VPN's resolver deserves investigation. Check whether the browser, operating system or VPN is controlling DNS.

A deliberately configured encrypted resolver is a different case. It may be reached through the VPN tunnel while still appearing under another company's name in the test. The visible resolver identity alone does not prove whether the query traveled inside or outside the tunnel.

Review the encrypted DNS guide before changing that setting. The relevant question is whether the observed route matches your intended trust model, not whether every service name matches the VPN brand.

If the provider cannot explain an unexpected result, avoid sensitive use until you have a clear answer. Keep a private note of the test conditions rather than sharing a full screenshot containing personal addresses in a public forum.

Check the applications you actually use

A browser test examines the browser activity involved in that test. It does not automatically establish how a mail client, game, backup tool or virtual machine connects.

Review split-tunneling exclusions and any application-specific proxy setting. A second browser profile can also use a different extension or resolver configuration.

If a test includes browser connectivity checks, read what each reported address represents. Local-network addresses, VPN addresses and the ordinary public address are not interchangeable. Do not disable every browser feature just because a page uses the word leak beside a number.

For a work application, use the organization's approved verification method. Do not send work traffic to an outside diagnostic service without permission.

Test interruption behavior without risking real work

Read the provider's description of its kill switch or always-on setting. Some features block traffic only after an unexpected interruption, while others also block it when you intentionally disconnect. The exact behavior depends on platform and configuration.

With only a harmless test page open, try the documented check. Observe whether internet access pauses, whether the app reconnects and which public address appears afterward.

Repeat after a sleep-and-wake cycle or a switch between Wi-Fi and mobile data where relevant. These are ordinary transitions that can matter more than a test performed once on a stable connection.

Do not interpret one successful interruption test as a guarantee for every failure mode. Keep the application updated and recheck after major changes.

Remove configuration conflicts one at a time

If the results are inconsistent, begin with the provider's supported default setup. Temporarily remove a custom DNS override only when the documentation identifies it as relevant, and record the original value.

Avoid running several VPN or network-filtering applications simultaneously without understanding their interaction. More layers can produce a route that is harder to reason about rather than one that is clearly safer.

Do not disable the firewall, antivirus or certificate checks as a generic troubleshooting step. Ask the provider for a specific explanation of the conflict and the least disruptive fix.

Our browser extension review can help identify old proxy or privacy extensions that are still changing connections.

Keep a small record, not a permanent testing habit

Record the date, device, app version, expected route and test outcome. Recheck when the operating system, VPN app or network setup changes significantly.

A practical result might be: the browser shows the VPN's public IP, DNS behaves as documented and ordinary reconnection tests do not unexpectedly expose the baseline route. That is useful evidence for that setup.

It is not proof of anonymity, an audit of the provider's internal systems or permission to ignore phishing and account security. Keep those tasks separate, and use the Privacy / Security directory to find further documentation only when a specific question remains.

Sources and further reading

1. Mullvad Help: How to prevent DNS leaks Consulted 28 September 2026.
2. Proton VPN Support: DNS leaks when using a VPN Consulted 28 September 2026.

Consult the linked documentation for current details. Settings, availability and interface labels may change.