Skip to content
Language: EN
EnglishالعربيةРусский中文Tiếng Việt
Start trialDashboard
Start 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, a WebRTC address on a different network from the visible browser route, or a DNS resolver on the saved direct connection’s network as a leak indicator.

Test version
2026.10.01
Last reviewed
Technical reviewer
John Hale

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, and so is a DNS resolver on the direct connection’s network. 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 used when the sources that answer agree and is discarded when they conflict; location remains an estimate.
WebRTC ICE candidatesBrowser WebRTC with Google and Cloudflare public STUNCreates an RTCPeerConnection and gathers candidates through stun.l.google.com, stun1.l.google.com, and stun.cloudflare.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, or the visible IPv4 and IPv6 addresses belong to different networks or countries. Different addresses on one network are normal.A detected public address exactly matches the saved direct baseline for that address family.
WebRTCICE gathering finished, or went quiet after a public candidate arrived, and every public candidate is already in the visible browser route with no saved-baseline address. A browser that turns WebRTC off or returns no candidates at all also shows no indicator.ICE was incomplete, blocked, private-only, malformed, or returned an alternate address whose network could not be identified. A different address on the same ASN is also Review because one service can use multiple exits.A public candidate matches the saved direct baseline or belongs to a different ASN from the visible route. When the visible route has no address in the candidate’s family, the other family’s network is compared.
DNSA complete, stable authoritative session reports resolvers in the verified public-IP country, or abroad on a network that also answered from that country in the same session (public DNS pools span countries), and no saved-baseline resolver.A resolver matches the saved baseline, sits in another country on a network that did not also answer from the visible country, has no known owner or location, the probe route changed, or the probe route did not match the visible route. These signals do not by themselves prove a DNS leak.A resolver belongs to the same ASN as the saved direct connection while the visible route uses another network. Resolver geography alone is never labeled a leak because public resolvers, anycast, and geolocation error prevent identity-level attribution.
Overall resultAt least one public address family, WebRTC, DNS, and any saved baseline produced complete evidence with no leak indicator, and IPv4 and IPv6, when both appear, use the same network.At least one channel is unavailable, incomplete, or ambiguous. A confirmed leak in any channel still takes precedence over an incomplete channel.A visible public address matched the saved direct baseline, WebRTC produced verified leak evidence, or DNS used a resolver on the saved direct connection’s network.

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 ICE gathering that finishes, or goes quiet after a public candidate. 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, WebRTC exposes a different network, or DNS uses a resolver on the direct connection’s 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 different network from the visible route, is leak evidence. Other alternate addresses remain Review.

DNS Resolver Mismatch

A resolver outside the route you expect can be worth investigating. A resolver on the network of your saved direct connection is leak evidence; geography 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. A detected IPv4 or IPv6 address that matches the saved direct baseline for that family is leak evidence, and IPv4 and IPv6 on different networks or countries is Review; seeing both families on one network 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

Verify ads from a residential IP

Once the route is clean, check placements, redirect chains and landing pages from a residential exit in the campaign market, with evidence templates for every capture.

Read the evidence

FAQ

Frequently Asked Questions

Common questions about IP leak testing and proxy security.

What is an IP leak?

An IP leak is when a website sees an address you did not route through your proxy or VPN: usually your direct IPv4 or IPv6 address, exposed through WebRTC, a DNS resolver, or an IPv6 route the tunnel does not cover. The proxy shows one network while the leak reveals the real one.

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, a WebRTC route bypass, or a resolver on the direct connection’s network is a leak indicator. DNS geography and missing results remain diagnostic signals, and the tool cannot prove anonymity.

How do I run an IPv6 leak test?

Run this test on your direct connection and save the baseline. Connect through the proxy or VPN and run it again. If the IPv6 row still shows the baseline address, IPv6 is leaking: the route carries IPv4 only. Disable IPv6 on the client or use a route that covers it, then repeat the comparison.

Does the IP leak test give a full report?

Yes. The report card lists the public IPv4 and IPv6 addresses with their ASN and location estimate, every WebRTC candidate, the DNS resolvers observed, and a verdict per channel against your saved baseline. You can copy the report as text; the tool does not send it to TrueProxies.

How does WebRTC leak detection work?

The tool creates a test RTCPeerConnection without opening camera or microphone media and examines the ICE evidence. An exact visible-route match has no indicator, and neither does a browser that turns WebRTC off. A direct-baseline match or a different network is a leak indicator; another address on the same ASN stays Review. 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, WebRTC, or DNS, and review the relevant browser/client route. Change one setting at a time and repeat the same comparison. Treat DNS country 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.

Start trialView pricing

More free tools

See all tools