VPN SECURITY & PRIVACY CHECKS

How to Check If Your VPN Is Working

By
Updated Oct 18, 2026 9 min read
Our Methodology Editorial Policy

A VPN icon is not the whole answer. An app can display “Connected” while a particular browser, DNS resolver, device setting or network path behaves differently than expected. A useful check looks at several observations—not one magic “safe” badge.

This guide explains how to inspect what a browser can see using free Zend2 tools. It is not a full-device security audit, a guarantee against every Android system exception, or a test of whether a VPN provider keeps logs. Zend2 also publishes its own Android VPN app, so we explain that product's documented limits rather than pretending we independently certified it.

Contents

Quick answer: four checks

If you want to know whether your VPN appears to be working for your browser, follow these steps:

  1. Record a baseline before you connect. On the same browser and network, open What's My IP. Note the public address's network/ISP classification and approximate region, without sharing your full IP publicly. You may also run the other tests before connecting for comparison.
  2. Connect your VPN and check again. Reload What's My IP. A different public address or network may be consistent with traffic going through the VPN, but an IP change alone proves neither full-device coverage nor absence of leaks.
  3. Check DNS observations. Open DNS Leak Test and start its test. Compare the displayed resolver networks with the baseline and your provider's documented DNS configuration. A third-party DNS service is not automatically a leak.
  4. Check IPv6 and WebRTC. Run the IPv6 Leak Test and WebRTC Leak Test. Unexpected public addresses associated with your original connection warrant investigation. Seeing no IPv6 result or seeing a private 192.168.x.x address is not automatically a pass or a failure.

Use the same phone/browser and, where possible, the same network during the comparison. Retry an unexpected result before drawing conclusions. Do not post full IP addresses, account details or screenshot notifications publicly.

What each test can and cannot tell you

Tool Useful question What the observation cannot prove
What's My IP What public address and network does this browser request appear to come from? That every app is routed through the VPN, or that a provider keeps no logs.
DNS Leak Test Which DNS resolver networks did this particular lookup check observe? That no Android system requests ever bypass a tunnel, or that the resolver itself keeps no information.
IPv6 Leak Test Can the browser expose IPv6 connectivity or addresses during this check? That all IPv6 paths are always blocked or tunneled, even after network changes.
WebRTC Leak Test Which local/private or public address candidates can WebRTC reveal in this browser? That a local IP is automatically a public-IP leak or that other apps have been examined.

A tool may display simplified labels such as “PASS”, “FAIL”, or a network-owner match. Read those labels as that tool's interpretation of its observations, not a certificate for the phone, VPN, or operator. IP location databases and ASN comparisons can be imperfect; a browser tool cannot observe all operating-system traffic.

Why your location can still look correct with a VPN on

A website may use signals besides the public address: device location permission, account region, cookies, past sessions, language, billing country or location data saved in an app. A VPN does not override your phone's GPS or erase a signed-in account history. Conversely, an IP-geolocation database may be out of date; a city shown by a lookup is approximate rather than your exact physical location.

If one service shows your usual city, inspect its location permission and account settings before declaring that the VPN leaked. Compare the browser-visible network independently with What's My IP.

Reading DNS results without false alarms

A DNS resolver translates names such as example.com into addresses. Some VPNs use third-party public resolvers rather than resolvers named after their own brand. The existence of a third-party resolver in a DNS test does not, by itself, show that the tunnel was bypassed.

For example, Zend2 VPN's published VPN Privacy Policy says its current default DNS server addresses are Cloudflare's 1.1.1.1 and 1.0.0.1, unless an individual VPN Edge is configured differently. Cloudflare is a separate operator with its own policies. Borsa, Zend2's account/control plane, does not store DNS query names; that is not a promise about every third-party resolver or host.

An unexpected resolver associated with your ordinary ISP, while the VPN is connected, may warrant a closer look. But browser secure-DNS settings, resolver infrastructure and app/OS behavior can complicate interpretation. Repeat the test under controlled conditions and read your provider's actual DNS documentation.

IPv6: absence is not a universal safety guarantee

Some VPN configurations route IPv4 differently from IPv6. An IPv6 browser check can reveal an address or report that none was observed. Neither observation proves what every other app, connection type or later network change will do.

If the tool shows an IPv6 address apparently linked to your original ISP while IPv4 appears to use a VPN exit, treat this as a warning to investigate, not as a conclusive attribution from an ASN comparison alone. Don't disable IPv6, change router-wide settings, or promise a fix without understanding your device and VPN.

Zend2 VPN's current Privacy Policy describes an IPv4 full-tunnel configuration while the VPN is connected, and does not claim universal IPv6 leak protection or capture of every app. This is a stated limitation, not a finding that a leak was observed on any particular user's phone.

WebRTC: distinguish private from public addresses

