Why WebRTC gathers candidates
ICE candidate gathering identifies possible paths for peer connections. Applications use those paths for data, audio, and video.
A data-only test can inspect candidate behavior without requesting camera or microphone access.
Candidate types matter
Host candidates describe local interfaces, server-reflexive candidates can reveal public mappings through STUN, and relay candidates use a TURN service.
A public candidate that differs from the route you intended to expose deserves review; a private address or mDNS hostname is not automatically a public-IP leak.
Modern browsers reduce local exposure
Many browsers replace local addresses with temporary mDNS names or restrict candidate details. That is a privacy improvement, but it can leave a basic test with less evidence.
Less evidence should be labeled honestly instead of converted into a confident pass.
VPN interpretation
Compare any public candidate with the public IP observed by the page and with the route expected from the VPN.
A browser test still cannot inspect every application, system route, or VPN implementation detail.
Permissions and data handling
WebRTC candidate tests do not need camera or microphone permission when they use a data-only peer connection.
MyIPCheckup starts the test only after a click and does not reuse the candidate inventory for advertising or persistent recognition.