The WebRTC host candidate does not expose a routable public address
Check id webrtc-address-class
What an ordinary browser yields
Chrome yields an mDNS `<uuid>.local` host candidate — passes; that is the LAN address being withheld, not leaked.
What a detector infers
Reading from the same fully offline `RTCPeerConnection` — built with **no `iceServers`**, so host-only gathering, no STUN, no packets — the first `typ host` ICE candidate's connection-address is extracted and classified: `mdns-local` (a `<uuid>.local` name), `rfc1918-private`, `link-local`, `cgnat`, `routable-public`, or `none`. Only `routable-public` fails; every other class passes. This is a deliberate correction of a well-known tool: CreepJS treats anything other than `0.0.0.0` as a leak, which reports Chrome's mDNS hostname as a leak when it is in fact **the obfuscation working** — the real LAN address was withheld and replaced with a per-origin random name, which is the privacy feature functioning exactly as designed. The signal that actually matters is narrower: a routable public address inside a host candidate reveals the real network identity of the machine regardless of any proxy in front of it, because the candidate is gathered from the local interface rather than routed. Severity is info, and info-severity checks are excluded from the score entirely — even a routable-public result is reported rather than counted, because it describes your network configuration rather than contradicting anything you claim. When the stack is unavailable, `pass` is null with the reason surfaced — a blocked WebRTC stack is a privacy setting or extension, a legitimate configuration, not evidence.
How to resolve it
Only a routable-public host candidate needs resolving: enable mDNS candidate obfuscation, or restrict the WebRTC IP handling policy so host candidates aren't gathered from the public interface. mDNS, RFC1918, link-local and CGNAT results need no action.
Nearby checks in Network & WebRTC
- the address WebRTC exits from matches the address this page was served to
webrtc-ip-vs-connectionThis is the one check on this page that cannot be answered from inside the page, and the only one that makes a network call. - relay-forced WebRTC exits the same address this page arrived from
webrtc-turn-egressEvery other WebRTC check on this page reads what the browser is willing to show it. - host candidates use an mDNS hostname rather than a literal LAN address
webrtc-mdns-hostWhen WebRTC enumerates the ways a peer might reach you, it offers host candidates describing your machine's own network interfaces. - ICE gathering offers at least one candidate on a working network
webrtc-gathering-suppressedThe other WebRTC rows on this page read what the candidates SAY. - every server-reflexive candidate has a host candidate behind it
webrtc-srflx-without-hostA server-reflexive candidate is not an address the browser knows about itself. - WebRTC header extensions match the claimed engine family
webrtc-extmap-engine-familyThis check generates an SDP offer and collects its a=extmap RTP header-extension URIs. - The WebRTC SDP offer matches the engine the User-Agent claims
sdp-engine-signatureAn RTCPeerConnection is constructed with no iceServers key, which makes the probe entirely offline: the native stack builds a local SDP… - NetworkInformation is only present on Chromium engines
connection-api-vs-engineThis check compares an API's mere existence against the engine family named by the User-Agent.
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on Network & WebRTC checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in Network & WebRTC — the family webrtc-address-class belongs to.