CONNECT
We probe your connection through 6 leak channels simultaneously.
24 checks. 10 seconds. Zero trust.
24-point VPN security audit
We probe your connection through 6 leak channels simultaneously.
eBPF captures your TCP fingerprint, TLS signature, and tunnel overhead.
We compare 24 signals against expected VPN tunnel patterns.
See your VPN's ranking among community test results.
Three checks. DNS leak, WebRTC leak, maybe an IPv6 ping. Green checkmark. "Secure." That checkmark isn't lying exactly. It answered the three questions it was asked and ignored the other eighteen. Like a doctor who takes your blood pressure, skips the bloodwork, and tells you you're healthy. A VPN can fail eighteen distinct ways while acing those three tests. Kill switch that races during reconnect, leaking raw traffic for 200 milliseconds. DHCP option 121 silently rerouting packets around your tunnel while the client shows a padlock. TLS fingerprints ratting out your real OS behind a spoofed User-Agent. MTU values that might as well wear a sign reading "tunnel." Catching the full picture means server-side instrumentation: eBPF on the receiving edge, JA4 and JA4H fingerprinting, per-protocol probing across UDP, QUIC, DoH, DoT, and IPv6 at the same time. Twenty-four signals minimum. In our testing most VPNs clear twenty. A handful scrape twenty-three. Two have passed all twenty-four, and one of those was a niche provider with twelve thousand users and zero marketing budget.
Standard VPN tester poses three questions. IP match the exit? DNS resolver match? WebRTC candidates clean? Full marks. Turns out you covered roughly a third of what actually breaks in production. IPv6 punches the first hole. Most consumer VPNs tunnel IPv4 only. ISP hands you an IPv6 prefix, your OS uses it by default (Windows, macOS, Linux, mobile, every last one of them), and every IPv6-capable site gets your real address. The VPN client sits there clueless. That traffic never grazed the tunnel. Roughly 45% of internet users have IPv6 connectivity now. Around 30% of consumer VPNs handle it. Do that arithmetic and sit with the number for a second. QUIC is sneakier. HTTP/3 runs over UDP. Some VPN configurations block UDP entirely, forcing TCP fallback. Others wave it through for performance gains. When your tunnel doesn't wrap UDP, the browser's HTTP/3 requests leave the building unwrapped. Chrome and Firefox both prefer HTTP/3 when a server offers it. That preference quietly routes around your protection. No warning. No dialogue. Nope. Encrypted DNS pulls the same trick one layer up. Firefox shipped DoH by default in the US back in 2018. Browser talks to Cloudflare 1.1.1.1 over port 443, application-layer encrypted, completely bypassing the VPN's leak protection that hooks into the OS resolver. You pass the DNS leak test. Your queries still leak. A passing grade on an exam that checked the wrong syllabus. Wire-level fingerprints dig deeper. VPN tunnels trim 40 to 100 bytes off the MTU depending on protocol. WireGuard sits around 1420, OpenVPN near 1450, IPsec at 1438. Server-side eBPF grabs those values in microseconds, zero JavaScript involvement. TCP stack signatures (window scaling, MSS, ECN flags) betray the originating OS. Claim Windows in your headers, ship Linux TCP options, and you've got a contradiction a machine spots before a human finishes reading the hex dump. JA4 seals it. Hashes the TLS ClientHello: cipher suites, extensions, supported groups, ALPN. Stable across browser versions for the same engine. Spoof your User-Agent all day long. JA4 won't flinch. Anti-detect browsers carry JA4 values that diverge from real Chrome on real Windows. JA4H does the same trick for HTTP/2 frame ordering. Both became standard in commercial detection stacks around 2024. Three-check testers don't touch either one.
Two attack classes that nail even careful users. Unrelated to each other, both invisible to any test that takes a single snapshot. Kill switch race conditions first. Every VPN client ships some form of kill switch: tunnel drops, traffic stops. Theory is clean. Practice? Straight up tire fire. Mullvad and ProtonVPN firewall all non-tunnel traffic at the OS kernel level. Most consumer clients? They pause at the application layer. A few only kick in on full disconnect and miss brief hiccups during renegotiation entirely. The reconnect window is where it bleeds. Tunnel goes down for 200ms during key exchange. Background services, Dropbox sync, OS update probes, password manager heartbeats, they all slam the network the instant connectivity flickers back. If the kill switch hasn't locked down in those 200 milliseconds, that burst exits from your real IP. A point-in-time test will never see this because you're connected when you click "check." Catching it needs 60 seconds of continuous session capture. Like diagnosing an intermittent engine knock by revving it once in the parking lot: you won't hear the rattle that shows up at highway speed. TunnelVision is worse. CVE-2024-3661, disclosed by Leviathan Security Group in May 2024. Uses DHCP option 121 to inject classless static routes that funnel specific destinations outside the tunnel. Attacker runs a rogue DHCP server on the same WiFi (coffee shop, hotel lobby, coworking space), your machine accepts the lease renewal, applies the routes, and traffic to chosen targets now bypasses the VPN. Tunnel stays up. Client shows connected. Kill switch stays asleep because nothing technically disconnected. Same principle as someone filing a postal redirect in your name: mail still goes "home," just stops at a different door. Linux clients running in a network namespace? Immune. Android? Mostly immune, different routing architecture. Windows, macOS, iOS, standard Linux without namespace isolation? All exposed unless the provider shipped an explicit patch. By mid-2025 Mullvad and ProtonVPN had fixes out. The kicker: most others either ignored the CVE, called it "not our bug" (routing-table issue, technically accurate), or pushed half-measures that the r/VPN crowd dismantled within a week. A 2026 audit probes for TunnelVision susceptibility. Three-check testers haven't caught up.
Network-level auditing catches VPN tunnels pretty well. Residential proxies? Not even close. And that's architectural, not a shortcoming we can engineer around. A residential proxy routes your traffic through someone's actual home connection. Exit IP belongs to a Comcast or Deutsche Telekom subscriber. ASN reads residential. MTU matches standard home router values. TCP stack is whatever laptop the homeowner runs. JA4 looks like regular Chrome because it is regular Chrome, on a real machine, in a real apartment. From the wire, this request came from a normal person in a normal house. Because at the network layer it literally did. Trying to spot the difference is like authenticating a painting by analyzing the canvas weave: a skilled forger sources the same Belgian linen. The supply chain goes: your request hits the proxy provider (Bright Data, Oxylabs, IPRoyal, NetNut), bounces through a residential device enrolled via "monetization" apps like HoneyGain, exits from that person's home IP. The providers pitch it as ethical opt-in. Whether every node in those networks volunteered enthusiastically, honestly, murkier question, especially after 911.re got seized and its enrollment practices made the news. For any detection system built on ASN lookups, IP reputation databases, and network fingerprinting, residential proxies are the architectural ceiling. The wire says "residential, clean, unflagged" because that's the literal network truth. Telling a proxy user from someone browsing from their kitchen takes behavioral signals: mouse dynamics, session cadence, account age. Those belong to the website operator. Not a network probe. Not us. The audit flags this boundary honestly. Residential IP, consistent home-network fingerprint, no anomalies? That's the correct finding. Could be a proxy. Could be someone's living room. The data that would settle it lives somewhere we can't reach and shouldn't pretend to.
We test 24 signals vs 3. We detect VPN protocol, not just IP.
Yes, they can see you visited whox.com. The security checks are passive network analysis. The speed test actively downloads/uploads data through your VPN tunnel.
VPN detection does not equal VPN failure. Websites can detect VPN; your traffic is still encrypted.
VPN tunnels add overhead, reducing packet size. This is invisible to you but visible to servers.
We need 50+ community tests. Test and report your VPN to help build the database.
Run the full WHOX toolkit from one place: leak checks, fingerprint probes, network diagnostics, reputation lookups, and privacy failure tests.