Clicking Connect is only the first step in using a VPN. An app can display a green status while a browser still reveals information through a separate setting, a network change or an application outside the tunnel. You do not need specialized security equipment to perform a useful check. A handful of repeatable tests can tell you whether the connection is reaching the VPN server and whether obvious routes around the tunnel are exposed. This guide explains what each result means and how to avoid false alarms.
Quick Answer
A VPN is working when your traffic uses the intended VPN route, the apparent public IP changes as expected, and DNS or browser leak tests do not expose unexpected network details. No single website proves complete privacy. Test both while connected and after disconnecting, and repeat after changing networks.
What Matters Most
The safest interpretation of any result is specific: describe what the test observed, not what it cannot prove. The sections below explain the practical trade-offs, what to test and when a VPN feature is worth using.
Start With a Baseline Before Connecting
Before opening your VPN, search for your public IP address in a browser and note the approximate location and ISP shown. Do not treat the mapped city as exact: IP databases often assign nearby cities or outdated locations. Record whether you are on home Wi-Fi, cellular data or a work network. That baseline makes it easier to tell whether the VPN changes your public-facing connection.
Now launch the official VPN app, choose a nearby country or server and wait for its connected state. Return to the IP-check page. The public IPv4 address should normally change, and the apparent network should correspond to the selected VPN exit. If you see the same residential or mobile IP as before, stop and investigate before relying on the tunnel.
Understand What an IP Address Test Proves
A changed public IP confirms an important part of the route, but not necessarily the security of every app. Browser proxies, split tunneling and browser-only VPN extensions can affect one program while leaving other traffic unchanged. That can be intentional. A user who split-tunnels a bank app should expect that app to use the normal route even while other traffic is protected.
Check a second independent IP-information website rather than trusting only the label displayed in the VPN app. If the service shows the correct VPN IP but lists the wrong city, it may be an outdated geolocation database rather than a leak. Compare the provider name, IP and country instead of treating a city mismatch as definitive evidence of failure.
Check DNS Requests, Not Just the IP
DNS turns domain names into numerical addresses. If your browser uses your ISP resolver outside the VPN when you expected encrypted DNS through the tunnel, it can reveal which domains you look up. A DNS leak test queries specially generated names and reports the resolvers involved. Seeing a cloud provider or a resolver in another city is not automatically a leak.
Focus on whether resolvers belong to the expected VPN or the DNS provider you deliberately selected. Some browsers use secure DNS independently of the operating system, so results can legitimately differ. If you see your familiar residential ISP resolving queries unexpectedly, inspect custom DNS settings, browser secure-DNS configuration, split-tunneling rules and the VPN app’s DNS controls.
Test IPv6 When Your Network Supports It
Many home and mobile networks support IPv6 alongside IPv4. A VPN can appear successful on IPv4 while mishandling IPv6 if the client or configuration does not route or block it correctly. Use an IPv6 test to determine whether the underlying network offers IPv6 and which address is exposed during a VPN connection.
Not seeing an IPv6 address is not automatically a problem; some VPNs intentionally disable or block IPv6 while connected. If an active IPv6 address remains visible and belongs to your normal ISP while the VPN claims full-device coverage, consult the provider’s documentation. Avoid disabling IPv6 permanently as a first reflex; the correct fix depends on the app and network.
For the provider-specific perspective, read our NordVPN review before making a long-term VPN decision.
Treat WebRTC Browser Results Carefully
WebRTC powers browser video calls and real-time communication. Older browser behaviors sometimes exposed local or public addresses in ways that confused users testing VPNs. Modern browsers include protections and may return temporary or obfuscated addresses. A diagnostic tool showing a private 192.168.x.x or 10.x.x.x address does not automatically reveal your identity to every website.
Run a browser-specific WebRTC test while connected. What matters is whether a public address belonging to your normal connection is exposed when it should not be. Browser extensions, privacy settings, local network permissions and corporate WebRTC policies can alter results. Test the browser you actually use instead of extrapolating from a different device.
Check the Kill Switch by Interrupting the Network
A kill switch aims to prevent traffic from silently returning to an unprotected route when the VPN disconnects unexpectedly. Enable the relevant protection in your VPN app, begin a harmless browser refresh loop or download from a trusted page, then briefly interrupt the VPN connection. The expected behavior depends on whether the app offers an always-on or app-only kill switch.
Do not perform this experiment while accessing sensitive accounts. Observe whether traffic pauses until reconnection, and repeat after your phone switches between mobile data and Wi-Fi. A VPN that reconnects quickly but permits a brief direct connection may not meet the requirements of someone who needs strict traffic blocking.
Repeat the Test on the Device You Actually Use
A passing desktop test does not validate an iPhone, Android phone, Fire TV or router configuration. Every operating system uses its own VPN routing rules. Android users can inspect Always-on VPN and Block connections without VPN; iPhone users should review the app’s on-demand behavior and reconnect after sleep. Windows users should consider split-tunneling rules and multiple network adapters.
If a router handles the VPN, test a device connected through that router and also confirm whether a guest network bypasses it. For browser extensions, remember that apps outside the browser may still use the unprotected connection. A useful test matches the route you intend to protect.
What to Do When a Result Looks Wrong
Begin with simple causes: disconnect and reconnect, switch to a nearby server, restart the VPN app, update its version, and test a different browser. Disable any second VPN or proxy temporarily because competing network tools can cause unexpected routing. If the problem occurs on one Wi-Fi connection only, compare it with mobile data.
For persistent DNS or IPv6 exposure, export the diagnostic output without including passwords or personal identifiers and contact the provider’s support team. Explain the device, operating system, VPN protocol, selected server and exact test behavior. Do not immediately buy a second subscription until you understand whether the problem is configuration, app support or the service itself.
Know the Limits of Every Leak Test
A leak test cannot prove that the VPN provider keeps no logs, encrypts every connection correctly or resists every future attack. Websites may still recognize you through account sign-ins, cookies or browser fingerprints. A VPN does not remove malware, repair a compromised computer or make unsafe downloads trustworthy.
The best outcome is a repeatable process: baseline IP, connected IP, DNS, IPv6 where relevant, browser WebRTC behavior and a disconnect test. Add software updates and account security to that routine. If the results change after an operating-system or browser update, repeat the tests before assuming your old setup still behaves identically.
A Reliable Five-Minute Routine
Open a normal browser tab and note your initial public IP and DNS result. Connect to a nearby VPN server and repeat both checks without changing browsers. If the apparent IP changes but DNS still points to a familiar ISP resolver, investigate the configured DNS rather than declaring total failure. Check IPv6 only if the underlying network supports it, and use WebRTC diagnostics to look for an unexpected public address. Finish by testing an ordinary network handoff. Save the observations privately so you can compare them after a future app or operating-system update.
What a Good Report Looks Like
A useful record identifies the date, phone or computer model, operating system, VPN app version, protocol and country selected. Note the observed IP country, the resolver organization, whether IPv6 is available and whether the app prevented fallback during a connection interruption. It is better to write “the public IP changed and the DNS result matched the intended configuration” than “100 percent anonymous.” This language tells another reader exactly what was checked, and avoids turning a narrow result into an unsupported privacy promise.
Real-World Situations
Home Wi-Fi privacy check
Connect to a nearby server, verify a new public IP and confirm the DNS resolvers are expected. Then turn the Wi-Fi off and back on to see whether the VPN automatically reconnects. This gives a more useful picture than checking only the green connected symbol.
Work laptop with split tunneling
Document which approved work applications bypass the VPN and which use the tunnel. A different IP inside a browser and a meeting app can be correct by design. Avoid changing company-managed routing settings without approval.
Hotel captive portal
Complete the hotel sign-in page before starting the VPN if the portal blocks access. Once connected, run the IP and DNS tests again. If the VPN stays connected but the internet stops, captive portal rules can be involved.
Android network handoff
Switch from a Wi-Fi network to mobile data with a harmless site open. Check whether the app reconnects and whether Android’s blocking setting behaves as intended. Device battery optimization can interfere with background operation.
Frequently Asked Questions
How do I know whether a VPN changed my location?
Compare your public IP and reported country before and after connecting. IP geolocation is approximate, so a slightly wrong city does not necessarily mean the VPN failed.
Is a DNS leak dangerous?
An unexpected DNS route can expose requested domain names to a resolver you did not intend to use. It does not mean the entire content of every HTTPS page is visible.
Why does a leak test show a cloud provider?
VPN services frequently use hosting companies or external resolvers. Compare against the provider’s published DNS design before assuming that any unfamiliar organization represents a leak.
Should I disable WebRTC?
Usually not as a first step. Current browsers use privacy protections. Investigate whether a real public ISP address is exposed and whether changing browser settings would break video calls.
Can I test my VPN for free?
Yes. Public IP checks, DNS tests, IPv6 diagnostics and built-in operating-system VPN settings are normally enough for a practical first-pass verification.
Final Verdict
If your public IP changes as expected and DNS, IPv6 and reconnect behavior match your intended setup, you have useful evidence the VPN is routing traffic correctly. Repeat after changing devices, networks or major app settings. For a broader shortlist of services to evaluate, use the reviews and comparisons below rather than buying based on one leak-test result.
Explore Related VPN Guides and Reviews
For details about individual VPN services and the trade-offs between them, continue with these OnlyVPNGuide resources: