the address WebRTC exits from matches the address this page was served to
Check id webrtc-ip-vs-connection
What an ordinary browser yields
The public address STUN reports and the address this page was served to are the same, meaning both paths leave through one exit.
What a detector infers
This is the one check on this page that cannot be answered from inside the page, and the only one that makes a network call. A browser has two independent routes to the internet: HTTP, which carried this page, and WebRTC media, which negotiates its own path over UDP. The check asks a public STUN server which address it saw the media path arrive from, asks this site's own edge which address the page arrived from, and compares them. They are two views of one question — where does this browser exit? — resolved by two independent stacks. When they disagree, media is not following the route the page took: a proxy or VPN configured only for HTTP leaves WebRTC to find its own way out, and any page running the same few lines of JavaScript reads the address underneath it. The comparison is deliberately confined to a single address family, because a dual-stack machine legitimately reaches STUN over IPv6 while fetching the page over IPv4, and calling that a leak would be wrong. Absence of a reflexive candidate is neither pass nor failure but a missing measurement — symmetric NAT, a UDP-blocking firewall, or a WebRTC-blocking extension each produce it. This row is reported but NEVER SCORED, and the reason is worth stating plainly: it is a fact about network topology rather than two sources contradicting each other, and from inside the page the ordinary case and the interesting case are the same shape. A corporate laptop behind an enterprise proxy or a cloud security gateway proxies HTTP only and lets media go out over raw UDP — a public HTTP address and a different public UDP address — which is indistinguishable from a proxied session leaking its real egress. No client-side test separates them, and an ASN or subnet heuristic would silence the genuine leak along with the false alarm. So the finding is shown in full and left for you to judge, rather than counted against a stock browser on a managed network.
How to resolve it
Route UDP through the same egress as HTTP so both paths share an exit. Where that is not possible, force WebRTC to relay-only — an ICE transport policy of 'relay' suppresses server-reflexive candidates entirely, so no direct address is ever offered. Disabling WebRTC outright also closes the gap, at the cost of a browser that cannot place calls, which is itself a mild oddity a site can notice.
Nearby checks in Network & WebRTC
- 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. - The WebRTC host candidate does not expose a routable public address
webrtc-address-classReading from the same fully offline RTCPeerConnection — built with no iceServers, so host-only gathering, no STUN, no packets — the first… - 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-ip-vs-connection belongs to.