WebRTC test: understand candidate addresses
This WebRTC test page explains the principle: the browser gathers ICE candidates over STUN. Those can include a LAN address and a public address even when ordinary HTTPS already goes through a VPN or extension proxy.
Use this page to learn what each candidate type means before you judge a leak. For a one-click WebRTC leak judgment, open the WebRTC leak test after you understand the list.
Candidates are collected in this browser and shown on screen. They are not uploaded to ipdet.app unless you generate a report.
How to use this tool
- Connect the VPN or proxy you normally browse with.
- Start the WebRTC test and wait for STUN results to list host and server-reflexive candidates.
- Note which addresses are LAN vs public. Then use the WebRTC leak test if you need a leak judgment against your VPN path.
List WebRTC candidates
What ICE candidates are
WebRTC asks the browser for addresses it could use for a peer connection. Host candidates are usually local. Server-reflexive candidates come from STUN and often show a public IP.
Ordinary HTTPS through a VPN does not automatically hide those STUN paths. That is why a WebRTC test can show a different address than the IP lookup.
Frequently asked questions
Is a WebRTC test the same as a WebRTC leak check?
No on this site. This WebRTC test explains and lists candidate addresses. The WebRTC leak test is the one-click judgment of whether a public candidate bypasses your VPN or proxy.
Why do I see a 192.168.x.x address?
That is a typical LAN host candidate. It is common and not the same problem as a second public IP that bypasses the tunnel.
Where do I go to judge a WebRTC leak?
Open the WebRTC leak test. Compare public candidates with the IP lookup there when you need a pass/fail-style leak check.
Related tools
