IP leak test: check WebRTC, DNS and IPv6 leaks behind a VPN or proxy
A VPN or proxy changes the address websites see, but it does not always cover everything your device sends. An IP leak test looks for the gaps: a browser that reveals another public address through WebRTC, DNS lookups that still go to your internet provider, or a second IP stack (IPv4 or IPv6) that bypasses the tunnel. IPOK runs each of these separately, next to the reputation of your exit IP, so you see both “what address do I show” and “does anything else slip out” in one place, free and without signup.
Connect your VPN or proxy first, then test each browser you use. The leak checks appear when you check your own connection, not when you look up another IP.
Your public IP
Try a sample IP
Try sample:
The four checks and how to read them
WebRTC
What can leak: Browsers use WebRTC for calls and peer-to-peer connections. To set one up they ask a STUN server what public address they appear from, and that answer can bypass a proxy that only covers web traffic.
How IPOK tests it: Runs only after you click. Your browser contacts Google and Cloudflare public STUN servers; the candidate addresses it gets back are parsed and compared in your browser and are not sent to IPOK.
Possible leak clue: A public candidate address that differs from your exit IP.
What it does not prove: No public candidate, or only private/mDNS candidates, means the test could not see one in this run. It is reported as unknown, not as safe.
What can leak: Every hostname you visit is resolved by a DNS resolver. If your traffic goes through a VPN but lookups still go to your ISP's resolver, the ISP (and anyone watching it) sees which sites you visit.
How IPOK tests it: The browser resolves a one-time test hostname under IPOK's own authoritative DNS (leak.ipok.io), which records which resolver asked. The self-hosted service holds the test ID, expiry and resolver IPs in memory for 5 minutes of readable lifetime, clears expired records on the next session operation, and may keep expired records in memory while idle. Only if issuing the ID fails does the web test fall back to bash.ws, and results are then read from that same backend. Older clients still use bash.ws.
Possible leak clue: A resolver in a different network or country than your exit, when the backend has comparable country data.
What it does not prove: A resolver in the same country is not proof of privacy, and some resolvers cannot be compared at all; those are shown as not comparable.
What can leak: Many connections have both an IPv4 and an IPv6 address. Some VPNs and proxies only tunnel one of them, so traffic on the other stack leaves through your real network.
How IPOK tests it: IPOK reaches you separately over IPv4 and IPv6 (ip4.ipok.io and ip6.ipok.io) and shows both exits side by side, with their ASNs.
Possible leak clue: The two stacks exit from different networks, and one of them is your home or mobile ISP.
What it does not prove: Different addresses on the same network are normal. A missing IPv6 exit can mean the stack is absent, filtered, timed out, or temporarily unreachable. It does not prove the device has no IPv6.
What can leak: Not a network leak, but a common giveaway: a browser timezone or language that does not fit the exit country, or an automation flag such as navigator.webdriver.
How IPOK tests it: IPOK compares what your browser reports (timezone, language, automation flags) with the exit IP and lists mismatches.
Possible leak clue: Timezone or language far from the exit location; webdriver set to true.
What it does not prove: Plenty of real people travel or use another language. A mismatch is context for troubleshooting, not a verdict.
On 2026-10-18 we opened IPOK in a fresh private headless Chromium window on a test server whose exit is on the Fastly network (AS54113, Seattle). The dual-stack check showed two exits at once, an IPv6 address in 2a04:4e41:88::/48 and the IPv4 address 140.248.52.113, and RIPEstat confirmed both belong to AS54113, so both stacks left through the same network. The browser consistency check flagged two things correctly: the browser timezone did not match the exit location, and navigator.webdriver was set, as expected for an automated browser. One machine, one run: this shows what the output looks like, not how often leaks happen.
A five-minute routine
Disconnect the VPN and open IPOK once, so you know your real exit IP and ISP.
Connect the VPN or proxy and reload. The exit IP and ASN should now belong to the VPN provider.
Look at both stacks. If IPv6 (or IPv4) still shows your ISP, that stack is not tunnelled: enable the VPN’s IPv6 handling or disable the uncovered stack.
Click the WebRTC check. A public candidate equal to your real IP from step 1 is a leak; restrict WebRTC in the browser or use the VPN client’s WebRTC protection.
Run the DNS check. If the resolver belongs to your ISP, switch the VPN’s DNS setting on, or set the resolver explicitly.
Repeat in every browser and profile you actually use; extensions and settings differ between them.
What IPOK does with the data
The WebRTC check is opt-in on the website and never uploads the candidates it finds. The DNS check uses IPOK’s own authoritative DNS first and only falls back to bash.ws if that first issuance fails; results stay on the backend that issued the ID. Older clients still use bash.ws. The public STUN servers (Google, Cloudflare) see the network you contact them from. These flows, and every retention period, are documented on the privacy page. A leak test that is itself careful with your address is the point.
What a leak test cannot tell you
A leak test checks a moment on one browser and one network. It does not audit your VPN’s logging, its kill switch, or apps outside the browser, and it cannot tell whether a website will accept your connection. For the reputation of the exit itself (hosting or residential, proxy flags, blocklists), see IP fraud score and IP lookup.
FAQ
What is an IP leak test?
It checks whether anything on your connection reveals a network other than the VPN or proxy exit you think you are using. The three common paths are WebRTC (the browser discovering your public address through STUN), DNS (lookups going to your ISP's resolver) and dual stack (IPv6 or IPv4 traffic that is not tunnelled).
How do I test for a WebRTC leak?
Connect your VPN or proxy, then start the WebRTC check on this page or on https://ipok.io/en. If a public candidate address appears that differs from your exit IP, WebRTC can reveal it. IPOK runs this only when you click, and the candidates are parsed in your browser rather than sent to IPOK.
Does a green result mean my VPN does not leak?
No. Green means the signals IPOK could compare did not differ in this run. Browsers, extensions, network changes and DNS caching all affect the outcome, and an unknown result means there was not enough evidence either way. Re-test after changing settings, and test each browser you use.
What is a DNS leak?
Your DNS lookups go to a resolver outside the tunnel, usually your ISP's. The sites you visit are then visible to that resolver even though the traffic itself goes through the VPN. The DNS check shows which resolver actually answered the test lookup.
Can IPv6 leak my real IP?
Yes, if your VPN or proxy only carries IPv4 while your network also has IPv6, or the other way round. The dual-stack check shows both exits; if one of them belongs to your home or mobile ISP, that stack is not covered.
Does IPOK store my real IP or WebRTC candidates?
WebRTC candidates are parsed in your browser and are not sent to IPOK. The self-hosted DNS test holds the test ID, expiry and resolver IPs in memory for 5 minutes of readable lifetime, clears expired records on the next session operation, and may keep expired records in memory while idle. Like any website, IPOK receives the IP you connect from; what is logged and for how long is listed on the privacy page.
Does the iOS app run the leak test automatically?
Yes, the iOS app runs it once when you open its Leak tab and cancels pending checks when you leave. It uses Google STUN and triggers six one-time DNS subdomain lookups to bash.ws through the system resolver. On the website, WebRTC only runs after you click.
Last checked 2026-10-18. Data flows as described in the privacy policy updated October 18, 2026.