A VPN that appears to be working is not the same as a VPN that is actually protecting you. Millions of people connect through virtual private networks every day under the assumption that their traffic is hidden, their identity masked, and their data sealed - only to discover, on closer inspection, that DNS queries are slipping through unencrypted, that IPv6 traffic bypasses the tunnel entirely, or that a browser's WebRTC feature is broadcasting their real IP address to any website that asks. The gap between perceived privacy and actual privacy is wider than most users expect, and closing it requires more than choosing a reputable provider and pressing connect.
The Leaks Nobody Warns You About
The three most common failure points in a standard VPN setup are DNS leaks, IPv6 leaks, and WebRTC exposure - and they can occur even on paid, well-regarded services. When your device sends a DNS query - the lookup that translates a domain name into an IP address - that request does not always travel through the VPN tunnel. If it exits through your regular internet connection, your ISP or any observer on the network can see exactly which sites you are visiting, regardless of the VPN. Testing at a site like dnsleaktest.com takes under a minute and frequently produces unwelcome results.
IPv6 is a parallel problem. Most VPNs were built around IPv4 and either ignore or incompletely handle IPv6 traffic. If your device has an IPv6 address assigned by your ISP - and most modern devices do - that address can leak outside the tunnel. The fix is to disable IPv6 at the operating system level: on Windows via the command line, on macOS through network preferences, on Linux through kernel parameters. It is a crude solution, but it is reliable. WebRTC, a browser technology used for real-time communication in applications like video calls and some chat platforms, poses a separate risk: it can establish direct connections that bypass proxy and VPN configurations entirely, exposing your real IP to any site or service that triggers it. Disabling it in Firefox requires one configuration change; in Chromium-based browsers, an extension is the practical option. Running a combined leak test at ipleak.net after any configuration change should be standard practice.
Protocol Choice and Kill Switch Reliability Matter More Than Brand
Many VPN applications default to OpenVPN or IKEv2. Both are mature, audited protocols - but WireGuard, a newer alternative, offers a substantially smaller codebase, which means a smaller attack surface and faster independent security audits. It is also significantly faster in most real-world conditions, a difference that becomes noticeable on mobile connections or when routing large volumes of traffic. WireGuard is now supported natively by several major providers, including Mullvad, IVPN, and ProtonVPN. For providers that do not offer it through their own applications, WireGuard's official client can import configuration files directly.
Kill switches deserve equal scrutiny. The concept is straightforward: if the VPN connection drops, all internet traffic should stop immediately, preventing any data from traveling unprotected. In practice, implementation varies considerably. Some kill switches operate at the application level and are slow to react, allowing a brief window of unprotected traffic during reconnection. Others operate at the firewall or network interface level and are far more robust. On Linux, custom iptables rules offer precise control. On Windows, firewall rules can be configured to block all traffic except through the VPN interface. The meaningful test is not whether the kill switch exists - it is whether it holds when the VPN connection is deliberately interrupted.
Advanced Configurations for Specific Threat Models
Split tunneling - routing only selected applications through the VPN while others connect directly - is a useful feature that is frequently misconfigured. The default in many applications excludes certain apps from the VPN, which is the opposite of what most privacy-conscious users want. The more defensible approach is to route only the applications that genuinely require protection through the tunnel, while leaving bandwidth-intensive or latency-sensitive traffic on the direct connection. This requires either a provider with granular split-tunneling controls or a third-party routing tool on desktop systems.
For users in countries where VPN traffic is actively detected and blocked - including those operating under restrictive national filtering systems - obfuscation is not optional. Standard VPN protocols produce traffic patterns that deep packet inspection can identify. Obfuscated protocols disguise VPN traffic to resemble ordinary HTTPS, making it significantly harder to detect and block. ProtonVPN's Stealth protocol and similar implementations from other providers address this directly. Open-source tools like Shadowsocks serve the same purpose and can be configured independently of any commercial service.
Multi-hop routing - passing traffic through two VPN servers in sequence rather than one - adds a meaningful layer of separation between the user and their traffic. If one server is compromised or compelled to log, the chain is not immediately broken. The tradeoff is latency and some reduction in throughput, which makes it a proportionate measure for journalists, activists, or anyone operating under elevated surveillance risk rather than a default recommendation for general use. Dedicated IP addresses - a fixed IP assigned exclusively to one account rather than shared across many users - solve a different problem: shared IPs on commercial VPNs are sometimes flagged by banking systems or streaming platforms as suspicious, because many people are connecting from the same address simultaneously.
The Operational Discipline the Technology Cannot Replace
No configuration eliminates risk if the underlying habits are careless. Rotating server connections between sessions reduces the predictability of your traffic pattern. Keeping VPN client software updated ensures that known vulnerabilities are patched. And for users managing sensitive workflows, containerizing network-dependent applications - running a torrent client or browser inside a Docker container that routes exclusively through the VPN interface - provides isolation that protects the host system even if the contained application is compromised.
The broader point is that privacy tools require maintenance. A VPN is not a product you configure once. Protocols improve, leaks emerge, providers change ownership, and threat models evolve. Treating periodic review of your setup as routine rather than exceptional is what separates a security posture that holds from one that merely appears to.
