A WebRTC test can display a private address, a public address, a name ending in .local, or no candidates at all. Those outcomes describe different parts of connection discovery. Calling each one an IP leak loses the information needed to decide whether the browser behaved as intended.
Imagine that a browser proxy sends an HTTPS request through one gateway, but a WebRTC test reports a different public mapping. The useful task is to identify the candidate type, the transport involved and the proxy’s promised coverage. This article explains that investigation without assuming that a short candidate list represents every path a future video call could use.
Understand what ICE is trying to accomplish
Interactive Connectivity Establishment, or ICE, helps two endpoints find a working path for media or data. Each endpoint can have several possible contact addresses. A device may have Wi-Fi, a VPN interface and more than one address family. Network address translation adds another complication because the address visible outside a router can differ from the address assigned locally.
A candidate is one potential contact point together with properties such as type, transport and priority. Candidate gathering produces possibilities; connectivity checks and the application’s configuration determine what can actually be used. A diagnostic that only gathers local candidates has not established a working peer-to-peer session or identified the selected pair for a real call.
The WebRTC exposure test creates a peer connection and collects the candidates this browser exposes during its observation window. It contacts a public STUN service. It does not request microphone or camera access, and its configuration does not provide a TURN relay allocation.
Read the candidate type before the address
| Type | Where it comes from | What to investigate |
|---|---|---|
| Host | A local interface contact point, possibly concealed behind an mDNS name | Which local information the browser exposes to the page |
| Server-reflexive | A mapping observed through a STUN exchange | Whether that route matches the intended tunnel or proxy policy |
| Relay | An address allocated by a TURN service | Whether relay configuration and credentials work for the application |
| Peer-reflexive | A contact point learned during connectivity checks | The established ICE session, rather than a gathering-only test |
A server-reflexive candidate can identify a public mapping created by a router or gateway. It does not automatically identify the device’s own interface address. A relay candidate describes infrastructure acting on behalf of the endpoint. Treating both addresses as if they were assigned directly to the laptop produces misleading location and ownership claims.
Transport and address family matter too. An IPv4 server-reflexive candidate and an IPv6 HTTPS observation are not directly interchangeable. Keep the complete candidate classification in your private notes even when you redact the address itself. It often explains more than the digits.
Recognise an mDNS-masked host candidate
Browsers can expose a generated .local name instead of an ordinary local IP in a host candidate. This reduces the local address information directly available to the page. The name is not an internet hostname that an arbitrary public DNS resolver is expected to resolve.
Do not paste that name into a public DNS explorer and conclude that the candidate is invalid when no answer appears. Multicast DNS operates in a different context. Likewise, the existence of a masked host candidate does not prove that every other candidate type or interface detail has been hidden.
When comparing browser configurations, record whether host addresses are exposed as IP literals, names or not at all. A change in representation is an observation about the browser’s behaviour. It is not a complete privacy score, because accounts, storage and other browser signals can still link activity independently.
Know what the STUN service learns
A STUN binding exchange allows the client to learn address information associated with the request as seen by the service. The service necessarily receives connection metadata needed to answer. Running the check therefore involves a network contact even though the resulting report is assembled in the browser.
The mapped address can differ from an HTTPS source address when the two traffic types follow different gateways. Browser proxy settings are a common reason to investigate, but they are not the only explanation. Separate address families, routing exceptions, network changes and service-specific paths can also create differences.
A STUN response is not a scan of the home network. It does not enumerate every device behind a router or demonstrate that unsolicited inbound traffic can reach a particular computer. NAT behaviour, filtering and application connectivity checks determine additional properties that the returned mapping alone cannot establish.
Investigate a proxy and STUN mismatch
Use a fictional setup with one browser profile and a proxy extension. An HTTPS IP check uses the proxy’s expected exit. The WebRTC test collects a server-reflexive candidate associated with the access connection. First confirm that both observations happened while the same settings and network were active. A stale report from before connecting the proxy is an easy source of confusion.
Next read the extension’s scope. If it only proxies browser web requests, the discrepancy may follow its documented design. If the requirement is that all relevant traffic use a device tunnel, evaluate a configuration that actually provides that coverage. The remedy should follow the requirement, rather than the wording printed on a browser extension’s button.
Repeat the test after one deliberate change. Compare candidate types, address families, gathering completion and the HTTPS observation. If the public mapping still differs from the expected route, capture the smallest reproducible record for the administrator. Avoid running unrelated network switches during the comparison, because they make the cause harder to isolate.
Treat an empty result as an unresolved observation
No candidates can mean that WebRTC is unavailable, restricted or disabled. It can also mean the configured STUN endpoint is unreachable, relevant traffic is blocked, or the observation ended before gathering completed. Those explanations have different implications for a working call application.
Check the tool’s reported state and error before changing anything. If the API cannot create a peer connection, address the browser or policy constraint. If gathering starts but produces no useful network candidate, investigate reachability and time limits. A missing relay candidate is expected when no TURN service is configured, so it should not be counted as an unexplained failure here.
Do not translate an empty table into a claim that a VPN protects every connection. The test has less evidence in that case. It may still be a desirable browser policy outcome, but that conclusion depends on the intended behaviour and on separate checks of required application functionality.
Test the real application after a policy change
Keep a distinction between gathering completion and connection success in the test record. A browser can finish gathering several candidates and still fail to establish a usable pair with its peer. Conversely, trickle ICE allows candidates to arrive over time, so the first visible result may be incomplete. A screenshot taken immediately after starting a check can omit later evidence without any underlying policy change.
Disabling WebRTC or restricting its network behaviour can affect calls, screen sharing and collaborative tools. A diagnostic page may look quieter while the application fails to connect or falls back to a different path. Test the important workflow with a non-sensitive session after making a change.
Applications can configure their own STUN and TURN servers and can prefer or require relay transport. Those choices influence the candidate set. An application using a relay-only policy is not reproduced by a diagnostic configured with a single public STUN server. Compare configurations before interpreting different candidate lists as contradictory results.
For a production call failure, an application’s connection statistics and selected candidate pair can be more useful than a fresh standalone test. Keep the gathering diagnostic as supporting evidence and ask which path the failed session actually selected. That moves the investigation from possible routes toward the route involved in the incident.
Frequently asked questions
Does this test turn on my microphone?
No. Candidate gathering can occur without requesting microphone or camera streams. This tool does not ask for either permission. A conferencing application may request media separately, so distinguish its permission prompts from the connection-discovery mechanism itself.
Is every public candidate an unexpected disclosure?
No. A public mapping may be the intended VPN exit or an expected interface. Compare it with the configuration and the request type. The important question is whether the browser exposed a path outside the policy you meant to enforce.
Why is there no TURN address in the report?
A relay allocation requires TURN infrastructure and suitable configuration, often including credentials. The included test uses STUN and does not provision a TURN account. Absence of a relay candidate therefore says nothing about whether a separate call service has functioning relay infrastructure.
What information makes a useful bug report?
Include browser version, proxy or tunnel scope, candidate types, address families, gathering state, timestamps and repeatable steps. Share full addresses only through an appropriate channel when necessary. Do not include session tokens, call invitations or unrelated browsing data.