STUN
STUN is the protocol WebRTC uses to discover your public IP and port through NAT. It is the mechanism behind most WebRTC IP leaks.
What STUN is
Session Traversal Utilities for NAT is a small protocol with one main job: tell a device what its own address looks like from the outside. A device behind NAT only knows its private address, such as 192.168.1.20. It sends a short UDP packet to a STUN server on the internet; the server replies with the public address and port it saw the packet come from. The device now knows its "server-reflexive" address and can tell a peer where to send traffic.
STUN servers are public, free, and run by many organizations. They keep no state and see only the address of whoever asked.
Why it matters
WebRTC uses STUN to gather connection candidates before a call or data channel is set up. Any web page can create a WebRTC connection object and start that gathering with a few lines of JavaScript, no permission prompt required. The candidate list then contains the public address that the STUN server reported. If that address differs from the one your proxy presents, the page has learned your real address, which is the classic WebRTC leak.
The reason a browser proxy does not help is that STUN runs over UDP straight from the operating system. HTTP and SOCKS proxies configured in the browser only handle TCP connections the browser opens itself. A full-device VPN does catch STUN traffic, as long as it tunnels all interfaces; a leak through a VPN usually means split tunneling or a second active interface.
How to check
The WebRTC leak test performs STUN candidate gathering in your browser and lists the public addresses that come back, flagging any that differ from your connection's address. The IP leak test includes the same check alongside the DNS and IPv6 tests.
How to fix it
Disable WebRTC, restrict ICE candidates to the default route (a policy option in Chromium-based browsers, and the behavior of several privacy extensions), or use an antidetect browser mode that replaces the STUN result with the proxy's address. SOCKS5 proxies with UDP support can carry STUN traffic if the application routes it through them, but browsers do not.
A common misconception
STUN is not a vulnerability; it is doing exactly what it was designed for. The exposure comes from letting any page trigger it silently. Blocking STUN servers at the firewall stops the leak and also breaks video calling, which is the trade-off to weigh.