TrueProxiesFree Trial

Free Tool

IP Leak Test: Check IPv4, IPv6, WebRTC, and DNS

What network signals can this browser expose?

Run the test once on your direct connection, save that result as the baseline for this tab, change your route, and run it again. The comparison identifies route-bypass evidence and separates ambiguous signals from verified leaks.

IPv4 Address

Waiting

Run the test to detect your IPv4 address.

IPv6 Address

Waiting

Run the test to detect your IPv6 address.

WebRTC Leak

Waiting

Run the test to check for WebRTC leaks.

DNS Leak

Waiting

Run the test to check for DNS leaks.

Transparent methodology

How This IP Leak Test Works

This is a browser-route comparison, not an anonymity certificate. It measures separately observable network signals, records incomplete evidence as unavailable or inconclusive, and treats only an exact direct-baseline match or a verified WebRTC route outside the visible browser route as a leak indicator.

Test version
2026.07.18
Last reviewed
Technical reviewer
Aseel Ashraf

Before-and-after baseline workflow

A route change is meaningful only when it is compared with known direct-connection evidence from the same browser session.

  1. Measure the direct route

    Without the proxy or VPN route you want to evaluate, run a complete test and review the IPv4, IPv6, WebRTC, and DNS evidence.

  2. Save the current result

    Choose “Use Current as Baseline.” The detected public IPs and DNS resolvers remain only in this page’s in-memory state for the current tab; reloading or leaving the page clears them.

  3. Change only the intended route

    Enable the proxy, VPN, or other routing configuration while keeping the same browser and tab. Changing several variables makes the comparison harder to interpret.

  4. Run the same checks again

    An exact public-IP or WebRTC match with the saved direct baseline is leak evidence. Missing data, an unverified alternate route, or DNS geography alone remains inconclusive or Review.

Signals and measurement providers

These external services receive the requests required to measure each channel. A provider failure is reported as missing or inconclusive evidence, never converted into a passing result.

Network signals, providers, and their role in this IP leak test
SignalProviderHow it is used
Public IPv4 and IPv6ipifyReturns the public address used by each address-family request.
IP location and network ownershipIPinfo and GeoJS · GeoJS documentationIndependently enrich public addresses. ASN ownership is treated as verified only when both sources agree; location remains an estimate.
WebRTC ICE candidatesBrowser WebRTC with Google public STUNCreates an RTCPeerConnection and gathers candidates through stun.l.google.com and stun1.l.google.com. The test does not open a camera or microphone stream.
DNS resolver evidencebash.ws authoritative DNS testLoads unique probe hostnames and retrieves the resolvers observed for that fresh session together with the public route used to request the result.

Classification rules

The tool distinguishes a verified leak from a signal that needs review. “Unavailable” means the channel could not be verified; it does not mean safe or leaked.

Rules used to classify IPv4, IPv6, WebRTC, DNS, and the overall result
ChannelNo indicatorReview / unavailableLeak detected
IPv4 / IPv6A public address was detected and it does not match the same-family address in the saved direct baseline.A family is missing, blocked, or could not be enriched. Different IPv4 and IPv6 addresses are normal and are not compared to each other.A detected public address exactly matches the saved direct baseline for that address family.
WebRTCCompleted ICE gathering exposed a valid public candidate already present in the visible browser route and no saved-baseline address.ICE was incomplete, blocked, private-only, malformed, or returned an alternate address whose ownership could not be verified. A different address on the same independently verified ASN is also Review because one service can use multiple exits.A public candidate matches the saved direct baseline, or a same-family candidate belongs to a different ASN after IPinfo and GeoJS independently agree on ownership.
DNSA complete, stable authoritative session reports resolver locations consistent with the verified public-IP country and no saved-baseline resolver.A resolver matches the saved baseline, its country differs, ownership/location is missing, the probe route changed, or the probe route did not match the visible route. These signals do not by themselves prove a DNS leak.This version does not label DNS evidence alone as a verified leak because public resolvers, anycast, and geolocation error prevent identity-level attribution.
Overall resultBoth public address families, WebRTC, DNS, and any saved baseline produced complete evidence with no leak indicator.At least one channel is unavailable, incomplete, or ambiguous. A confirmed public-IP or WebRTC leak still takes precedence over an incomplete channel.A visible public address matched the saved direct baseline, or WebRTC produced verified leak evidence.

