A server-reflexive candidate only appears when a STUN server answered
No srflx candidate with no ICE servers, and none with a STUN server that never answers (severity: warn).
What a detector infers
A server-reflexive (srflx) ICE candidate is the public address a STUN server reports back in its reply to a binding request. Chromium's WebRTC stack creates one in exactly one place, when a binding request succeeds (stun_port.cc), and Chrome has no default ICE servers. So with no STUN server configured, or with one that never answers, a srflx candidate cannot exist.
The probe gathers candidates twice: once with an empty iceServers list, and once pointed at a reserved documentation address that nothing answers on. Measured on Chrome and Edge on Windows, Linux Chrome, Playwright and chrome-headless-shell: no srflx in either case. A candidate list that has one anyway was written rather than gathered — the shape produced when a configured public address is inserted into WebRTC's output instead of being discovered through a STUN exchange.
It complements webrtc-srflx-without-host, which needs a host candidate behind every reflexive one; this row needs a STUN reply behind it. No ordinary configuration is known to produce the failing shape.
How to resolve it
Use a real STUN exchange. If WebRTC should show a particular public address, route its UDP traffic through that address so a STUN server reports it; inserting the address into the candidates produces reflexive candidates with no server behind them. Keeping the public address out of WebRTC altogether is also coherent.
Nearby checks in Network & WebRTC
- navigator.connection.downlink sits on Chrome's 50 kbps grid, capped at 10
downlink-on-50kbps-gridnavigator.connection.downlink is not a raw measurement. Blink's NetworkStateNotifier multiplies the network-quality estimate by a per-host… - Every server-reflexive address is one the STUN server actually handed out
srflx-was-seen-by-stunA server-reflexive candidate exists only after a STUN server received a binding request from that public address and replied with it. - Emoji come from the claimed OS's emoji font
emoji-font-vs-osEmoji are drawn from the operating system's colour emoji font, and the fonts differ in a way measureText can see without rendering a pixel. - Canvas text is anti-aliased the way the claimed OS rasterises it
glyph-aa-levels-vs-osCanvas text is rasterised by the platform's font engine, and the engines leave different fingerprints in the alpha channel. - The default monospace font is the claimed OS's
monospace-default-vs-osThe generic monospace family resolves to a font the platform chooses. - The JS heap ceiling fits the memory the browser reports
heap-ceiling-vs-device-memorynavigator.deviceMemory and V8's heap ceiling, performance.memory.jsHeapSizeLimit, look unrelated but are computed from the same number: the… - 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.
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 srflx-only-from-answering-stun belongs to.