DEV Community

ricco020
ricco020

Posted on • Originally published at anonymflow.com

I built 5 free VPN diagnostic tools — here's what most online testers miss

#privacy #vpn #security #webdev

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:

  1. Generate 20 random subdomains (32-char nonces).
  2. Query each domain through the user's browser.
  3. Log which resolver answered each query (server-side, with the user's nonce).
  4. 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:

  1. Public IP via STUN — RTCPeerConnection.createOffer() triggers STUN binding requests that can bypass VPN routing.
  2. Local IP — reveals your LAN topology even with VPN active.
  3. mDNS IP — Chromium tries to mitigate #2 by reporting .local mDNS 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.

Top comments (0)