Inspect connection candidates, not a vague leak score
WebRTC lets browsers establish real-time connections for calls, data channels and collaboration. To find a route between peers, it gathers candidates describing possible network endpoints. That discovery process can reveal information that differs from the address a normal web request uses. The difference matters when you expect a VPN or proxy to carry all traffic.
This tool creates a temporary data channel, contacts a public STUN service and records the ICE candidates exposed by your browser. It does not start a call or request microphone or camera access. You receive the candidate types, addresses and protocols that were actually observed. A missing public candidate is reported as missing, not converted into a claim that your connection is completely anonymous.
Understand host, reflexive and relay candidates
A host candidate describes a local interface available to the browser. Older browser behaviour sometimes exposed private interface addresses directly to page scripts. Modern browsers often replace the address with an mDNS name ending in .local. That is an intentional masking mechanism. The name is not a public website and does not mean that another person can browse to your device.
A server-reflexive candidate, usually marked srflx, represents the address mapping observed by a STUN server. On a home connection it may be a router’s public address; behind a VPN it depends on how that network and browser route the request. Comparing this address with the public IP you expect is more informative than seeing a generic red badge.
A relay candidate is associated with a TURN service that relays traffic. This diagnostic does not configure a TURN account, so the absence of relay candidates is expected. It does not imply that conferencing applications are unable to use a relay. Those applications can supply their own servers, credentials and routing policies.
The Overview tab explains the findings. Measured data lets you search individual fields and values, while JSON report shows the complete export. Export JSON to retain a baseline, or print the findings for your own records. Review the report before sharing it: browser characteristics, token claims, and file names can reveal information about your setup.
Run a controlled VPN comparison
Begin with the connection configuration you intend to evaluate. Check your public IP in a separate run, then run the WebRTC test. Record the exact public candidate addresses and whether the gathering process completed or reached its observation limit. Keep the two checks close together in time; reconnecting a mobile network or changing a VPN endpoint can legitimately change an address between observations.
If a server-reflexive address differs from the expected VPN address, investigate the route rather than jumping straight to a conclusion. Split tunnelling, browser-only proxies, separate IPv4 and IPv6 routes, VPN exclusions or an institutional network can explain the difference. A browser proxy may carry HTTP traffic while other traffic follows a separate route. Compare the addresses with information from your own network configuration.
Repeat the test after one configuration change. Turning off WebRTC entirely may stop some candidates from appearing, but it can also disable calls or collaboration features. Prefer documented browser and VPN controls that match your needs. Test an actual conferencing application afterwards so that a privacy improvement does not silently break work you rely on.
Explain an empty or incomplete result
A browser can expose no candidates because WebRTC is disabled, local privacy policy prevents disclosure, UDP traffic is blocked, the STUN service cannot be reached or a short gathering window expires before a response arrives. Those conditions look similar from a single page. This test cannot distinguish all of them, so the report retains the timeout information and observed candidates instead of inventing a diagnosis.
The observation lasts up to roughly seven seconds. Networks with unusual filtering or high latency may not complete in that time. Running the test again can establish whether the result repeats. An ordinary web page also cannot prove that every application uses the same network path. Your mail client, operating system services and another browser can follow different rules.
Use the evidence as part of a routing investigation. If the browser reports a private address, assess what the intended peer can see and whether the exposed information matters for your threat model. A private address is network metadata; it is not automatically an externally reachable port or a successful intrusion.
Candidate types at a glance
| Field or type | How to read it |
|---|---|
| host | A local candidate; it may use an mDNS name to mask the interface address. |
| srflx | The public mapping observed through STUN; compare it with your expected route. |
| relay | A TURN relay candidate; this test does not configure a TURN account. |
| Observation timeout | The collection window ended; absence of a result is not a clean bill of health. |
Strengths and limitations
What this is useful for
This test exposes the actual candidate information available to the page and identifies mDNS masking. It is useful for comparing browser settings and documenting an unexpected network route. You can retain the complete observation instead of relying on an unexplained yes-or-no judgement.
What to keep in mind
One STUN server and one gathering attempt do not cover every possible route or application. A network can block this test without preventing every form of address disclosure. The result is not a port scan, a firewall audit or a certificate that a VPN has no leaks.
Common questions
Will this switch on my camera or microphone?
No. The tool creates a data channel for connection discovery. It does not call getUserMedia or request media permissions. A WebRTC test can gather candidate information without recording sound, capturing video or establishing a call with another user.
Why does the address end in .local?
That is usually a browser-generated mDNS hostname used to avoid handing the page a raw local address. Treat it as a masked host candidate. It is different from a server-reflexive public address and should not be copied into a public IP geolocation service.
What information leaves my browser?
When you run the test, the browser contacts Google’s public STUN service at stun.l.google.com:19302. That service receives the connection information necessary to answer a binding request. The candidate report itself is not uploaded by this application.
Does a matching public IP prove my VPN is safe?
It shows that the observed STUN mapping agrees with the address you compared at that time. It does not evaluate DNS routing, other applications, kill-switch behaviour, future reconnects or traffic that this page never generated. Use separate tests for those questions.