WebRTC helps browsers establish real-time connections. A WebRTC check can show locally scoped addresses, public address candidates, or masked *.local/mDNS results depending on the browser. A 192.168.x.x or 10.x.x.x private address is not the same as showing your ordinary public ISP address to a website. Compare any public address to your baseline and to the normal browser-visible result before concluding it is exposed.

Disabling WebRTC entirely can break video calls and other browser functions. Avoid installing unverified extensions or turning off browser protections on the strength of a single test label. See the dedicated WebRTC Leak Test for more detail.

Android Always-on VPN and what a browser test misses

Android can offer an Always-on VPN setting and, on some devices/configurations, a way to block connections without a VPN. Availability and behavior depend on the Android version, phone and VPN integration. See Google's Android VPN help. Do not turn off lockdown simply to make a page load.

These settings are not a guarantee that every kind of device traffic is covered. Mullvad published technical reports about Android connectivity-check traffic outside VPN tunnels in 2022, DNS exceptions in 2024, and particular Android bypass vulnerabilities during 2026. Those are descriptions of platform-specific conditions, not evidence that Zend2 VPN failed a test. A browser-only check won't detect every such OS-level path.

If your main symptom is “Connected but nothing loads,” or connection loss when Wi-Fi changes to cellular, read VPN Slow or Disconnecting on Android? instead of treating that problem as proof of a leak.

Your VPN provider's privacy claims are another question

A VPN may change which network address a website sees, but that doesn't verify the provider's logging policy, independence, audit history or retention practices. Review the actual privacy policy and distinguish session/account metadata from records of browsing activity. Watch for absolute marketing slogans not supported by a clear explanation.

Zend2 VPN is a live Android product using VpnService and WireGuard. Its VPN Privacy Policy explains that its control plane, Borsa, may store account/device identifiers, location and session details, the public source IP when a new VPN session record is created, operational timestamps, failure codes and byte totals. The policy says Borsa does not store browsing history, visited URLs, destination IPs, DNS query names or packet payloads. It does not call the product a verified “no-logs” VPN and makes no blanket promise about VPN Edge hosts or third-party DNS resolvers.

Free uses Automatic location; Plus may request a named location subject to availability. Details are on the official Zend2 VPN page and in the VPN Terms. Do not claim a kill-switch audit, a universal IPv6 fix, or perfect reconnection that the documents don't establish.

What to do if a result surprises you

  1. Repeat the observation. Keep the same browser and network; note whether the VPN is connected and whether the relevant page has been reloaded.
  2. Compare the right thing. Distinguish a public address from a private one, an ISP DNS resolver from a documented public resolver, and an approximate IP location from GPS or account settings.
  3. Check your device settings safely. Review the VPN profile and secure-DNS settings without casually disabling a lockdown policy or other protection.
  4. Update and ask support. If a pattern repeats, collect a redacted summary with device model, Android/app versions, timestamp, Wi-Fi versus mobile data and the observed category of result. Do not publish your full IP or account identifiers.
  5. Use the right guide. For disconnections or stalled internet, see Android VPN troubleshooting. For choosing a provider, see the Android VPN checklist.

Interested in the app itself? See Zend2 VPN's features, Free/Plus limits and privacy disclosures or get Zend2 VPN on Google Play. Zend2 Private Browser is a separate app; this link is for the Android VPN package.

Frequently asked questions

No. It can show that this browser request appeared to come from a different network, but it does not prove that every app is protected, that DNS and IPv6 behave as expected, or that the VPN provider does not retain data. Compare IP, DNS, IPv6 and WebRTC observations, and understand their limits.

It may use GPS or location permission, your account or billing region, cookies, or other saved signals rather than your public IP. IP-geolocation databases can also be inaccurate. Check what information the specific site uses before concluding that a VPN connection leaked.

No. Zend2 VPN's published Privacy Policy says its current default DNS addresses are Cloudflare 1.1.1.1 and 1.0.0.1, unless a specific VPN Edge uses different settings. A third-party resolver is not automatically a bypass. A browser test also cannot establish what that resolver or other systems log.

No. It says only that the particular browser test did not observe an IPv6 address under those conditions. It does not certify every Android app, future network change or system connection. Zend2 VPN does not claim universal IPv6 leak protection.

Not by itself. That is a private local-network address. Compare public WebRTC candidates with your normal browser-visible public IP and your baseline before inferring a public-IP exposure. Browser privacy and mDNS handling differ by browser.

No. Browser checks cannot audit server-side records, establish that every app is routed through a tunnel, or validate how a VPN behaves during a real connection failure. Zend2 VPN's policy documents account and session metadata and does not claim verified no-logs status, a universal kill switch, or universal IPv6 leak protection. See the official VPN page and VPN Privacy Policy.

Sources and further reading