Advanced IP & DNS Leak Test: Check Your Network Security

Many users believe purchasing a "residential proxy" will completely disguise them as a typical home user. However, modern risk-scoring engines look far beyond static classification tags in GeoIP databases (such as IP2Location or MaxMind). Even when an exit IP is listed as an ISP/residential address, the forwarding proxy gateway almost always runs on a cloud-hosted Linux server, introducing stark cross-layer contradictions: First, transport protocol stack signatures: the exit server transmits Linux-standard TCP option ordering (MSS, SACK_PERM, TS, NOP, WS) during the initial SYN handshake rather than Windows or Apple options. Second, path MTU discrepancy: residential PPPoE connections usually exhibit an MTU of 1492 (or 1400–1430 on cellular), whereas bare datacenter Ethernet is standard 1500 (MSS=1460). When an anti-fraud system detects a residential IP accompanied by a datacenter MTU and a Linux TCP stack, it classifies the connection as an automated proxy.

💡 Test your connection with our Proxy Anonymity Test to see where your TCP terminates.

There is no fixed physical binding between an IP address and a physical geolocation. Location results depend on the commercial GeoIP database used by each site and its update cycle: First, database sources and telemetry models differ—providers (like MaxMind, IP2Location, DB-IP) weight BGP announcements, whois registry entries, and network latency probes differently, with refresh intervals ranging from days to months. Second, Anycast routing and CDN edge delivery: providers like Cloudflare announce the same IP block from hundreds of global datacenters, routing your packet to the closest edge colocation. Third, cross-border IP reassignments: when a hosting provider reallocates an IP block registered in one country to servers in another, outdated databases report the historical origin. Our tool combines multi-database cross-checks with physical RTT speed-of-light delay multilateration to verify actual physical regions.

An IP Fraud Score (or Risk Score) is a numeric index (typically 0 to 100) used by risk engines to quantify the likelihood that a connection originates from abusive, bot, or disguised activity. Core evaluation factors include: First, historical reputation and abuse lists: whether the IP has engaged in credential stuffing, scraping, spamming, or scanning within recent 24–72h windows. Second, ASN type and infrastructure: data center (hosting) and public proxy/VPN ranges carry higher baseline risk than residential broadband or mobile carriers. Third, multi-endpoint and protocol consistency: whether a session exhibits split dual-stack exits (IPv4 and IPv6 diverging), DNS resolver location divergence, or WebRTC local IP exposure.

💡 Use our Split Tunneling Test to identify routing leaks that might inflate your risk score.

Even with an active VPN or proxy, your real identity can leak through sideband channels: First, DNS Leaks: when your browser resolves hostnames, if the proxy software fails to capture OS-level DNS requests, queries go directly in the clear to your local ISP DNS server, revealing visited domains and true location. Second, WebRTC Leaks: WebRTC is a browser technology for real-time peer-to-peer media. When initiating connections, it bypasses HTTP/SOCKS proxy layers and sends UDP STUN packets directly, exposing your genuine local and public IP addresses. Our homepage tests your DNS exit and WebRTC state in real time.

💡 To check for hardware-level canvas, audio, and WebRTC leaks, visit the Browser Fingerprint Test.

The homepage network stack panel runs three related probes in parallel: one hits a domain with A records only (iptestv4.myipdns.com), one hits a domain with AAAA records only (iptestv6.myipdns.com), and the third hits a dual-stack domain with both record families. The first two are mandatory—each hostname resolves to only one address family, leaving your system no choice, thereby capturing your actual egress IP on IPv4 and IPv6 independently. The third probe is not forced; instead, it observes which address family your system selected on its own, which is shown in the "Preferred Protocol" column: this outcome is determined by your OS and browser address selection policy (Happy Eyeballs, RFC 8305: when dual-stack is available, try IPv6 first, falling back to IPv4 only on failure), not specified by us. Placing all three side-by-side is critical because many proxy and VPN clients only tunnel IPv4: if your IPv4 egress is on the proxy ASN while your IPv6 egress remains on your residential ISP, and the preferred protocol displays IPv6, then when visiting dual-stack websites most of your traffic never travels through the tunnel—this is the most common form of "VPN enabled yet real identity exposed", and it throws no errors whatsoever.