Privacy handling

  • The result is assembled in your browser. This tool does not submit a completed test report to TrueProxies.
  • The saved baseline is held in memory for the current page and tab. It is not persisted by the tool after a reload or navigation.
  • The measurement providers receive the requests required to observe an address, candidate-supporting STUN exchange, geolocation lookup, or DNS probe. Their own privacy and retention terms apply.
  • Public IP addresses and resolver addresses are shown on screen because they are the evidence being compared. Mask them before posting a screenshot or sharing a report.

Browser and OS coverage

Public IP checks
Requires JavaScript, HTTPS fetch support, provider CORS access, and working IPv4 or IPv6 connectivity. A blocked request is indistinguishable from an unavailable address family in browser-only code.
WebRTC checks
Requires RTCPeerConnection and completed ICE gathering. Browser privacy settings, managed policies, extensions, mDNS masking, firewalls, and UDP restrictions can reduce or block evidence.
DNS checks
Requires unique probe images and the bash.ws result endpoint to be reachable. Content blockers, secure-network policies, caching layers, or rotating exits can make the session unavailable or inconclusive.
Browsers and operating systems
The capability-based checks are intended for current Chrome, Edge, Firefox, and Safari on desktop and mobile. This page does not claim a certified browser/OS matrix; browser and operating-system routing policies can differ by version and configuration.

Limitations

  • A clean result covers only the signals available to this run. It does not prove anonymity, prevent fingerprinting, inspect every application on the device, or verify traffic outside this browser tab.
  • IP geolocation is approximate. A city or country mismatch can reflect stale data, ISP routing, a public resolver, or anycast rather than a route leak.
  • A standard HTTP proxy may carry browser HTTP traffic without carrying WebRTC, operating-system DNS, or every IPv6 path. The exact behavior depends on the browser, operating system, proxy protocol, and client configuration.
  • Rotating and multi-egress services can legitimately expose different addresses during one run. Alternate addresses remain Review unless direct-baseline or independently verified network evidence satisfies the leak rule.
  • Provider outages, rate limits, content-security policy, extensions, and network filtering can remove evidence. Unavailable means unverified, not safe and not leaked.

Standards and provider references

Understanding IP Leaks

What Is an IP Leak?

An IP leak is evidence that a direct public address remained visible despite an intended proxy or VPN route. This test can verify that evidence when an address matches a saved direct baseline or WebRTC exposes a different, independently verified network. DNS geography, city labels, and missing results require more caution and are not identity proof.

Leak Types

Common Browser Route Signals

Interpret each channel separately before deciding whether a route bypass occurred.

WebRTC Route Bypass

WebRTC gathers connectivity candidates separately from ordinary page requests. A candidate that matches the saved direct baseline, or belongs to a verified different network from the visible same-family route, is leak evidence. Other alternate addresses remain Review.

DNS Resolver Mismatch

A resolver outside the route you expect can be worth investigating. Resolver geography or ownership alone cannot prove a leak because public DNS, anycast routing, rotating exits, and geolocation errors can produce legitimate differences.

IPv4 or IPv6 Bypass

A client can route one address family differently from the other. The decisive comparison is whether a detected IPv4 or IPv6 address matches the saved direct baseline for that same family; merely seeing both families is normal.

Route boundaries

Where Browser Routes Can Diverge

A proxy carries only the traffic that the application sends through it. Browser WebRTC, DNS resolution, and IPv6 behavior depend on the browser, operating system, proxy protocol, and client configuration. Measure each channel explicitly instead of assuming one successful HTTP request represents every network path.

