The Practical VPN Leak-Test Checklist
A VPN privacy check should test more than a green connection icon. A browser can reach a website while its VPN tunnel is disconnected, and different network features can take different routes. This checklist separates the signals so that an inconclusive test is never presented as a clean result.
1. Record the public IP address
Open the DI VPN IP Address Check before connecting and note the public address and approximate country. Connect to DI VPN, reload the test and compare the address. The website sees the source address of the request that reaches it. Location databases can be imprecise, so use the address as the primary signal and country/city as supporting context.
2. Check WebRTC separately
WebRTC uses ICE candidate gathering to discover possible peer-to-peer paths. Some browsers expose private candidates, public candidates, or mDNS hostnames. A public candidate that differs from the HTTPS address deserves investigation. The absence of a visible candidate is not proof that every application is protected. Read the WebRTC test guide before interpreting the result.
3. Require an authoritative DNS observation
A request to a public DNS-over-HTTPS endpoint only proves that the endpoint answered. It does not identify the resolver used for ordinary system DNS. A meaningful resolver audit uses a unique random hostname beneath a domain whose authoritative nameserver can observe the recursive query. DI VPN labels the DNS audit unavailable until its own authoritative zone is publicly delegated and reachable. See what the DI VPN DNS audit can currently verify.
4. Check IPv6, not only IPv4
A network may have both IPv4 and IPv6 routes. A VPN that changes the IPv4 address does not automatically prove that IPv6 takes the same path. Test an IPv6-only endpoint and interpret an unreachable result carefully: IPv6 may be disabled or filtered rather than protected by the tunnel.
5. Verify Internet traffic through the tunnel
A proxy setting alone is not a successful VPN connection. The client should verify an exit address and make a separate ordinary Internet request. If the Internet request fails, the client should not label the session Protected. Run Check Connection in the same browser profile where the extension is installed.
6. Verify browser protections by their actual state
Read the active ad/tracker rules, WebRTC policy, DNS-prefetch policy and Kill Switch configuration from the browser extension. A saved toggle is not proof that rules loaded, and a configured Kill Switch is not the same as a controlled traffic-drop test.
Privacy and limits
Run tests only when you choose. Do not submit passwords, one-time codes or private account data. A website test can observe its own browser requests; it cannot inspect every application, device interface or operating-system packet. Compare multiple independent signals and keep unresolved checks marked inconclusive.