⚠ We can only tell you whether your dual-family egresses terminate in different networks; we cannot judge how your proxy software should be configured. Conversely, IPv6 showing as unavailable does not equate to safety; it may simply mean your network lacks IPv6, or that your proxy disabled IPv6 entirely—the latter is often the intended behavior.

We do not read your local system settings—browsers cannot read them at all, and any web page claiming to read your local DNS configuration is merely guessing. The real approach is to test in reverse: our site operates an authoritative DNS server, generating a unique random subdomain for each test (such as k3f9x2ab.leakv4.myipdns.com) for your browser to resolve. This hostname appears only once in history and will never exist in any cache, so your recursive resolution chain must query our authoritative server all the way back to the source; we record who actually made the query, and then return that address to your browser. Consequently, the "DNS Egress" column displays the actual outbound network address of your recursive resolver, not the upstream IP you entered in your system settings: if you set 8.8.8.8, the machine querying us will be a specific outbound node in that cluster, which may well reside in a different country; large public resolvers rely on anycast and clustering, so observing several different egress addresses in a single test is completely normal. The genuine criterion is not whether addresses match, but rather: if this egress falls within your own broadband ISP network while your IP egress terminates on a proxy—that signifies DNS queries failed to follow the tunnel.

⚠ This methodology can only observe who queried our own authoritative server; we cannot and do not see any other domains you resolve. There is also a known blind spot: if your proxy also intercepts DNS queries, what we observe is the proxy provider's resolver—confirming no leak to your local ISP, yet your DNS query log remains visible to your proxy provider; that is a separate consideration beyond what this tool detects.

Through WebRTC, single probes are dispatched to multiple STUN servers to collect returned srflx candidates—that is, the public IP and port actually observed by the remote server after NAT translation. There is only one decisive criterion: candidates are grouped by translated public IP; if two or more distinct ports appear under the same IP, it is classified as Symmetric NAT (assigning a new mapped port for each distinct destination); otherwise, it is classified as Cone NAT (consistently mapping the same internal port to the same external port). Grouping candidates before comparing ports was deliberately introduced: in split-tunnel proxy environments, different STUN servers may route through different egresses, naturally causing ports to diverge; however, this divergence stems from path differences rather than NAT behavior, and omitting grouping would misdiagnose all such setups as Symmetric. Displaying "Unknown" has two causes: first, failing to receive any srflx candidate within the 4-second timeout (WebRTC disabled in browser, blocked by extensions, or outbound UDP filtered); second, receiving only a single candidate whose public IP does not match the ingress IP used to access this site, making it impossible to distinguish browser candidate deduplication from traffic routing splits, so we deliberately display unknown.

⚠ Honest clarification: we only distinguish between Cone and Symmetric NAT, and do not sub-classify into Full Cone, Restricted Cone, or Port-Restricted Cone. The RFC 3489 four-tier model requires actively controlling combinations of source ports and destination targets across repeated probes, and WebRTC in browsers provides no such low-level control; when web-based tools report one of the four categories, they are usually just relabeling these two outcomes.

A single inspection on the homepage issues six probes in parallel, each targeting distinct domains: one purely IPv4, one purely IPv6, two gathering protocol stack fingerprints over IPv4 and IPv6 respectively, one hitting a dual-stack domain to observe which family your system prefers, and one dedicated probe enforced over HTTP/1.1. These are not duplicate requests; each probe collects entirely different telemetry. Separating them is necessary because our diagnostic logic relies on cross-layer correlation: a single device exhibits distinct protocol stack signatures across IPv4 versus IPv6, and across HTTP/1.1 versus HTTP/2 (and HTTP/3 when available), and these characteristics can only be compared once captured individually. Furthermore, parallelism is not for speed: if executed serially, an intermediate network switch, proxy toggle, or tunnel reconnect would stitch together telemetry from a non-existent hybrid machine; parallel execution ensures all six probes observe the exact same network path at the exact same instant. Among them, the HTTP/1.1 probe intentionally sends only a single request—HTTP/1.1 lacks an HPACK dynamic table, so additional requests yield no extra entropy, while a single request guarantees captured headers map strictly to the same observation record.

⚠ The trade-off is connecting to multiple subdomains upon initial load, which ad blockers or strict privacy extensions occasionally intercept. In such cases, the corresponding indicator shows a gray dot and remains in an unknown state; we will never backfill values from other probes to forge an apparently complete result.