WebRTC-Leak-Test

Was ein WebRTC-Leak ist

WebRTC ist die Browser-Technik hinter Videoanrufen, Bildschirmfreigabe und direkter Dateiübertragung zwischen zwei Nutzern auf Websites wie Google Meet und Discord. Um zwei Menschen direkt zu verbinden, muss der Browser jede Adresse herausfinden, unter der er erreichbar sein könnte. Dafür schickt er eine winzige Anfrage an einen STUN-Server, der mit der öffentlichen Adresse antwortet, von der die Anfrage bei ihm ankam. Diese Adressen – ICE-Kandidaten genannt – reicht der Browser dann an das JavaScript der Webseite weiter.

Für Anrufe ist das nützlich, für den Datenschutz ein Problem. Jede Seite kann diesen Vorgang unbemerkt starten, ohne Berechtigungsabfrage und ohne Kamera oder Mikrofon. Verlässt die STUN-Anfrage deinen Computer außerhalb des VPN-Tunnels, erfährt die Seite die Adresse, die dir dein Internetanbieter zugeteilt hat, und nicht die, die dein VPN anzeigt. Das ist ein WebRTC-Leak: Die Website sieht zwei Adressen, und eine davon ist genau die, die du verbergen wolltest.

So nutzt du den Test

1. Verbinde dein VPN oder deinen Proxy so, wie du normalerweise surfst, und öffne dann diese Seite.
2. Warte auf das Ergebnisfeld oben. Der Test startet von selbst, und die Zeile Test läuft wird durch einen einzeiligen Befund mit kurzer Erklärung ersetzt.
3. Halte unter Verglichene Adressen die Zeile Deine Verbindung (HTTP) gegen Öffentliche IP über WebRTC. Die Zeile Verwendeter STUN-Server zeigt, welcher Server deinem Browser geantwortet hat.
4. Sieh dir die Tabelle der ICE-Kandidaten an. Typ sagt, woher ein Kandidat stammt (host ist dein Gerät, srflx ist das, was der STUN-Server gesehen hat, relay ist ein TURN-Server), und Art sagt, ob die Adresse öffentlich ist, in deinem lokalen Netz liegt, hinter Carrier-NAT steckt oder hinter einem .local-Namen verborgen ist.
5. Hast du eine Browser-Einstellung oder Erweiterung geändert, klicke auf Test wiederholen. Hast du das VPN selbst ein- oder ausgeschaltet, lade stattdessen die Seite neu: Die HTTP-Adresse wird nur einmal gelesen, beim Laden der Seite.

Führe den Test einmal ohne VPN aus und notiere dir die Adresse, die dein Anbieter dir gibt. Genau diese Adresse sollte nie mehr auftauchen, sobald der Tunnel steht.

Anwendungsfälle

• Ein VPN prüfen, bevor du dich darauf verlässt. Bei aktivem Tunnel sollte die öffentliche WebRTC-Adresse mit der HTTP-Adresse übereinstimmen oder ganz fehlen. Eine abweichende Adresse derselben Adressfamilie ist das Ergebnis, bei dem du handeln solltest.
• Eine Proxy-Erweiterung testen. Proxy-Erweiterungen im Browser leiten normale Seitenanfragen um, aber die STUN-Anfrage läuft über UDP und kann direkt über deinen Anbieter ins Netz gehen, solange der Browser nicht angewiesen ist, sie zu blockieren.
• Eine IPv6-Lücke finden. Manche VPN-Konfigurationen tunneln IPv4 und lassen IPv6 unberührt. Der Befund lautet dann, dass WebRTC auch deine IPv6-Adresse verrät.
• Eine verwaltete Browser-Richtlinie überprüfen. IT-Abteilungen, die WebRTC auf Firmen-Laptops einschränken, können die Seite auf einem Testgerät öffnen und kontrollieren, ob die Kandidatentabelle nur zeigt, was die Richtlinie zulassen soll.
• Eine WebRTC-App in einem restriktiven Netz debuggen. Listet die Tabelle host-Kandidaten, aber keinen srflx, ist UDP zum STUN-Server auf Port 3478 wahrscheinlich blockiert, und Anrufe in diesem Netz brauchen ein TURN-Relay.

