WebRTC-læktest
WebRTC lader websider oprette direkte forbindelser, og for at gøre det indsamler browseren sine egne adresser. Testen viser, hvad en side kan få at vide på den måde.
Testen spørger Cloudflares offentlige STUN-server (stun.cloudflare.com, port 3478) om den adresse, den ser, som en side til videoopkald ville gøre. Cloudflare ser derfor din adresse; intet sendes til vores server.
Denne tekst findes endnu ikke på dansk. Den vises på engelsk, indtil en oversættelse er udgivet.
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.
Ofte stillede spørgsmål
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.