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. Candidates can describe local interfaces, a public address discovered through STUN or a TURN relay. An mDNS name obscures a local numeric address; it does not conceal every public candidate. 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.
Check whether WebRTC reveals an additional address outside the route you intended. A VPN address in one candidate does not establish that every candidate, application or address family uses the tunnel.
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.
Keep a baseline of expected addresses and candidate types. A website also sees the source address of its ordinary HTTP connection, so an address appearing in a test is not automatically a leak.