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.
- VPN Leak Test - the single-moment version of this check, across IP, DNS, WebRTC and IPv6.
- Public Exposure Report - the full browser-session receipt.
- DNS Leak Test - which resolver answered, which is often what survives a reconnect.
- VPN self-test pages by provider - the same checks with each app's own settings named.
- Methodology - how MyIPScan labels confidence and limits.