WebRTC Leak Test
WebRTC lets web pages set up direct connections, and to do that the browser gathers its own addresses. This test shows what a page could learn that way.
The test asks Cloudflare's public STUN server (stun.cloudflare.com, port 3478) for the address it sees, as a video-call page would. Cloudflare therefore sees your address; nothing is sent to our server.
WebRTC lets a web page open direct audio, video and data connections, the technology behind browser video calls. To find a direct path between two devices, the browser gathers candidates: its local addresses, and its public address as seen by a STUN server on the internet.
Before 2019, any page could read your local network addresses this way. Modern browsers hide them behind random .local names (mDNS), so a page sees something like 8f3c….local instead of 192.168.1.23.
The public address is the interesting part for VPN users. Normally it is the same address every website sees. If the VPN only tunnels some traffic, WebRTC can reveal the address of your real connection. This test gathers candidates exactly as a call would, using Cloudflare’s public STUN server, and compares the public address with the one this page sees.
Frequently asked questions
Who sees my address during the test?
Cloudflare's STUN server (stun.cloudflare.com), which has to see an address to report it, just as in any video call. Nothing from the test is sent to our server.
How do I stop a WebRTC leak?
Use a VPN app that routes all traffic, including UDP, through the tunnel; many have a WebRTC or leak-protection setting. Firefox can disable WebRTC entirely (media.peerconnection.enabled in about:config).
The test shows an IPv6 address I did not expect.
Some VPNs tunnel only IPv4. If WebRTC shows a public IPv6 address from your own provider, your IPv6 traffic bypasses the VPN.