MyIPScan

Privacy diagnostic

VPN Kill Switch Test

A kill switch is meant to block every packet from the moment a VPN tunnel drops until it comes back. When it does not, the address underneath is visible for a few seconds - and it is invisible to the person it happens to precisely because it is brief. This records the drop while it is happening and tells you how long your own address was on show, in your own session, on your own machine.

Record a drop on your own connection

Three steps. The first two give the recorder something to compare against; the third is the part you have to do yourself, because nothing on a web page can disconnect your VPN for you.

  1. Step 1: capture your own network

    Disconnect the VPN completely, then capture. This reading is what lets the recorder tell your ISP apart from a different VPN server later. It never leaves the page.

    not captured

  2. Step 2: capture the tunnel

    Connect the VPN again and capture the address it gives you. Anything that is not this address, once recording starts, is something worth timing.

    not captured

  3. Step 3: force the drop

    Start recording, then break the tunnel the way it breaks in real life: quit the VPN app, disable the network adapter, or switch the phone between Wi-Fi and mobile data. Reconnect when you are ready.

What the recorder saw

Nothing recorded yet.

Real network visible
no reference captured
Tunnel address gone for
no drop recorded
Samples with no reply
none
First exposure
-
Matches
0 exact, 0 same-network
Samples taken
0
Gap achieved
-

Sample by sample

Consecutive samples with the same outcome are grouped. The first and last timestamps of each group are what the reported window is built from.

    The result you can post

    Nothing here is stored or transmitted. The readings live in this tab until you close it, and no visitor's recording is collected, aggregated or published.

    How the recorder tells a block apart from a leak

    The awkward part of measuring a dropped tunnel is that the drop breaks the measurement too. A sample that fails and a sample that succeeds mean opposite things, so the recorder sorts every reading into one of four outcomes and only one of them counts as exposure.

    No reply at all
    Nothing got out of the browser. This is consistent with a kill switch holding, and consistent with a cable being out. The recorder reports the silence and not a cause.
    The tunnel address
    The reading matches what you captured in step 2. The tunnel is still carrying traffic.
    Your own address
    The reading matches what you captured in step 1. Traffic left the machine outside the tunnel: this is the leak, and it is the only thing counted as one.
    Some other address
    Neither reference matched. Reconnecting to a different server in the same VPN looks like this, and it is not a leak, so it is timed separately and never added to the exposure figure.

    The reported window comes with both of its bounds. The lower one is the span actually observed, from the first matching sample to the last. The upper one is the widest window the samples still allow, because a leak can begin the instant after one reading and end the instant before the next. A result that says at least 3.6s, at most 4.8s is stating the measurement and its resolution in the same breath.

    Which makes the gap between samples the number everything else rests on. The loop asks for one every 1.5 seconds, and one every 0.6 seconds for twelve samples after anything changes. It does not always get it: forcing a disconnect means going to the VPN app, that puts this tab in the background, and browsers clamp background timers to about one per second. So the recorder reports the gap it achieved rather than the gap it wanted, and says how long the tab was hidden. Every window narrower than that gap is one it could have missed.

    What this recording cannot establish

    • It is one session, one device, one browser and one moment. Running it twice can give two different answers, and both of them are real.
    • It is not a test of any VPN application. Nothing here covers other servers, other platforms, other protocol settings or other versions of the same app, so a recording is evidence about your run and not about the software in general.
    • Silence is not proof. Samples that get no reply show that traffic was not moving, not who stopped it.
    • If your own address changed since you captured it - a reconnected router, a mobile handover, carrier-grade NAT - a genuine exposure can land in the “some other address” column instead. The recorder errs towards under-reporting, and the same-network match exists to catch part of that gap.
    • MyIPScan does not gather these recordings, does not compare providers and publishes no ranking. What you get is your own measurement to do with as you like.

    Where to run it next

    The recorder answers one question. These answer the ones next to it: what your session exposes right now, which resolver is answering for you, and how the same checks read on the app you are actually using.

    Quick reference

    VPN Kill Switch Test: what this tool does

    Samples the visible address continuously while a VPN tunnel drops and reconnects, and reports how long the real address was reachable.

    How to use

    1. Capture one reading with the VPN off, so the recorder has your own network to compare against.
    2. Reconnect, capture the tunnel address, then start recording and break the tunnel the way it breaks in real life.
    3. Read the pair of bounds, not the single number: the lower one is what was observed, the upper one is what the sampling gaps still allow.

    What the result means

    The page polls /api/ip-sample, asking for a reading every 1.5 seconds and every 0.6 seconds for twelve samples after anything changes, then sorts each one into four outcomes: the tunnel address, your captured address, some third address, or no reply at all. Only a match against your captured address is counted as exposure, and the reported window carries both the span observed and the widest span the gaps allow.

    Limitations

    • A sample that gets no reply shows that nothing left the browser, not what stopped it. A kill switch, a pulled cable and a sleeping radio are indistinguishable from inside a page.
    • Without the reading taken with the VPN off there is no reference, so an address that is not the tunnel can only be reported as unclassified rather than as yours.
    • Browsers clamp timers in a background tab to about one per second, and forcing a disconnect usually backgrounds this one, so the gap achieved is measured and printed rather than assumed. A window shorter than that gap can be missed entirely.
    • An address that changed since it was captured lands in the unclassified column rather than the exposed one, so the count errs low.
    • It records one session on one device at one moment. It establishes nothing about any VPN application across servers, platforms, protocols or versions.

    FAQ

    Does a failed request prove the kill switch worked?

    No, and the recorder never says it does. A request that gets no reply only shows that nothing left the browser at that moment. A kill switch blocking traffic looks exactly like an unplugged cable, a sleeping Wi-Fi radio or a server outage from inside a page, so the timeline calls it “no reply” and leaves the cause to you.

    Why does it ask me to disconnect the VPN first?

    So it has a reference. Without one, an address that is not the tunnel could be your own ISP or simply a different VPN server, and those are opposite results. The reading taken with the VPN off is what lets the recorder say “this is your address” instead of “this is some address”. You can also capture it after the recording and the timeline is re-derived.

    How short a leak can it catch?

    It asks for a sample every 1.5 seconds, and every 0.6 seconds for twelve samples after anything changes, so a window longer than the gap it achieved will get at least one sample. Forcing a disconnect usually means leaving this tab, and browsers clamp timers in a background tab to roughly one per second, so the recorder measures the gap it actually managed and prints it beside the result. Anything shorter than that gap can be missed entirely.

    Does MyIPScan collect these recordings?

    No. The readings exist in the page until you close the tab. Nothing is written to storage, nothing is sent anywhere, and no result from any visitor is aggregated, published or turned into a verdict about a provider.