IP purity check
Test your IP as soon as the page opens: network type, native or broadcast, the SpamCop blacklist, time zone, language and WebRTC, plus how to read each result.
This page checks as soon as it opens whether the IP websites see and the addresses WebRTC exposes are the same. If they differ, WebRTC is not going through your proxy.
This page compares two things as soon as it opens: the IP websites see, and the addresses a page can get through WebRTC. If they differ, WebRTC is not going through your proxy, and websites can see another, real IP of yours.
Checking…
A WebRTC leak is when your proxy is on and websites see the proxy IP, yet a page can still read another public IP through the browser’s WebRTC feature, usually your own network’s real address. It comes from how WebRTC works: to set up audio and video connections, the browser asks a STUN server directly for its public address. RFC 8828 says that when a client sits behind a proxy but can also reach the internet directly, these checks do not go through the proxy and reveal the client’s public IP. This page compares both sides as soon as it opens and gives one of four results: no leak, leak, worth a look, or cannot test. To fix it, set WebRTC in your antidetect browser to replace the address with the proxy IP (AdsPower calls it Replace), install Google’s official WebRTC Network Limiter extension in Chrome to keep WebRTC on the proxy, or turn WebRTC off in Firefox’s about:config. Test again here after each change.
Updated:
| Item | Meaning | Next step |
|---|---|---|
| No leak | WebRTC shows only the public IP websites see, or no public IP at all. | Nothing to change. Test again after you switch proxy, browser or settings. |
| Leak | WebRTC shows another public IP of the same type, and a page can read it. It is usually your real IP outside the proxy. | Change the WebRTC setting as described under “How to fix it” and test again. |
| Worth a look | Only a public address of the other type appears: websites see IPv4 and WebRTC also gives an IPv6 address, or the other way round. | With a proxy on, change the WebRTC setting as described under “How to fix it” and test again; without a proxy you can ignore it. |
| Cannot test | The browser has WebRTC turned off or blocked, so a page cannot read any address. | Nothing leaks through WebRTC. Remember it is off when you need video calls in the browser. |
| Cannot compare | We could not look up the IP websites see this time. | Reload the page and test again in a moment. |
Local addresses (such as 192.168.x.x, or the xxxx.local names browsers use instead) are not public IPs and do not count toward the result.
WebRTC is the browser feature for real-time audio and video, such as video meetings in a web page. To connect two devices directly, the browser asks a STUN server for its public address, and the STUN server replies with the address it sees. A page can read that address through the WebRTC interface.
The catch is that this request does not necessarily go through your proxy. RFC 8828 says that when a client sits behind a proxy but can also reach the internet directly, WebRTC’s STUN checks do not go through the proxy and reveal the client’s public IP. That is the case when the proxy is set only in the browser or an extension: web requests use the proxy, while WebRTC’s request goes out directly.
Local addresses are mostly hidden now. Since Chrome 76 in August 2019, Chrome replaces the local addresses WebRTC gives out with random xxxx.local names. This page counts such names separately and does not treat them as a leak.
Find WebRTC in the profile settings and choose Replace. AdsPower says the public address is then replaced by the proxy IP and local addresses are masked. Real uses your real IP; Disable turns WebRTC off, and AdsPower says websites will detect that you turned it off; Forward relays through Google’s servers. Other antidetect browsers usually have a WebRTC option under a different name; test here after setting it.
Expected result The result becomes “No leak” and the WebRTC column shows the proxy IP.
Install Google’s official WebRTC Network Limiter extension and, on its options page, choose to keep WebRTC on the proxy configured in Chrome. The extension notes that disabling non-proxied UDP is off by default and has to be chosen on the options page.
Expected result Test again: your real IP no longer appears in the WebRTC column. The cost is that video calls in the browser may lose quality: RFC 8828 says media falls back to TCP when the proxy does not support UDP.
Open about:config in the address bar and set media.peerconnection.enabled to false. According to Mozilla, pages can then no longer create WebRTC connections, so they cannot read any address.
Expected result The result becomes “Cannot test”. Video calls in the browser stop working; set it back to true when you need them.
When a proxy tool takes over all traffic of the computer, WebRTC’s request is handed to it too, and the result depends on whether the tool forwards UDP.
Expected result Just test on this page: if there is no leak, nothing needs to change.
Reload this page after every change. While you are at it, use the IP purity check to see whether your time zone and language match the IP too.
Expected result The result becomes “No leak” or “Cannot test”.
It stops the leak, at a price: video meetings and voice calls in the browser stop working. AdsPower says of its Disable mode that websites will detect that you turned WebRTC off. So when you need WebRTC to work and still want no leak, replacing the address with the proxy IP suits better than turning it off.
It depends on how the VPN takes over traffic. Mozilla notes that when Firefox is set to use only the default route, WebRTC uses the VPN’s exit address. The simplest way is to test here with the VPN on: “No leak” means you are fine; “Worth a look” means another type of address, usually IPv6, does not go through the VPN.
No. It is a random name the browser gives a local address, and pages cannot see the real local address behind it. This page only counts these names; they do not affect the result.
Each site uses its own STUN server and waiting time, so the addresses they get at the same moment are not always identical. This page uses Cloudflare’s STUN server. Test a few times and go by the addresses that appear every time.
The addresses WebRTC finds are compared with the IP websites see only in your browser and are never sent to us. Location and network operator are looked up only for the IP websites can already see: nothing is written to a database, logs do not record addresses, and results stay in server memory for 24 hours only.
A WebRTC leak comes from browser settings, so it can happen with any provider’s proxy and can be fixed the same way. When you set up a Proxy302 IP in an antidetect browser, set WebRTC as described above and test again here.
Official documentation · Confirmed on:
Read on 4 November 2026. When a client is behind a proxy but can also reach the internet directly, WebRTC’s STUN checks do not go through the proxy and reveal the client’s public IP. Mode 4 (force proxy) requires WebRTC media to be proxied whenever HTTP is; HTTP and most SOCKS proxies do not support UDP, so media then moves to TCP and quality drops.
Official documentation · Confirmed on:
Read on 4 November 2026. STUN is a protocol to discover your public address: the client sends a request to a STUN server on the internet, which replies with the client’s public address and whether the client is reachable behind the router’s NAT.
Official documentation · Confirmed on:
Read on 4 November 2026. Chrome replaces private IP addresses in WebRTC ICE host candidates with random mDNS hostnames ending in .local, for example 1f4712db-ea17-4bcf-a596-105139dfd8bf.local; expected to roll out fully in August 2019 with Chrome 76.
Official documentation · Confirmed on:
Read on 4 November 2026. Developed by Google. It configures how WebRTC’s network traffic is routed by changing Chrome’s privacy settings and can require WebRTC traffic to use the proxy configured in Chrome; disabling non-proxied UDP is off by default and is set on the extension’s options page.
Official documentation · Confirmed on:
Read on 4 November 2026. media.peerconnection.enabled controls whether pages can create RTCPeerConnection objects; with it off no ICE candidates are generated. media.peerconnection.ice.default_address_only uses only the default-route interface, which with a VPN is the VPN’s exit address.
Official documentation · Confirmed on:
Read on 4 November 2026 (published 1 February 2024, updated 18 August 2026). Forward relays via Google to mask the real IP; Replace keeps WebRTC on, replaces the public address with the proxy IP and masks local IPs; Real keeps WebRTC on with your real IP; Disable turns WebRTC off, and websites will detect that.
Create an account, top up once, then pick rotating residential, static ISP or datacenter IPs and have one running in your browser within minutes.