relay-forced WebRTC exits the same address this page arrived from
Check id webrtc-turn-egress
What an ordinary browser yields
The address the relay-forced UDP comes from is the address the page arrived from. A browser that emits no hole-punch at all is reported separately as N/A: that closes the vector, but it is not a comparison and must not read as one.
What a detector infers
Every other WebRTC check on this page reads what the browser is willing to show it. This one reads what the browser DOES, because in the configuration that matters the page is structurally blind. When a site sets iceTransportPolicy to relay, the browser is forced to reach a TURN server, and the only candidate it exposes back to the page is the TURN server's own allocated address — never the address the packet left from. That asymmetry is the whole technique, and it is not theoretical: measured directly against our own endpoint, a real Chrome reported ZERO relay candidates to the page while the server recorded its true public address in the same second. A check that read the candidate list would have concluded nothing happened at the exact moment the address was handed over. So the measurement requires being the operator. The probe mints a token over HTTPS, which is when the service learns the address the page arrived from; the browser is then pointed at that service as a TURN server with the token as its USERNAME; and the service reports which address the UDP actually came from. Two egress paths, one question: do they agree. The token is what makes it a measurement rather than an observation — without a proper credential challenge carrying REALM and NONCE the browser never sends USERNAME at all, and the server can see a packet without being able to prove whose it was. The service never allocates a relay: it answers the challenge and refuses, because a server that really relays is an open relay and is abused within hours, and the source address is present on the Allocate request before any allocation exists. Severity is info and it is never scored, for the same reason as the STUN check — a corporate gateway that proxies HTTP but not UDP produces a shape identical to a genuine unmasking, and no client-side signal separates them.
How to resolve it
Route WebRTC's UDP through the same egress as HTTP, or stop it leaving. Relay-only is NOT a fix and is worth being explicit about, because it is widely believed to be one: it suppresses the candidate the page can read while still handing the address to the TURN server, which is the party that matters. An HTTP or SOCKS proxy does not carry UDP, so a proxied session whose WebRTC still reaches the network is unmasked by any site that asks.
Read in the wild by
Verisoul
A fraud-detection vendor whose client script forces relay-only WebRTC against its own TURN servers, tagging the attempt with a short-lived token so the backend can bind the observed UDP source address to that page load, then tearing the connection down seconds later. The design is what this check reproduces.
iceTransportPolicy: "relay" + stun_token / cf_token, connection closed ~2000ms after setLocalDescription
Every attribution traces to a published artifact. See the sources and their limits.
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. - 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-turn-egress belongs to.