Short answerAnother public WebRTC address requires a route verification, but does not in itself prove a leak.A private address or a .local name is not equal to a public IP.A lack of candidates does not prove protection either.

Two ways to see a network address

The HTTP request goes to the web server. WebRTC looks for a suitable way to exchange data, and can go to STUN. If the routing rules differ, these mechanisms can observe different addresses, so one green mark "protected" would hide too many conditions.

The check below only creates a data channel. It doesn't query the camera, it doesn't record the voice, it doesn't connect you to a random person. The external STUN sees the sender's address; the call starts after you've confirmed it.

Compare HTTP and WebRTC

WebRTC IP leak test

Free

Loading the check...

Three possible outcomes

Public addresses matched. The resulting candidates match the HTTP connection address. This is a useful observation for this tab, but not a validation of DNS, other applications, or tunnel break behavior.

There's another public address. Verify IP versions and connection rules. IPv4 and IPv6 can go on different routes. Compare the result to your ISP's known address and repeat under the same conditions; don't infer from the country name alone.

There's not enough data. STUN may not have responded, WebRTC may have been limited to browser policies, addresses may have been hidden, and an empty list may not be interpreted as “no leaks.”

Local addresses and mDNS

Private band addresses describe a local network. Browsers can also replace a local address with a name ending with .local. These values are displayed to understand the method, but are not counted as public addresses in comparison.

The tester does not determine the identity of each address to your ISP, nor does it determine which route was desired, but the correct interpretation depends on your connection configuration.

Why there's no promise to check the DNS

A normal page does not receive a list of DNS resolvers from the browser. A reliable DNS check requires monitoring unique requests on its own authoritative DNS server, and substituting such a check with a list of prospective providers would give false confidence.

Save the report if you want to match two browsers or discuss the result with the administrator of the work network. When you publish it, note that it contains the observed IP addresses.

Sources and methodology

Calcomera editorial teamTests, explanations and open limitations of the method. About the editors