Precise description of each check: how it works, evidence collected, what may affect results, and what we do not test.
Last reviewed: October 2026
1. Public IP and Network Metadata
ActiveEndpoint: GET /api/ip-infoRuntime: Cloudflare Workers
How it works
When a request reaches the Cloudflare Worker, Cloudflare injects request metadata headers containing the client's connecting IP address and approximate network information. The /api/ip-info endpoint reads these headers and returns them as JSON.
Headers used:
cf-connecting-ip — Client's public IP address
cf-ipcountry — ISO 3166-1 alpha-2 country code
cf-ipregion — Region/state code (where available)
cf-ipcity — City name (where available)
cf-asn — Autonomous System Number
cf-as-organization — Network organization name
Evidence collected
The response includes the observed IP, IP version (4 or 6), country code, region, city, ASN, network organization, timestamp, and source identifier. No precise coordinates are returned even if available.
VPN/proxy exit IP registration location vs. physical server location
IPv6 vs IPv4 — some networks prefer one over the other
Local development — Cloudflare headers are not present, so the endpoint returns a development notice
What we do NOT test
Your precise physical location (GPS, Wi-Fi triangulation)
Whether the IP belongs to a VPN provider vs. hosting company
Your ISP's internal routing or customer assignment
Historical IP reputation or abuse records
Limitation statement
IP geolocation is approximate and may identify an ISP/VPN exit region rather than your physical location. Network details depend on Cloudflare edge metadata availability. The ASN shows the network operator, which may be a hosting provider rather than your commercial VPN service.
2. HTTPS Round-Trip / Endpoint Reachability
ActiveEndpoint: GET /api/healthClient-side: performance.now()
How it works
The browser performs up to 3 sequential HTTPS GET requests to /api/health with cache bypass (cache: 'no-store'). Each request is timed using performance.now() before and after the fetch. The median of successful samples is reported.
Each sample includes: DNS resolution (if not cached), TCP connection, TLS 1.3 handshake, HTTP request/response. The server responds with Cache-Control: no-store, private, must-revalidate to prevent caching.
Evidence collected
Median round-trip time in milliseconds, number of successful samples, and timestamp.
Browser connection pooling and HTTP/2/3 multiplexing
Local firewall or antivirus TLS inspection
What we do NOT test
ICMP ping (different protocol, often different path)
Geographic latency to a specific city (we only test to our endpoint)
Bandwidth/throughput (no data transfer beyond tiny JSON)
Jitter, packet loss, or connection stability over time
Limitation statement
This measures HTTPS round-trip time to the MyVPNCheck endpoint, including TLS handshake and server processing. It is not an ICMP ping or pure geographic latency measurement. The first request includes connection establishment overhead; subsequent requests may benefit from connection reuse.
3. WebRTC Candidate Inspection
ActiveClient-side: RTCPeerConnectionSTUN: Google (configurable)
How it works
The browser creates an RTCPeerConnection configured with STUN servers (Google's by default, configurable via PUBLIC_STUN_SERVER_URL). A data channel is created to trigger ICE candidate gathering. The browser contacts the STUN server, which reflects the public-facing IP and port. All ICE candidates are collected until the gathering completes or an 8-second timeout elapses.
Candidates are parsed and classified by type: host (local), srflx (server-reflexive/public), prflx (peer-reflexive), relay (TURN). Only srflx candidates with publicly routable addresses are compared to the HTTP public IP.
Evidence collected
All ICE candidates (type, protocol, address, port, priority, foundation)
Public srflx candidates extracted
Any public addresses differing from HTTP IP
STUN server used, completion status, timeout status
DNS leaks (requires authoritative DNS infrastructure)
WebRTC data channel actual media flow
TURN/relay candidate behavior (not configured)
Limitation statement
Results apply only to this browser's WebRTC configuration. Modern browsers may mask local IPs with mDNS names. The test uses a STUN server which receives connection metadata. Other applications on your device may behave differently. A clean test in one browser does not prove other browsers or system traffic aren't leaking.
4. IPv4 / IPv6 Reachability (Not Implemented)
Unavailable
Requires dedicated family-specific test endpoints that are provably reachable only over IPv4 or only over IPv6 at the network layer. A dual-stack URL behind a CDN proxy is insufficient because the edge accepts either family. This check will be implemented only when genuine infrastructure is verified.
5. DNS Leak Test (Not Implemented)
Unavailable
A true DNS leak test requires a unique per-scan hostname/token under a domain whose authoritative nameserver can observe the recursive resolver query. Without controlled authoritative DNS infrastructure, any "DNS leak test" would be unreliable. This check will be implemented only when the backend is deployed and verified.
VPN Detection, Protocol & Provider Claims
This website does not claim it can definitively detect an active VPN, its exact protocol, kill-switch status, or provider logging behavior from a normal browser visit. IP intelligence inference may be added later with source, timestamp, update strategy, and confidence/limitations disclosed. We will not hard-code a list of "VPN IPs" and present it as authoritative.
The network organization/ASN observed by this site is the hosting/network operator, which may differ from the commercial VPN service a person pays for. Many VPNs share infrastructure (AWS, DigitalOcean, etc.).