You are working from a hotel room. Your laptop is connected to the hotel Wi-Fi, and the VPN client says it is connected. When the signal becomes unstable, you switch to your phone’s hotspot.
A few seconds later, the page reloads and your messages begin syncing again.
Everything appears to have worked. But what happened during those few seconds?
Your traffic may have paused until the VPN tunnel came back. It may have been blocked completely. Or the laptop may have restored its regular internet connection first, allowing a few requests to leave before the VPN caught up.
The Connected icon cannot tell you which one occurred. The best time to test a VPN is not five minutes after the connection has settled. It is during the short, messy period when the network is changing underneath it.
When a VPN connects, the operating system uses routing rules to decide which traffic should enter the virtual network interface.
The client encrypts that traffic and sends it to the VPN server.
The important phrase is “which traffic.”
If split tunneling is enabled, some applications may be allowed to use the regular network. A browser may use its own DNS-over-HTTPS settings instead of the system resolver. On a device with both IPv4 and IPv6, the two types of traffic may not follow the same route.
None of these differences automatically proves that something is leaking. A company might send internal applications through its corporate tunnel while leaving video calls on the local connection.
A user may have excluded a latency-sensitive application on purpose. That is an expected bypass if it matches the intended policy.
The problem begins when the actual route does not match the expected one.
Before testing, decide what should happen. Are all applications meant to use the tunnel, or only selected ones? Should the internet stop working if the VPN drops? Are IPv4, IPv6, and DNS queries all expected to follow the same route?
Without that baseline, almost any unfamiliar IP address or DNS resolver can look like a security failure.
Disconnect the VPN and record your current public IPv4 address. Check whether the device has a working public IPv6 connection and note which DNS resolver is handling queries. Write down whether you are using home Wi-Fi, an office network, hotel Wi-Fi, or a mobile hotspot.
Connect the VPN and repeat the same checks with the same device and browser.
A basic record might look like this:
| Test state | Visible IPv4 | IPv6 result | DNS resolver | Current network |
| VPN disconnected | Original public address | Available or unavailable | Original resolver | Home Wi-Fi |
| VPN connected | VPN exit address | Tunneled or blocked | Expected resolver | Home Wi-Fi |
| Network changing | To be observed | To be observed | To be observed | Mobile hotspot |
There is no single correct address for every setup. The purpose of the baseline is to make the original network recognizable.
If its public address returns when it should be blocked, you have something specific to investigate.
A single screenshot from an IP checker is not enough. A routing change may last only a second or two. By the time you refresh the page, the tunnel may already be back.
A better method is to use a trusted public IP-checking service that permits automated or repeated queries. Send harmless requests at the rate allowed by the service and keep a timestamp beside each result.
Do not log in to a bank, company dashboard, or other sensitive account during the test. You are checking the connection path, so there is no reason to involve real data.
A sample record could look like this:
10:14:02 — Started switching from Wi-Fi to a mobile hotspot[Text Wrapping Break] 10:14:04 — VPN client showed Reconnecting[Text Wrapping Break] 10:14:05 — Test request returned the original public IP[Text Wrapping Break] 10:14:07 — VPN client returned to Connected
This is only an example of how to record the test, not a real test result. It shows why the final connection status is not enough. A check performed at 10:14:07 would miss the two seconds that mattered.
Whichever VPN you use, run the test with the same kill-switch, auto-connect, and split-tunneling settings you depend on every day.
Turning on stricter settings just to produce a clean result tells you very little about your normal protection.
Start by moving from one Wi-Fi network to another. The physical network interface and gateway may change.
Watch whether requests pause until the tunnel returns or continue while the client is still reconnecting.
Next, switch from Wi-Fi to a phone hotspot or cellular connection. Remote workers do this often in hotels, airports, and cafés. The question is not whether the VPN eventually reconnects.
It is whether any request bypasses the tunnel and leaves through the new upstream connection first.
Sleep and wake behavior is also worth checking. A client may lose its session while the device is asleep and need to negotiate a new connection after wake-up.
If email, cloud storage, or the browser resumes faster than the VPN, background requests could get a head start.
Finally, change VPN servers or briefly stop the client. If the intended policy is fail closed, protected traffic should remain blocked between the old tunnel ending and the new one becoming ready.
If the original public IP returns at once, check whether that behavior was allowed by the settings or whether the kill switch failed to work as expected.
Captive portals need separate treatment. Hotel and airport networks often require users to open a sign-in page before a VPN can reach its server. The limited traffic needed to complete that sign-in is not automatically a leak.
Avoid visiting other sites, complete the network login, connect the VPN, and then begin the actual test.
A returning public IP is fairly easy to understand. DNS results are not.
Browsers such as Firefox and Chrome may use DNS over HTTPS instead of the resolver supplied by the operating system. An organization may also use split DNS, sending internal and public domain queries to different places.
Seeing a resolver that does not carry the VPN provider’s name is therefore not enough to prove a DNS leak.
The result must be read alongside the configuration.
| What you observe | Possible explanation | What to check next |
| Original public IP returns during the switch | Kill switch did not block traffic, split tunneling is active, or regular access is allowed after disconnection | Fail-closed and application-exclusion settings |
| Public IP looks correct, but DNS is unexpected | Browser DoH, split DNS, system fallback, or DNS bypass | Browser and system DNS settings |
| IPv4 uses the tunnel, but original IPv6 appears | IPv6 is neither tunneled nor blocked | IPv6 support and routing |
| Only one application shows the original IP | Per-app rule or split-tunnel exclusion | Application allow and exclusion lists |
| Internet access stops when the VPN drops | Fail-closed behavior may be working | Reconnect and repeat the same test |
Browser results only describe browser traffic. Split tunneling might place the browser inside the tunnel while a terminal tool or another application uses the regular network.
The reverse can also happen when the browser has its own secure DNS configuration.
Compare at least one browser result with a system-level check. If they disagree, investigate which application created each request and which network interface handled it.
Packet-capture tools such as Wireshark can help with deeper analysis, but do not begin there.
Many problems can be found by comparing the baseline, running repeated requests, and reviewing application-routing rules.
Also, do not treat every private address as a serious leak. Addresses beginning with 192.168 or 10 are commonly used inside local networks.
Their appearance in connection details does not mean a website has learned the device’s original public IP.
“Kill switch” is a product feature name, not a single technical standard shared by every operating system.
According to Android’s VPN documentation, always-on VPN can keep a selected VPN service running, while blocking connections that do not use the VPN is a related but separate control.
Android also supports per-app rules that can place selected applications inside the tunnel while allowing others to use the system network.
The key icon in the Android status bar, the always-on setting, and “Block connections without VPN” do not mean the same thing.
For fail-closed protection, the setting that matters is the one that controls what happens to protected applications when the tunnel is unavailable.
Apple also separates VPN On Demand, Per-App VPN, and Always On VPN. On Demand and per-app rules can trigger a connection for selected domains or managed applications.
Always On VPN is mainly designed for supervised devices managed by an organization.
An auto-connect option on a personal device should not be assumed to behave like an enterprise Always On deployment.
Windows LockDown VPN is closer to a strict fail-closed design. It uses a forced tunnel and blocks outbound network traffic when the VPN is unavailable.
However, it has deployment limits, and Microsoft notes that the built-in LockDown option is available only for IKEv2 connections.
Feature labels show how a tool is intended to work. A controlled network switch shows what it actually does on the device in front of you.
If the original public IP appears during a network change, begin with the kill switch, always-on behavior, and split-tunneling rules. Do not change the protocol, server, DNS settings, and client version at the same time.
If the problem disappears after four changes, you will not know which one fixed it.
When only DNS looks wrong, inspect the system resolver, browser DoH settings, split DNS, and any fallback behavior allowed during a tunnel failure.
If the original IPv6 address appears while IPv4 remains protected, check whether the client supports IPv6 tunneling or blocks IPv6 when it cannot carry that traffic.
Disabling IPv6 may hide the symptom, but it should not be treated as the universal first answer. Correct routing or explicit blocking is a better fix when the platform and client support it.
After changing one setting, repeat the exact same network switch with the same testing method. A result that can be reproduced is worth more than a single clean screenshot.
Save a short record of the working configuration. Client updates, operating system upgrades, and policy changes can alter routing behavior, so an old test describes only the setup that existed at that time.
A clean result tells you that no obvious unexpected path appeared on the device, applications, and network changes you tested.
It does not audit the provider’s logging practices or server infrastructure. It cannot stop phishing, malicious downloads, ignored certificate warnings, or malware already running on the device.
A perfectly encrypted tunnel can still carry a password to the wrong website.
The final pass-or-fail rule is simple.
If protected connections stop when the tunnel fails and resume only after the VPN is ready, fail-closed protection is doing its job.
If the original public IP, an unprotected IPv6 route, or other traffic that should have stayed inside the tunnel appears during that gap, the Connected icon matters far less than it seems.
CISA's latest advisory for red teams warns critical infrastructure operators that security systems can fail…
Alice, the AI trust, safety, and security company formerly known as ActiveFence, has closed a…
SynkLoader is using Microsoft Teams conversations to turn routine IT support requests into a route…
ToxNetV2 is a Linux botnet that shows how artificial intelligence can move closer to real…
WhatsApp has confirmed that more than 1 billion people now use passkeys to log into…
ASOS US Sales LLC reported unauthorized access to customer accounts using credentials obtained from outside…