How to Test Your VPN: A Step-by-Step Guide to Checking Security and Leaks

A useful VPN test asks whether traffic follows the route you intended and whether that behavior survives a connection failure. Start with the public address websites observe, then check DNS, WebRTC, IPv6 and apps outside the browser. Finally, check recovery and performance under the conditions you actually use.

A VPN’s “Connected” label only describes the client’s reported state. A changed public IP shows that a particular request used a different exit, but it cannot establish that every app is protected. A browser leak test and an inspection of the client configuration provide different pieces of evidence.

Read how VPNs work if you want to understand the route from your device to the gateway. Our guide to VPN limitations explains why a clean leak test does not guarantee anonymity.

Use your own device and an authorized network. Save work and pause sensitive activity before any test that deliberately disconnects the tunnel. Keep the first comparison simple: one device, one connection and the VPN’s full-device mode, with split tunneling temporarily disabled if your configuration permits it.

1. Record the setup. Note the operating system, VPN app version, browser, selected protocol, server, kill-switch mode and any custom DNS setting.
2. Identify extra routing layers. Browser proxies, other VPN extensions, private-relay services, work gateways and router VPNs can change the observed address. Document them and test separately where possible.
3. Disconnect the VPN intentionally. If strict blocking prevents baseline access, temporarily allow the baseline according to the client’s documented settings. Restore protection before the connected and failure tests.
4. Record public IPv4 and IPv6. Note whether IPv6 actually works without the VPN, rather than assuming your network supports it.
5. Run a DNS and WebRTC baseline. Save the raw addresses and resolver names, not just a summary badge.
6. Reconnect and repeat the same checks. Use fresh requests on the same network and compare the raw results.

Choose tools that expose the underlying observations

Our IP Leak Test can help collect public-IP, resolver and browser observations. Read the raw results and any availability messages rather than treating a score as proof. A second check, such as Mullvad’s connection-check page, can help compare observations; its “using Mullvad” status is provider-specific.

A test website receives the connection you use to visit it. Keep baseline addresses and test records private, and share only the information needed for troubleshooting. If one tool cannot complete a measurement, repeat with a working test rather than translating “unknown” into “secure.”

Open the same public-IP checker with the VPN connected. For a normal remote consumer VPN in full-tunnel mode, the observed public IPv4 should be the selected VPN exit rather than the address recorded before connecting. Compare the address itself; a flag or city name is secondary.

What counts as a pass or failure?

A pass means the tested request used an expected VPN exit and did not reveal the baseline public IPv4. If the browser still shows the home or mobile-network address, investigate whether it is excluded by split tunneling, using a different profile or displaying cached information. If full-tunnel routing is intended and a fresh request still uses the baseline route, that check has failed.

An unchanged address can be expected for some corporate access-only VPNs, because internet traffic is intentionally left on the normal connection. A router VPN may also remain active while you disconnect a device app. State the intended design before labelling the result.

Location databases can be wrong

A VPN address may be attributed to a nearby city, an old location or a hosting company different from the brand name. Virtual locations complicate the picture further. An unexpected map pin alone is not proof that your home IP leaked.

Check the provider’s server information and our guide to VPN server types. Repeat with another server if the address itself is unclear, keeping the baseline comparison intact.

IPv4 and IPv6 are separate address families and can follow different routes. A VPN that protects IPv4 but leaves a working IPv6 path outside the tunnel can expose an address from your access network to IPv6-capable destinations.

1. With the VPN off, confirm whether an IPv6-specific request succeeds and record the public address or access-network prefix.
2. Connect the VPN and repeat an IPv6-specific check. A generic page might use IPv4 even when IPv6 is available, so inspect which family it tested.
3. Compare the result with the provider’s documented behavior: supported IPv6 should use the intended tunnel; unsupported IPv6 may be deliberately blocked.
4. Repeat after a network change or reconnect, because routes can change when the device switches interfaces.

Do not rely only on exact address equality: mobile networks and IPv6 privacy addressing can change addresses. Compare network ownership and route evidence where needed. Read IPv6 and WebRTC leaks for the underlying differences.

DNS resolves names to addresses. A meaningful browser DNS leak test generates fresh names and observes which resolvers query the test’s authoritative servers. Reading a configured resolver address or querying a public DNS API is not the same measurement.

Run a fresh test before and after connecting. Compare the reported resolvers with the provider’s documented DNS setup and any custom resolver you intentionally use. Unexpected access-provider resolvers deserve investigation when the goal is to keep ordinary DNS within the VPN path.

Multiple resolvers are not automatically a leak

A resolver service can use several outbound addresses or distributed infrastructure. The number of reported addresses is not a reliable pass/fail rule. A third-party resolver can also be intentional. Identify who operates it and whether queries reach it through the route you selected.

Likewise, a resolver in another country does not establish that your connection bypassed the tunnel. Country labels are database estimates, and resolver infrastructure does not necessarily match the exit’s advertised location.

Account for browser secure DNS

A browser using DNS over HTTPS may contact a resolver independently of the operating system’s DNS setting. Mozilla’s Firefox DNS-over-HTTPS documentation explains the browser-level feature. Check whether it is active, what resolver is selected and whether fallback behavior changes the result.

A DoH resolver different from the VPN’s resolver is not, by itself, proof of traffic bypass. Its encrypted connection may still travel through the VPN, while giving that resolver visibility into queried names. Route protection and resolver trust are separate questions.

Our guide to preventing DNS leaks covers configuration choices. A domain’s DNS-record checker answers a different question from a test of your browsing resolver path.

WebRTC supports browser-based communications and gathers possible connection endpoints called ICE candidates. These can reveal useful network information. A test should identify whether a candidate exposes a public address from the access network when the intended policy is to keep that traffic inside the VPN.

MDN’s ICE candidate-type documentation distinguishes host candidates, reflexive candidates and TURN relay candidates. Their addresses have different meanings; compare the candidate with your baseline and expected route rather than counting candidates.

Test the browser you actually use

Browser policies, extensions, profiles and permissions can change candidate behavior. Test each browser used for calls or sensitive work, and consider whether granting microphone or camera permission changes the result. An address test without permissions does not necessarily represent every call scenario.

If you find a public-address bypass, confirm that a full-device VPN is active, check UDP and IPv6 handling, and review the browser’s supported privacy controls. Disabling WebRTC can break conferencing; choose a control that matches your needs and verify both privacy and functionality afterward.

A kill switch should prevent the traffic covered by its policy from escaping through the normal connection when the tunnel is unavailable. Some modes block all internet access, some act on selected applications, and some remain active only after a VPN session starts. Confirm the promised behavior before interpreting a test.

Use fresh requests and keep another path available

1. Enable the relevant protection and confirm the expected VPN public address.
2. Start repeated fresh public-IP requests or controlled traffic that you can observe. Avoid cached pages; record failures as well as returned addresses.
3. Briefly interrupt and restore the underlying connection, such as by toggling your own Wi-Fi. If a device can fall back to mobile data or another interface, include that path deliberately in the test.
4. Watch the period after network access returns but before the VPN reconnects. Protected traffic should be blocked or use a re-established tunnel, rather than reveal an access-network address.
5. Repeat with documented client failure scenarios where feasible. A tunnel-only failure while ordinary internet access remains available is a stronger test than removing every connection.
6. Reconnect normally, confirm recovery and record the mode, event and observed results.

For an advanced tunnel-only test, an experienced user can temporarily block the specific VPN gateway on an authorized local firewall while leaving general internet access available. Account for endpoint changes and automatic server failover, document the temporary rule and remove it afterward. If you cannot isolate the tunnel reliably, label that scenario not verified.

Intentional disconnects can behave differently

Clicking Disconnect may be defined as permission to resume ordinary traffic in one mode, while an always-block mode keeps traffic stopped. Closing the app window may leave its background service running. Neither action alone reliably simulates a tunnel failure.

Browser polling also has limits. Sampling once per second can miss a shorter escape window, and a paused tab can stop sending requests. Packet capture or controlled continuous traffic offers stronger evidence. Read how kill switches work for the distinctions.

