STUN is one of the quieter, less-discussed pieces of WebRTC's plumbing — and it's specifically the mechanism responsible for a browser learning what public address it's reachable at, which is directly relevant to how WebRTC leaks happen.
The specific problem STUN solves
Most devices sit behind NAT (see Public IP vs Private IP), meaning they don't inherently know their own public-facing address — only their local, private one. Before two browsers can attempt a direct connection, each needs to learn what address the outside world would actually use to reach it.
How the STUN request works
Your browser sends a simple request to a STUN server, which replies with the public IP address and port the request appeared to come from — the address your NAT/router presented to the outside internet. This "server-reflexive" address becomes one of the candidate addresses WebRTC offers when negotiating a connection with the other peer.
What STUN does not do
STUN's job ends at address discovery — it does not relay the actual call audio, video, or data once a connection is established. That's a separate concern, handled either by a direct peer-to-peer path (if one worked) or by a TURN relay server (as a fallback when direct connection fails, common with more restrictive NAT configurations).
Why this matters for leak testing
Because STUN's specific job is revealing your public address, and this process runs independently of your regular HTTP traffic, it's exactly the mechanism a WebRTC Leak Test checks — comparing what STUN reveals against what your VPN shows for ordinary traffic.
FAQ
Is STUN itself a privacy risk?
STUN is doing exactly what it's designed to do — the privacy consideration is really about whether that discovered address bypasses a VPN that's supposed to be hiding it, not about STUN malfunctioning.