Investigate signals

What to Do If You See a Leak Indicator

  1. 1Confirm that the saved baseline came from the direct connection you intended to compare and that you remained in the same browser tab.
  2. 2Identify the exact channel: a direct-baseline IPv4/IPv6 match and verified WebRTC bypass are stronger evidence than DNS location or an unavailable result.
  3. 3Review the browser, operating-system, proxy protocol, and client routing settings for that channel, then change one variable at a time.
  4. 4Repeat the same before-and-after comparison. Do not treat Review or Unavailable as proof that the route is fixed.
  5. 5When requesting support, provide the browser/OS, client, protocol, test version, time, and masked evidence; do not post credentials or full public addresses.

Evidence library

Focused leak-test guides and original route evidence

Use the focused guides to investigate one network channel, then compare the four anonymized route observations with your own baseline. The case series is evidence from one recorded session, not a population benchmark.

WebRTC leak test guide

Read ICE candidates, distinguish public routes from private or mDNS evidence, and investigate browser-proxy bypass.

Read the evidence

DNS leak test guide

Interpret authoritative resolver observations without turning anycast or country mismatches into false leak claims.

Read the evidence

IPv6 leak test guide

Compare IPv4 and IPv6 separately and test whether an IPv4-only route leaves the direct IPv6 path visible.

Read the evidence

Proxy vs VPN route guide

See why an application proxy, WARP, and a full-device VPN can cover different browser traffic paths.

Read the evidence

Browser route case series

Review four anonymized direct, WARP, and proxy observations with downloadable CSV and JSON evidence.

Read the evidence

FAQ

Frequently Asked Questions

Common questions about IP leak testing and proxy security.

What is an IP leak test?

This browser check compares public IPv4 and IPv6 routes, WebRTC candidates, and DNS resolver evidence. An exact saved-baseline match or independently verified WebRTC route bypass is a leak indicator. DNS geography and missing results remain diagnostic signals, and the tool cannot prove anonymity.

How does WebRTC leak detection work?

The tool creates a test RTCPeerConnection without opening camera or microphone media and examines completed ICE evidence. An exact visible-route match has no indicator. A direct-baseline match or independently verified different network is a leak indicator; another same-family address on the same verified ASN stays Review. Empty, blocked, malformed, or incomplete evidence is Unavailable.

Is this IP leak test free?

Yes, the page requires no signup. Checks run in your browser and contact third-party IP, geolocation, STUN, and bash.ws authoritative DNS services. Those providers receive the requests needed to measure the route. The completed test report is not submitted to TrueProxies by this tool.

Why does my IP show a different city than where I am?

IP geolocation is an estimate. ISP routing, anycast infrastructure, provider updates, and database errors can place an address in a different city or country. A location label by itself does not establish a leak.

What should I do if a leak is detected?

Confirm the direct baseline, identify whether the evidence came from IPv4, IPv6, or WebRTC, and review the relevant browser/client route. Change one setting at a time and repeat the same comparison. Treat DNS mismatches and unavailable channels as Review rather than automatic proof.

Can a website tell that I am using a proxy?

A website may evaluate IP ownership or reputation, request headers, TLS and browser characteristics, account history, and behavior. This IP leak test measures route exposure only; it does not test whether a site classifies an address as a proxy or whether a session is anonymous.

Bloggers

Link to This Tool

Help readers compare their browser route with a direct baseline. Copy this HTML to link to the test.

<a href="https://trueproxies.com/tools/ip-leak-test/" title="IP Leak Test by TrueProxies">IP Leak Test — Check IPv4, IPv6, WebRTC &amp; DNS</a>

Verify Your Route

Need a proxy route you can test?

Test TrueProxies on your actual client and targets, then compare browser-visible IPv4, IPv6, WebRTC, and DNS signals against your direct baseline.

View Pricing