Provider-neutral self-test pilot
Windscribe deliberately does not ship a kill switch. It ships a Firewall, and it argues the difference matters: a kill switch reacts after the tunnel drops, while the Firewall is on before that and blocks anything not going through the VPN. Its IPv6 handling is conditional rather than a flat yes or no, and it runs its own resolvers. The result speaks for your session only, not for Windscribe's network.
Live test
Windscribe ships a Firewall instead of a kill switch, and its IPv6 handling depends on protocol and location, so read the IPv6 line carefully.
Current-session checks
Read the signals once unconnected and once connected. On Windscribe the lines worth studying are IPv6, which depends on your protocol and location, and DNS, which Windscribe answers itself.
Before you read the result
Windscribe's feature pages and knowledge base state each point below, and its wording about kill switches is deliberate rather than accidental.
Windscribe states that it does not have a kill switch and uses a built-in Firewall instead, on the grounds that a kill switch is reactive and only acts after the VPN has gone down, while the Firewall works continuously to block traffic not going through the VPN. The setting lives under Preferences, Connection, Firewall Mode, and it is the first thing to check after an unexpected reading.
Windscribe documents IPv6 as conditional: it can route IPv6 through the tunnel on WireGuard, on paid locations where the app and the server support it, and otherwise it blocks IPv6 to prevent a leak. So both an IPv6 answer and an empty IPv6 line can be correct on Windscribe - which one you get depends on the protocol and the location you chose.
Windscribe says it uses its own internal DNS servers, which become active when you connect, and that all DNS queries travel over the tunnel. R.O.B.E.R.T. is the blocking layer built on top of that, filtering ad, tracker and malware domains at resolution time - which can also explain a resource that will not load during a check.
Windscribe is explicit that WebRTC can read the local address and bypass a browser proxy, which is why its extension carries a WebRTC Slayer switch. It also notes this is a browser-proxy problem rather than a desktop-app one: with the whole system routed through the desktop app, WebRTC has no separate path out. Which of the two you are using changes how to read the WebRTC result.
Windscribe commissioned Packetlabs to audit its FreshScribe stack in 2024, covering roughly twenty repositories and around eighty thousand lines of code including its own forks of OpenVPN and WireGuard, and published the report unredacted. Like every audit, it describes the provider's systems at a point in time rather than your session.
Between the readings
Windscribe argues that the difference between its Firewall and a kill switch is timing: one is blocking before the tunnel drops, the other reacts after it. Timing is exactly what a recorded drop measures.
Safe Copy exports use safe summary categories and remove raw IP, exact city, full user-agent, raw fingerprint data, raw resolver IPs and WebRTC candidates. It is not a certificate, provider audit, or proof of anonymity.
FAQ
Windscribe says it does not, and uses an always-on Firewall instead. It argues a kill switch is reactive and only acts after the VPN drops, while the Firewall continuously blocks traffic that is not going through the VPN.
Windscribe documents it under Preferences, Connection, Firewall Mode in the desktop app. It is the setting to confirm first when a check reports an address you did not expect.
Conditionally. Windscribe documents routing IPv6 through the tunnel on WireGuard for paid locations where the app and server support it, and blocking IPv6 otherwise so it cannot leak. Both an answer and an empty line can be correct depending on your setup.
Windscribe states that it uses its own internal DNS servers, active when you connect, with all queries travelling over the tunnel. R.O.B.E.R.T. does domain blocking at that layer.
Windscribe describes WebRTC Slayer as an extension feature for the case where you are using the browser proxy only. With the whole system routed through the desktop app, it says WebRTC has no separate path out.
Windscribe had Packetlabs audit its FreshScribe stack in 2024, across roughly twenty repositories and around eighty thousand lines of code, and published the report without redactions. That covers the provider's systems, not your browser.