Short answer
Enable Kill Switch and prepare a controlled test that loses the VPN tunnel while internet remains available. Disconnecting WiFi does not demonstrate that blocking works. Check relevant applications, exclusions and recovery; if you cannot create and observe that condition reliably, leave acceptance pending.
Key verification: Record internet, tunnel and application states separately before, during and after the controlled failure.
Sources and limitationsA VPN may connect successfully and still need a test of what happens when its tunnel fails. Kill Switch addresses that moment: checking whether an application continues sending traffic over the ordinary connection or loses access until the intended protection returns.
Define the condition you need to check
The Surfshark Kill Switch documentation describes blocking internet when the VPN connection drops and enabling the option in the app. Check instructions for your operating system and installed version. An enabled switch establishes a configuration, not a test result.
Separate an unexpected tunnel loss from pressing the disconnect button. Record which condition you are testing and what behaviour the app documents for that action. Do not extrapolate a manual disconnection result to a different failure you have not reproduced.
A complete internet outage is insufficient evidence
If you switch off WiFi and every page stops loading, you cannot tell whether blocking intervened: the computer also lost its physical connection. The intended condition requires distinguishing a failed tunnel from an available underlying connection. Lack of browsing alone does not identify its cause.
Prepare the test on an authorised device without calls, payments or deliveries in progress. Use a controlled failure method recommended by support for your environment. If you lack a reliable way to retain internet while the tunnel fails, record a pending test. Do not improvise network changes on a production workstation or declare acceptance complete.
Original observation matrix
| Stage | Underlying connection | VPN tunnel | Observation |
|---|---|---|---|
| Before the test | Available | Connected | The application completes the control request |
| Controlled failure | Available and verified | Down | The included application loses access |
| Excluded application | Available | Down | Separate result based on its intended route |
| Recovery | Available | Restored | The application regains access and retains work |
The matrix proposes an acceptance criterion rather than a CallsIQ observation. Record time, device, version and configuration. A row without evidence remains pending. Use test requests without credentials or client information, retaining only the records needed to explain behaviour.
Review exclusions before interpreting results
An application configured outside the tunnel should not be evaluated as an included application. Map each application to its intended route and check current exclusion options. If you do not know how exclusions interact with Kill Switch on your device, consult support and test that case separately.
Checking a visible address on an external page may help observe one request, but does not establish the route of every application. It also does not establish complete anonymity. Limit acceptance to the condition and applications actually checked.
Include recovery and work continuity
Fictional example: an agency uses a browser inside the tunnel and a phone application on another route. The browser loses access during the test; the phone application needs separate evaluation. Do not attribute every audio interruption to the phone provider or declare its traffic protected just because the browser passed.
After VPN recovery, verify that a new request works and pending work was not sent twice. Retain a recovery procedure users can follow. Surfshark may fit a need to manage this connection condition; CallsIQ has not performed the test or validated blocking on actual devices.
Sources and limitations
Documentary review: . Content type: Documentation-based guide with original resource.
Sources describe terms and capabilities stated by their owners. Proposed protocols and fictional examples do not establish product tests performed by CallsIQ.
- Surfshark Kill Switch documentationsupport.surfshark.com
Check current terms
Consider these options if they solve the problem described. Confirm features, limits and availability in your country.
SurfsharkAffiliate linkThe labelled commercial links may earn CallsIQ a commission or referral reward. Our commercial policy.
Official sources, explained calculations and clearly labelled examples. Read about our methodology and use of AI in writing.