A stable connection can pass while transitions expose weaknesses. Repeat the public-IP, DNS and relevant app checks after sleep, resume, reconnect and a change of network. On a phone, test Wi-Fi-to-mobile and mobile-to-Wi-Fi transitions with the configured protection active.

Always-on and blocking are separate settings

On compatible Android configurations, always-on VPN manages persistent connection while the separate blocking option restricts connections without VPN. The Android VPN documentation explains these controls and app-specific behavior. Availability depends on the client and device configuration.

For other platforms, use the current app and operating-system documentation instead of assuming an Android setting has an identical equivalent. Test the actual applications and transitions you care about; platform services and permitted exceptions can require a more detailed assessment.

Split tunneling intentionally routes selected traffic outside the VPN. A browser test can pass while an excluded downloader, game or video-call app uses the access network. Conversely, a browser deliberately excluded from the tunnel can show your normal public address while another app is protected.

1. List included and excluded applications, domains or routes according to the client’s supported configuration.
2. Test an included browser or app with a fresh request and confirm the expected VPN exit.
3. Test an excluded application separately and compare with the intended ordinary route.
4. Repeat during a disruption, checking how the kill switch treats both included and excluded traffic.
5. Recheck DNS behavior; per-app routing and resolver behavior do not always have identical boundaries.

When an app does not report its public address, use a controlled endpoint you operate or an appropriate packet capture rather than inferring its route from another app. Do not assume a terminal request follows the same route as a browser when rules are application-specific.

Read split tunneling versus full tunneling. Also distinguish a browser proxy extension from a device-wide VPN using our VPN and proxy comparison.

A normal website receives application traffic after it exits the VPN. It cannot directly inspect the encrypted device-to-gateway tunnel, identify its cipher or validate its key exchange just from your public IP. A VPN-detection badge, HTTPS padlock or hosting-network classification is not evidence of a specific VPN encryption configuration.

Start with the client’s actual configuration

Inspect the selected protocol in the app or approved connection profile. Use the provider’s current documentation and relevant connection logs to understand what was negotiated. Redact secrets before sharing logs. Our guides to VPN protocols and WireGuard versus OpenVPN explain the common choices.

Labels such as “automatic” or a provider-branded protocol may require documentation to interpret. Confirm the connection actually established with the expected configuration rather than assuming the preferred selection was used successfully.

Inspect the correct interface when using packet capture

Wireshark’s capture-interface guide explains interface selection. Capturing on the physical Wi-Fi or Ethernet interface helps inspect outer traffic; capturing on a virtual tunnel interface may show traffic before encapsulation or after decryption.

In a controlled full-tunnel test, identify the VPN gateway traffic and look for unexpected direct connections carrying the test activity on physical interfaces. Account for local-network traffic, the VPN’s own control connections, documented exclusions and all active interfaces. Plain DNS on port 53 outside the intended path is a useful clue, but port numbers alone do not establish the full route.

Readable application traffic on a tunnel interface is not automatically an encryption failure. Equally, traffic that looks opaque on a physical interface does not prove the cryptography is implemented correctly. Packet capture adds routing evidence; configuration review and security assessments answer other questions.

Performance affects whether you can use the protected connection consistently, but speed is not a security score. A fast connection can leak, and a slower one can route correctly. Run leak checks and performance checks as separate parts of the same evaluation.

1. Use the same device, network and speed-test destination for the first comparison. Pause large downloads and background synchronization.
2. Run at least three measured trials without the VPN and three with it. Interleave the conditions if network load varies noticeably.
3. Compare median download, upload and latency. Record the VPN server, protocol, test endpoint and time.
4. Repeat with another nearby VPN server if needed. If the test service changes its own endpoint automatically, record that change.
5. Check stability during an actual call or permitted download rather than relying only on a short benchmark.

Calculate a meaningful comparison

Download retention is VPN throughput divided by baseline throughput, multiplied by 100. If your baseline median is 100 Mbps and the VPN median is 80 Mbps, retention is 80% and reduction is 20%. These are example numbers, not measured results for a provider.

