TL;DR
I built and published 5 free VPN diagnostic tools on AnonymFlow. The methodology behind them — what they measure, why it matters, what other "VPN testers" miss — is below. All measurements happen 100% in your browser; nothing is logged on a server.
→ Try them: anonymflow.com/en/tools
The 5 tools and what they check
| Tool | What it measures | Why it matters |
|---|---|---|
| My IP | Public IPv4 + IPv6 + ASN + geolocation accuracy | Confirms which exit a website actually sees |
| DNS leak test | Resolver IP via OpenDNS echo trick + 20 random subdomains | Detects round-robin smart-DNS bypasses that standard tests miss |
| WebRTC leak test | STUN-derived public/local/mDNS IPs | Catches the 6-month silent leak ~70% of VPN users have without knowing |
| VPN speed test | Browser-to-server iperf-like measurement | Real-world bandwidth in your actual conditions, not a marketing claim |
| Geo-blocking probe | Detected country from HTTP headers + IP geolocation | Reveals what catalog Netflix/Disney/BBC will show you |
Why most "VPN testers" are broken
Most online VPN leak testers do one DNS lookup against a domain they control. If you happen to use the same resolver, false positive. If you use DoH, false negative.
The fix is the extended DNS leak protocol I document here:
- Generate 20 random subdomains (32-char nonces).
- Query each domain through the user's browser.
- Log which resolver answered each query (server-side, with the user's nonce).
- Cross-reference: if all 20 queries answered from the VPN provider's DNS infrastructure → no leak. If even one query came from a different ASN → leak.
This is the only way to detect:
- Smart DNS that forwards some queries to the ISP (~15% of consumer VPNs do this for streaming compatibility)
- DoH bypasses that resolve through Cloudflare/Google directly, ignoring the VPN tunnel
- OS-level resolvers (systemd-resolved, Android's connectivity service) that bypass the VPN's DNS
The WebRTC leak you probably have
WebRTC has three leak vectors, and most browser extensions only fix one:
-
Public IP via STUN —
RTCPeerConnection.createOffer()triggers STUN binding requests that can bypass VPN routing. - Local IP — reveals your LAN topology even with VPN active.
-
mDNS IP — Chromium tries to mitigate #2 by reporting
.localmDNS hostnames, but those hostnames are themselves a fingerprinting vector.
uBlock Origin's "Disable WebRTC" toggle fixes #1 and #2. It does not fix #3 on Chromium browsers — and Chromium ~70% market share means most "VPN-protected" users still leak via mDNS.
What I built differently
The AnonymFlow tools run 100% client-side (no server-side logging, no tracking pixels, no analytics IDs). The DNS leak test does require a server (to log which resolver hit which nonce) but the log is rotated every 24h and never tied to a user account.
Source code: all available on GitHub (webrtc-leak-detector npm, dns-leak-detector-cli).
The deeper "why this matters" question
VPN providers love performative trust signals: "no-logs audited", "anonymous payment", "based in Panama". These are real, but they're 3% of the picture.
The other 97%:
- The browser you use leaks more than the VPN exit.
- The OS resolves DNS in ways the VPN client doesn't always intercept.
- The WebRTC API is older than the modern VPN industry and was never designed for privacy.
A 5-minute diagnostic on your own setup tells you more than a 50-page audit report about a VPN provider you've never met.
Reproduce / contribute
If you find a leak vector my tools miss, open an issue on GitHub. If you want to integrate the methodology into your own audit, the VPN leak audit protocol is documented in 12 steps with reproducible criteria.
This is the dev-focused condensation. The 5 tools themselves are at anonymflow.com/en/diagnostic-tools — no signup, no ads, no logs.