VPN Leak Test: WebRTC & DNS Leak Checker for Privacy

VPN leak test online: detect WebRTC IP leaks in your browser, compare your public and local IPs, and check whether your VPN hides your real address.

Updated 2026-08-16

Related Tools

Device Info: Check Browser, OS, GPU & Hardware Specs

IP Address Lookup: Online Geolocation, ISP & ASN Info

DNS Lookup: All 16 Record Types (A, AAAA, MX, SRV)

HTTP Headers Viewer: Analyze & Audit Response Headers

Ping & Traceroute: Test Network Latency & Server Uptime

Port Scanner Online: Check Open Ports & Common Services

Features

WebRTC leak detection: the test collects ICE candidates through the same mechanism video calls use, then checks whether a private address (192.168.x.x, 10.x.x.x) slipped out while your VPN is on
Public IP via STUN: two STUN servers (Google and Cloudflare) report the address the internet sees you from, so you can compare it with your VPN exit server
mDNS protection status: Chrome and Edge hide the real local IP behind a .local name; the tool tells you whether your browser is protecting you or exposing the raw address like Firefox does
Clear verdict: results are classified as leak, protected, unclear, or error, each with a concrete next step instead of a bare IP dump
Honest DNS scope: a static page cannot run a real DNS leak test (it needs a server that resolves a unique domain), so the tool says so and gives command-line and service alternatives
VPN-first workflow: the recommended flow is connect your VPN, then run the test and compare the public IP against your provider's exit server
No personal data collected: the test runs entirely in your browser and the results never leave the page, which matters for a privacy-checking tool
Works on desktop and mobile: the same detection runs in Chrome, Edge, Firefox, and Safari, with browser-specific behavior explained in the results

How to Use

