The core diagnostic question for any WebRTC leak result is simple to state and worth being precise about: does the exposed public address belong to your VPN, or to your actual ISP? The answer determines whether you're looking at expected behavior or a genuine problem.
The expected case
When a VPN is working correctly, WebRTC's public-address discovery should reveal the VPN's own exit IP — the same address your regular HTTP traffic shows. Seeing this address appear in a WebRTC candidate list isn't a leak; it's WebRTC correctly reporting the address the VPN tunnel presents to the outside world.
The problem case
A genuine leak looks different: the WebRTC candidate list includes a public address that does not match your VPN's exit — typically your real ISP-assigned address, discovered because STUN's request bypassed the VPN tunnel entirely. This is the pattern that actually indicates your real identity is escaping.
How to tell them apart in practice
- Note your VPN's exit IP from an ordinary check like NetRiskScan's IP Risk Check.
- Run the WebRTC Leak Test and review every public candidate address it lists.
- Any candidate matching your VPN's exit is expected. Any candidate that doesn't match — especially one that geolocates to your actual region rather than the VPN's — is the routing problem worth fixing.
FAQ
What if I see two different public addresses, both unfamiliar?
This can happen with certain VPN configurations using multiple exit points, or with WebRTC relay (TURN) candidates that aren't your address at all — cross-check each candidate's classification carefully rather than assuming any unfamiliar address is automatically a leak.