So funktioniert dieser Test

1. Dein Browser lädt diese Seite über deine normale Verbindung, also sieht unser Server eine öffentliche Adresse – oben angezeigt als Deine Verbindung (HTTP).
2. Die Seite baut eine WebRTC-Verbindung auf, die nie jemanden anruft, und fragt den öffentlichen STUN-Server von Cloudflare (stun.cloudflare.com), welche Adresse er sieht.
3. Wir listen jeden Kandidaten auf, den dein Browser erzeugt hat, und vergleichen die öffentlichen mit der HTTP-Adresse. Das alles passiert in deinem Browser; zurück an uns geht davon nichts.

So liest du das Ergebnis

• Kein Leak: WebRTC meldet dieselbe öffentliche Adresse wie deine Verbindung oder gar keine. Nutzt du ein VPN, deckt es WebRTC ab.
• Leak: WebRTC meldet eine andere öffentliche Adresse desselben Typs (IPv4 gegenüber IPv4). Bei eingeschaltetem VPN ist diese zweite Adresse fast immer deine echte.
• Anderes Protokoll sichtbar: Du bist über IPv6 verbunden, und WebRTC zeigt zusätzlich eine IPv4-Adresse, oder umgekehrt. Bei einem normalen Heimanschluss gehören beide dir. Bei einem VPN, das nur ein Protokoll tunnelt, läuft das andere am Tunnel vorbei.
• Lokale Adresse sichtbar: Eine Adresse wie 192.168.x.x oder 10.x.x.x bedeutet, dass dein Browser die Adresse deines Geräts im Heimnetz weitergibt. Aktuelle Versionen von Chrome, Edge, Firefox und Safari verbergen sie standardmäßig hinter einem zufälligen .local-Namen.

So stoppst du einen WebRTC-Leak

• Nutze die App deines VPN, nicht nur die Browser-Erweiterung. Ein systemweites VPN leitet den STUN-Verkehr durch den Tunnel; eine Proxy-Erweiterung tut das oft nicht.
• Schalte den WebRTC-Leak-Schutz ein, falls deine VPN-App oder -Erweiterung einen hat.
• Firefox: Öffne about:config und setze media.peerconnection.enabled auf false, um WebRTC komplett abzuschalten – oder lass es an und verlass dich auf das VPN.
• Chrome und Edge: Einen eingebauten Schalter gibt es nicht; nutze eine seriöse Erweiterung, die die WebRTC-Richtlinie für den Umgang mit IP-Adressen auf „Disable non-proxied UDP“ setzt (UDP, das nicht über den Proxy läuft, deaktivieren).
• Brave: Einstellungen → Datenschutz und Sicherheit → WebRTC-IP-Nutzungsrichtlinien → „Nicht-proxisiertes UDP deaktivieren“.
• Safari: Leaks sind selten, weil Safari ICE-Kandidaten standardmäßig einschränkt.

Führe den Test nach jeder Änderung erneut aus. Denk daran, dass Anrufe im Browser nicht mehr funktionieren, wenn du WebRTC abschaltest – repariere deshalb lieber das VPN, statt die Funktion zu deaktivieren.

Was dieser Test nicht verrät

Ein sauberes Ergebnis gilt nur für WebRTC. Deine DNS-Anfragen, Zeitzone und Sprache deines Browsers sowie dein Fingerprint sind eigene Kanäle; die Startseite prüft, ob Zeitzone und Sprache zur IP passen, und der Fingerprint-Test deckt den Rest ab. Einen DNS-Leak-Test bieten wir nicht an, weil er einen eigenen DNS-Server bräuchte – und wir wollen nichts vortäuschen.

Häufige Fragen

Dieser Test prüft einen einzigen Leak-Kanal zu dem Zeitpunkt, an dem du ihn ausführst. Die Ergebnisse hängen von deinem Browser, deinen Erweiterungen und deinem Netz ab und können sich ändern, sobald sich eines davon ändert. Er ist keine Sicherheitsprüfung deines VPN.