1Connect your VPN first, then open this page. Testing without a VPN shows your normal ISP address, which is expected and not a leak.
2Tap Start Leak Test and keep the page in the foreground. The test collects ICE candidates for about 4 seconds.
3Read the Public IP card: with a VPN on, this address should match the exit server your VPN provider shows in its app.
4Check the Local IP exposure card: seeing 192.168.x.x or 10.x.x.x means WebRTC exposed your real network address; seeing *.local means the browser hid it.
5If the verdict says leak, disable WebRTC in your browser settings (Chrome: chrome://settings/content/webRTCAllowLegacyCameraMicrophonesCertificates or the privacy content settings) or install a WebRTC-blocking extension, then re-run the test.
6Compare results with a second device on the same VPN: the public IPs should match, and neither device should show a private address.
7Test after changing VPN servers: switch to a different country in the VPN app and re-run, confirming the public IP changes with the server.
8Use the DNS section as a reminder: for a real DNS leak check, run dig +short whoami.akamai.net from the command line or use a backend service, since this page cannot resolve domains itself.
9Re-test after browser updates: browsers change their WebRTC behavior between versions, so a clean result from last year is worth confirming again.

Frequently Asked Questions

What is a VPN leak test?

A VPN leak test checks whether your real IP address or DNS queries escape the VPN tunnel. This tool tests the WebRTC side: it collects the ICE candidates your browser would send during a video call and looks for private addresses (192.168.x.x, 10.x.x.x) that should stay hidden when a VPN is active. A clean result means the browser only exposed addresses the VPN controls.

Can this tool test DNS leaks?

No. A real DNS leak test requires a server that resolves a unique domain name and reports which DNS server answered, and a static browser page has no server to do that. This tool honestly tests WebRTC only. For DNS leaks, use a backend service such as dnsleaktest.com or ipleak.net, or check from a terminal with dig +short whoami.akamai.net (Unix) or nslookup myip.opendns.com (Windows).

Why does my browser expose 192.168.x.x during the test?

A 192.168.x.x, 10.x.x.x, or 172.16-31.x.x address in the local section means WebRTC is exposing your real private network address. Firefox, older Safari, and Chromium with mDNS disabled leak this by default. Fixes, in order: update the browser (Chrome and Edge now hide it), disable WebRTC in browser settings, or use a WebRTC-blocking extension, then re-run the test.

What does *.local in the local section mean?

A .local address is a mDNS-obfuscated name that Chrome and Edge generate instead of your real local IP, for example 6f8c-4a2b-1c9e.local. Seeing only .local addresses means the browser is protecting you from WebRTC leaks. Firefox and Safari do not use this obfuscation, which is why they can show the raw private IP.

Does a VPN hide my IP from WebRTC?

No. WebRTC can bypass the VPN tunnel and ask the network stack directly for local addresses, which is exactly why leak tests exist. A VPN hides your IP from normal HTTP traffic, but a browser with WebRTC enabled can still expose a private address or even the real public IP. The fix is browser-side: disable WebRTC or use a blocking extension, because no VPN setting can stop it.

Why do I see two different IP addresses in the results?

The public IP comes from a STUN server and is the address the internet sees; a private address in the local section comes from the host candidate and is your actual network address. Seeing both means WebRTC is leaking the private one. Seeing only the public IP, with the local section showing *.local or nothing, means the leak is closed.

Is my real IP leaked if I see 10.x.x.x or 172.16.x.x?

Yes, those are private network ranges (RFC 1918), and their presence means a website could learn your local network address through WebRTC even with a VPN on. The leak is limited to the LAN address, not your public IP, but it still identifies your device on the network and defeats some VPN privacy expectations. Disable WebRTC or use a blocker, then re-test.

How do I check DNS leaks on Windows or Mac?

On Windows open Command Prompt and run nslookup myip.opendns.com; the server line shows the DNS server that answered. On Mac or Linux run dig +short whoami.akamai.net and compare the result with your VPN's DNS. If the answering server belongs to your ISP instead of your VPN, you have a DNS leak and should enable the VPN's built-in DNS protection.

Why does Safari show a private IP while Chrome shows .local?

Safari does not apply mDNS obfuscation to WebRTC host candidates in the same way Chrome and Edge do, so it can expose the raw private IP. Safari 14.1 and later added some protection, but behavior varies by version. The consistent fix across browsers is disabling WebRTC or blocking it with an extension.

My VPN provider says it has no leaks. Should I still test?

Yes. VPN providers advertise leak protection for their own tunnel, but WebRTC leaks happen in the browser, outside the VPN's control. A provider can be technically leak-free while your browser still exposes a private IP. The result of this test depends on the browser, not the VPN, which is why the same VPN can test clean in Chrome and leak in Firefox.

Why are my results different every time I test?

ICE candidate collection is not deterministic: the browser gathers candidates over a few seconds, STUN servers can respond at different speeds, and some candidates arrive after the test window closes. If the verdict flips between runs, run the test three times and trust the worst result, since a single leak is enough to matter.

Will disabling WebRTC break video calls or other sites?

Yes, disabling WebRTC entirely stops video calls, screen sharing, and some chat features in the browser. The trade-off is deliberate: complete leak protection versus full WebRTC functionality. A middle ground is a blocking extension with per-site toggles, so video call sites can still use WebRTC while everything else stays blocked.

Can a browser extension really stop WebRTC leaks?

Yes. Extensions like WebRTC Leak Prevent or uBlock Origin's advanced mode force the browser to disable non-proxied WebRTC or strip private candidates, which closes the leak at the browser level. After installing one, re-run this test: the local section should show *.local or nothing instead of a private IP.

Does a VPN leak test collect or store my IP address?

No. This test runs entirely in your browser: the STUN exchange happens between your browser and the STUN server, and the results are rendered on the page without being sent anywhere. There is no analytics hookup and no server log on this site, which is the point of a privacy-checking tool. The IP you see is displayed locally and disappears when you close the tab.

VPN 会泄漏个人隐私吗？

VPN 本身不会主动泄漏隐私，但泄漏可能来自三处：WebRTC 让网页绕过 VPN 直接读取本地 IP（本工具检测的正是这个）；DNS 请求走了运营商服务器（需要服务端检测）；以及 VPN 服务商自己的日志政策。连接 VPN 后运行本工具，公网 IP 应与 VPN 出口一致、本地 IP 不暴露，即通过 WebRTC 检测。

Why does the public IP show an IPv6 address?

Because a proxy may only carry part of the protocol families. The STUN servers have both IPv4 and IPv6 addresses, the browser prefers the IPv6 path when available, and the source address the STUN server sees is whatever your network actually exits through. The IPv6 address may be your proxy exit or, when the proxy does not cover IPv6, your real address. Compare it with the exit IP shown in your proxy app: a match means IPv6 goes through the proxy, a mismatch means that family goes direct, so enable that family in the proxy or disable system IPv6 and re-test.

Why does my IP differ between this tool and an IP lookup website?

Because the two paths are different: IP-lookup websites reach their server over TCP/HTTP through your browser proxy settings, while this tool reaches STUN servers over UDP through the network stack's UDP path. If the website shows your proxy exit IP but this tool shows your real IP, your proxy only carries TCP and UDP goes direct, which is typical when the proxy client's UDP rule is DIRECT or the node protocol does not forward UDP. Fixes: check the UDP rule in your proxy client (common in Clash-style clients), or switch to a node protocol with UDP support such as WireGuard, Trojan, or Hysteria2.