WebRTC supports real-time voice, video and peer connections. To establish a route, the browser gathers network candidates. Older advice often claims that every site can read a device's private addresses, but modern browsers commonly obscure local host candidates with mDNS names.
What may still be visible
A service involved in a WebRTC connection can learn candidate information needed for communication. Public-address behavior depends on browser, network, VPN and relay configuration.
Test the real setup
- Test before and after connecting the VPN or proxy.
- Compare the WebRTC result with the ordinary public IP.
- Check the same browser profile used for calls.
- Repeat after browser or VPN updates.
Do not break features blindly
Disabling WebRTC can stop meetings, browser calls and screen sharing. Prefer browser and VPN controls that route or limit candidates while preserving required features.
The meaningful question is whether WebRTC exposes a route outside the protection you intended, not whether a test page displays any address at all.
Relay servers change the route
TURN relays can carry media when peers cannot connect directly. Organizations may require relay-only behavior for privacy or network control, at a performance cost. The application, not a random extension, should configure that policy.
Interpreting a result
A private mDNS name is not the same as a public address leak. Record the address type, candidate type and active network before concluding that a VPN failed. Repeat the test during a real call because candidate gathering can differ from an idle test page.
Test with and without the privacy tool
Record the public address shown by an ordinary IP check, then run a WebRTC candidate test during the same connection. Repeat after enabling a VPN or browser setting. Private mDNS names are not the same as exposed local numeric addresses, and a matching VPN address is not a leak.
Avoid breaking communication blindly
Disabling WebRTC can stop browser calls, screen sharing and support tools. Prefer the browser or VPN vendor's supported leak-protection setting, keep software current and verify the result. Enterprise administrators should test conferencing before enforcing a global policy.
Remember that a site can learn the connection address through normal HTTP traffic. The question is whether WebRTC reveals an additional address that defeats the intended routing or privacy boundary.
Interpret candidate types correctly
WebRTC gathers network candidates so browsers can establish voice, video and data connections. A test may show host candidates, server-reflexive addresses or relay addresses. Modern browsers can replace local addresses with mDNS names, so seeing a local-looking identifier is not automatically a public IP leak.
The relevant question is whether WebRTC exposes an address outside the network path the user intended. Compare the normal public address, the VPN or proxy address and the candidate type during an actual call. A matching VPN address is evidence that routing is working, not a leak.
Fix without breaking communication
Use supported browser or VPN controls before installing another extension. Disabling WebRTC can break meetings, screen sharing and customer support tools. Enterprise teams may prefer relay-only media through TURN servers, accepting extra latency in exchange for a predictable route.
Repeat tests after browser, extension and VPN updates. Document the expected addresses and candidate types so future results can be compared with a known baseline rather than interpreted from colour-coded warnings alone.