Latency is the response time of the test path, usually reported in milliseconds. Jitter describes its variability, and packet loss describes missing packets within a defined measurement. Check how the test actually measures these metrics; an HTTP response time is not interchangeable with an ICMP ping.

Never accept simulated or estimated figures as a measurement of your own connection. Our VPN speed and latency guide explains the factors that change performance. There is no universal percentage reduction that determines whether a VPN is safe.

These charts use an invented lab record to show how to present results. They are not provider benchmarks, a survey or a security certification. Separate observed failures from tests that could not be completed.

A critical failure is not cancelled by several passes. Six clean checks cannot compensate for an observed escape during tunnel recovery. Prioritize fixing the failed behavior and completing the unverified measurement.

Change one relevant setting at a time so the result remains explainable. After a change, rerun the failed check and any related checks. Switching DNS, protocols or routing can solve one issue while changing another part of the connection.

Retest before restoring sensitive activity

If full-tunnel privacy is your goal, pause sensitive work while investigating a confirmed bypass. Use a supported configuration, confirm the baseline comparison and rerun the relevant transition. Keep managed-device changes coordinated with the network administrator.

Our VPN troubleshooting guide can help organize symptoms. If support is needed, provide a concise report with redacted observations, the client version, network type and exact reproduction steps.

A short report makes a clean result reproducible and a failure easier to fix. Separate raw observations from interpretation. Keep full addresses in your private record if needed, but redact them before publishing or sharing broadly.

VPN TEST REPORT
Date / time:
Device / OS / VPN app version:
Browser and profile:
Network: Wi-Fi / Ethernet / mobile
VPN server and protocol:
Routing mode and app exclusions:
Kill-switch mode / startup protection:
Browser secure DNS and custom DNS:

BASELINE (VPN OFF)
Public IPv4:
Public IPv6 or unavailable:
Observed DNS resolvers:
WebRTC candidate observations:

CONNECTED CHECKS
IPv4 / IPv6: passed / failed / not verified
DNS: passed / failed / not verified
WebRTC: passed / failed / not verified
App routing: passed / failed / not verified
Protocol configuration: evidence and limitations

DISRUPTION AND RECOVERY
Event tested:
Ordinary internet path available during test:
Requests or capture used:
Unexpected address / resolver observed:
Sampling interval and remaining uncertainty:

PERFORMANCE
Test destination and measurement method:
Repeated baseline / connected results:
Median throughput and latency:

FOLLOW-UP
Configuration changed:
Retest result:
Unverified scenarios:
Redactions applied before sharing:

When should you test again?

Repeat after a VPN or operating-system update, a protocol change, a new browser profile, altered split-tunnel rules, a router change or travel to another network. Mobile fallback and sleep behavior deserve another check when settings or power-management behavior change.

Use a lightweight routine check for everyday connection confidence and a more complete test after material changes or before sensitive work. There is no universal calendar interval that guarantees continuing protection.

Three studies illustrate different limits of a connection test: website warnings beside verified VPN exits, advertising requests observed inside a VPN tunnel and reporting-service access across connection conditions. They measure messages, disclosures and reachability respectively; a result in one category is not a pass or failure in the others.

A clean test means the tested paths did not expose an unexpected address or resolver under those conditions. It does not verify a provider’s server-side logging, ownership, all software vulnerabilities, future changes or every application on your device.

Websites can still identify logged-in accounts, cookies and browser characteristics. Malware can access information before encryption. Location permissions can reveal position independently of your IP address. A VPN does not remove those sources of identification.

Provider trust needs separate evidence

Read the provider’s logging disclosures, audit scope and operational details. Our guide to VPN jurisdictions and data retention explains why location labels alone are insufficient.

To test your VPN properly, record a baseline, compare IPv4 and IPv6, examine resolver and WebRTC observations, then test failures, transitions and the apps you actually use. Review the client configuration for protocol evidence and measure performance with repeated, comparable trials.

Fix observed bypasses and keep unknown results visible. Retest after material changes, and evaluate provider trust separately from routing. This process gives you a practical, repeatable way to check VPN security without relying on a green badge alone.