WebRTC Leak Test: Read IP Exposure and Missing Results
Understand WebRTC leak test results: matching or additional IPs, no public address, timeouts and unsupported browsers. Run a free browser exposure check.
What the WebRTC check actually does
WebRTC supports browser calls and data connections. During connection setup, ICE gathers candidate addresses; a STUN service can help discover a public-facing address. This path can differ from an ordinary web request, which is why it is useful to inspect it alongside your public IP.
IPNixa contacts Cloudflare’s public STUN service and compares the public candidates with the IPv4 and IPv6 observations for this check. Private and mDNS host candidates are not listed as public exposure. IPv6 candidates in an already observed /64 are treated as the same network, so the comparison concerns additional public networks rather than every distinct textual address.
How to run a WebRTC leak test
Keep your intended VPN configuration active while checking the browser you actually use. IPNixa does not request camera or microphone access for this test.
- Open VPN Check and wait for the public IPv4 and IPv6 observations to settle.
- Read WebRTC exposure. It runs with each connection check and waits up to three seconds for candidate gathering.
- If an additional address appears, review your VPN and browser WebRTC settings. An extra address alone does not establish a VPN leak.
- If the result is Unconfirmed, retry after checking browser restrictions and connectivity. Keep privacy settings that you intentionally enabled in mind when interpreting a missing result.
Read the state before the address
Completion and comparison answer different questions. Candidate gathering may finish without exposing a public address, or stop early after exposing only part of the list.
| State and result | What was established | What to do |
|---|---|---|
| Compared · Observed addresses match | Completed gathering found addresses in already observed public networks | Read this as a comparison, not proof of full VPN protection |
| Observed · Additional address | A public address outside the compared HTTP observations appeared | Review the address and VPN routing; an unfinished list may contain more |
| Unconfirmed · No public address observed | Gathering finished without a public address to compare | Consider browser privacy controls or a blocked STUN endpoint |
| Unconfirmed · Gathering timed out | Gathering did not finish within the test window | Retry; do not treat the result as leak-free |
| Unconfirmed · Test could not complete | The API was present but setup failed | Review browser restrictions or connection errors |
| Unsupported · WebRTC API unavailable | The browser did not expose the API | The test could not run in this browser |
Work through an additional-address example
For an illustrative test, assume HTTP confirms 198.51.100.24 after you connect a VPN, while WebRTC also observes 203.0.113.42. Both examples use documentation addresses. If you saved 203.0.113.42 before connecting the VPN, the repeated address is a reason to inspect the WebRTC path. If you did not save a direct baseline, the tool cannot establish that the additional address belongs to your home connection.
First read whether gathering completed. An additional address is still a useful observation when gathering times out, but the list may be incomplete. Then check your VPN’s browser exclusions and WebRTC guidance, repeat the same test and compare the results. If you contact support, include the state label and test time along with the address pattern. Avoid drawing a location or identity conclusion from an extra candidate: IPNixa does not turn it into a hidden home location or a VPN-provider verdict.
Why no public address is an inconclusive result
A browser can expose only local candidates, hide address details or fail to reach the STUN service. These outcomes can be consistent with privacy controls, but they do not establish what would happen in another browser, call or application.
For a useful follow-up, repeat the test under the same network conditions and review the full IPv4/IPv6 comparison. DNS leaks require a separate authoritative DNS test service. VPN provider classification and browser fingerprint exposure also answer different questions.
Frequently asked questions
Is “no public address observed” a successful WebRTC leak test?
It is inconclusive. No public address was available for comparison. Browser controls, local-only candidates or blocked STUN access may explain the result.
Why does my WebRTC test time out?
Address gathering did not finish within the test window. Network conditions, restrictions or STUN reachability may affect it. A timeout is shown as Unconfirmed, even if partial matching addresses were seen.
Does a WebRTC test reveal my real IP behind every VPN?
No. It lists public addresses exposed by this browser during this check. A correctly routed or restricted setup may reveal only expected addresses or none at all.
Does IPNixa need camera or microphone permission?
No. This check gathers connection candidates with a data channel; it does not request or record audio or video.