How to Check Whether Your VPN Is Working

A connected icon only shows that the VPN app believes it established a session. A useful check compares observable network behavior before and after connecting, then confirms that the apps and protocols you care about use the expected route.

1. Record a Baseline With the VPN Disconnected

Disconnect the VPN, close any other proxy or privacy relay, and record the public IPv4 address, public IPv6 address if present, ISP or network name, and approximate location shown on the homepage. This baseline gives you something concrete to compare.

2. Connect and Compare the Visible IP

Connect to the intended VPN server, reload the page, and compare both address families. The VPN detector provides a quick network-based signal, but it cannot verify every app or guarantee that a connection is private.

• The visible address should normally differ from the disconnected baseline
• The network owner should normally be the VPN operator or its hosting provider, not your residential or mobile ISP
• The displayed country should broadly match the selected exit region
• A city mismatch alone is not proof of failure because IP geolocation is approximate

If the address changes but the city looks unexpected, review why IP location databases disagree before changing settings.

3. Check IPv4 and IPv6 Separately

A device can have both IPv4 and IPv6 connectivity. A VPN may route both, route only one, or deliberately disable an unsupported protocol. Compare every public address shown before and after connecting rather than checking only the first one.

• If both addresses change to the expected network, both observed browser routes appear to use the VPN
• If IPv4 changes but the original public IPv6 remains visible, consult the VPN's IPv6 documentation
• If IPv6 disappears after connecting, that may be an intentional product design rather than a leak
• If no public IPv6 was present in the baseline, an IPv6 result cannot be inferred from that session

4. Review DNS Behavior Carefully

DNS translates names into addresses. A DNS test can report which resolver answered its specially generated queries, but the resolver name may belong to the VPN, a privacy DNS service, a cloud provider, or a content-delivery partner.

• Compare resolver operators with the VPN disconnected and connected
• Check the VPN documentation for the DNS design it intends to use
• Treat an unfamiliar resolver as a reason to investigate, not automatic proof of a leak
• Remember that browser secure-DNS settings can intentionally select a resolver independently

5. Interpret WebRTC Results in Context

WebRTC supports real-time browser communication and can expose network candidates to a page that runs a test. Modern browsers commonly reveal private or obfuscated local candidates; a private address such as 192.168.x.x is not the same as exposing your original public IP.

Compare any public candidate with the disconnected baseline. If a test shows the original public IP while connected, reproduce the result in an updated browser and follow the VPN provider's WebRTC guidance.

For the protocol-level privacy considerations behind these results, see the IETF WebRTC IP Address Privacy Requirements.

6. Confirm Which Apps Use the VPN

A browser result describes the browser route. Split tunneling, per-app VPN settings, browser proxies, containers, virtual machines, and work profiles can intentionally use different paths.

• Review split-tunneling exclusions in the VPN app
• Repeat the check inside each browser profile or environment that matters
• For a command-line app, inspect its route or make a request from that app rather than assuming the browser result applies
• Check managed-device policies if an employer or school controls the network configuration

Common Results and What They Mean

• IP unchanged: the tunnel may not be active, the browser may use another proxy, or the traffic may be excluded
• IP changed, location unchanged: the VPN server or its IP record may be near you; compare the network owner
• Location in a neighboring city: normal geolocation uncertainty is more likely than a routing failure
• Some apps change and others do not: inspect split tunneling and app-specific network settings
• Internet stops when the VPN disconnects: a kill switch may be working as configured

Troubleshooting Order

• Reconnect once and reload the test without a cached page
• Confirm that the selected server reports connected inside the app
• Temporarily review split-tunneling and browser-proxy settings
• Try another server from the same provider
• Update the VPN client and operating system
• Capture the before-and-after addresses and contact the provider if the result persists

For the narrower question of why an address changes, see how a VPN changes your public IP. For the broader privacy limits, see what a VPN does and does not hide.