Design

Beliebte Tools

WebRTC Leak Test

WebRTC kann einer Website Adressen geben, die Ihr Browser sonst nicht schicken würde – auch die hinter Ihrem VPN. Dieser Test fragt drei STUN-Server von Cloudflare und Google, zeigt jede Adresse, die zurückkam, und was sie ist, und vergleicht sie mit der Adresse, die eine Website ohnehin sieht. Kann er etwas nicht testen, sagt er das, statt Ihnen einen grünen Haken zu zeigen.

Läuft in Ihrem Browser gegen STUN von Cloudflare und Google · nichts wird gespeichert · Kandidatentypen nach RFC 8445

Testen Sie einmal mit ausgeschaltetem VPN und einmal mit eingeschaltetem. Der Unterschied ist die Antwort.

Ihr Browser fragt drei STUN-Server von Cloudflare und Google, welche Adresse sie sehen. Keine Adresse, die WebRTC findet, wird an uns gesendet.

Was eine Website ohnehin siehtIPv4IPv6Ihre Verbindung wird ermittelt…
Jede Adresse, die WebRTC geliefert hat

  1. Jede Adresse, die WebRTC liefert, erscheint hier in einer eigenen Zeile, sobald die STUN-Server antworten.

Keine Adresse, die WebRTC findet, wird an uns gesendet. Ihr Browser fragt die STUN-Server selbst, wie bei jedem Videoanruf. Um zu zeigen, was eine Website sieht, fragt die Seite ipify.org und unseren eigenen Server nach Ihren Adressen und deren Netzen, so wie der DNS-Leak-Test.

Was ist ein WebRTC-Leak?

WebRTC ist die Browserfunktion hinter Videoanrufen. Um zwei Menschen direkt zu verbinden, sammelt sie jede Adresse, unter der Ihr Rechner erreichbar ist, und bietet sie der Seite an – auch Adressen, die Ihr Browser bei einer gewöhnlichen Anfrage nie schicken würde.

Dieses Sammeln von ICE-Kandidaten ist in RFC 8445 festgelegt. Ihr Browser listet die Adressen Ihrer eigenen Netzwerkschnittstellen auf, fragt dann einen STUN-Server „Von welcher Adresse aus sehen Sie mich?“ und fügt auch diese hinzu. Jede Seite im Internet kann das mit ein paar Zeilen JavaScript starten und jeden Kandidaten lesen, sobald er eintrifft, ohne Berechtigungsabfrage – so ist es gewollt, denn ein Anruf muss ohne eine funktionieren.

Zum Leak wird es, wenn eine dieser Adressen etwas ist, das Sie verbergen wollten. Ein VPN ändert den Weg, den die Anfragen Ihres Browsers nehmen, aber WebRTC kann das Betriebssystem nach jeder Schnittstelle fragen; auf einem Rechner, dessen physische Verbindung noch besteht, kann die echte Adresse also neben der des VPN auftauchen. Dabei ist nichts schiefgegangen: Die Funktion tut genau das, wofür sie gebaut wurde.

Was jede Seite starten kannein Sammeln, Schritt für Schritt

IHR GERÄTDAS INTERNETIhr Router (NAT)Skript der SeiteIhr BrowserSTUN-Serverstun.cloudflare.comnew RTCPeerConnection()keine Berechtigungsabfragelistet jede Netzwerkschnittstelle auf192.168.1.20 → 8b7f4e2a-….localVon welcher Adresse aus sehen Sie mich?192.168.1.20:54400203.0.113.7:54400203.0.113.7:54400die Adresse, die er gesehen hatjeden Kandidaten, sobald er eintrifftonicecandidateIHR GERÄTDAS INTERNETSkript der SeiteIhr BrowserSTUN-Servernew RTCPeerConnection()keine Berechtigungsabfragelistet jede Netzwerkschnittstelle auf192.168.1.20 → 8b7f4e2a-….localVon welcher Adresse aus sehen Sie mich?192.168.1.20203.0.113.7203.0.113.7:54400die Adresse, die er gesehen hatjeden Kandidaten, sobald er eintrifftonicecandidateIhr Router (NAT)

Das ganze Skript

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.cloudflare.com:3478" }],
});
pc.createDataChannel("");
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate);
await pc.setLocalDescription(await pc.createOffer());

Was es ausgegeben hat

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0candidate:1467250027 1 udp 1686052607 203.0.113.7 54400 typ srflx raddr 0.0.0.0 rport 9 generation 0

Was jede Zeile ist

  • hostAuf diesem Rechner8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.localVon Ihrem Browser maskiert
  • srflxVon einem STUN-Server gesehen203.0.113.7Im Internet routbar
Ein Sammeln an einem Heimanschluss, mit Dokumentationsadressen. Die private Adresse verlässt den Browser nie unverändert; der STUN-Server sieht die öffentliche Seite des Routers, nicht den Rechner, und beide Antworten gehen an das Skript, das gefragt hat.
Ergebnis des WebRTC-Leak-Tests: jeder ICE-Kandidat mit seinem Typ, der Art jeder Adresse und dem ErgebnisErgebnis des WebRTC-Leak-Tests: jeder ICE-Kandidat mit seinem Typ, der Art jeder Adresse und dem ErgebnisDas ErgebnisLeak, Kein Leak oder – ehrlich – Nicht getestet, mit dem Grund.Jede AdresseMit ihrem Kandidatentyp, denn ein Host-Kandidat bedeutet etwas anderes als ein reflexiver.Was sie istPrivat, Carrier-Grade-NAT, ein Tunnel oder routbar. Nur eine routbare Adresse kann ein Leak sein.Die ServerJeder STUN-Server in einer eigenen Zeile. Ein Server, der nichts gesagt hat, ist ein Test, der nicht gelaufen ist.Was eine Website siehtDie Adressen, die Ihr Browser ohnehin schickt; mit ihnen werden die WebRTC-Adressen verglichen.
Ein Testdurchlauf: was jeder STUN-Server geantwortet hat, jede Adresse, die WebRTC offengelegt hat, welche Art Adresse es ist und ob die Website sie ohnehin sieht. Wählen Sie eine Nummer, um zu sehen, was der jeweilige Teil zeigt.

So prüfen Sie auf ein WebRTC-Leak

Starten Sie den Test oben. Er sammelt Kandidaten von drei STUN-Servern, ermittelt, was jede Adresse ist, und vergleicht die routbaren mit der Adresse, die eine Website ohnehin sieht.

Drei Ergebnisse sind möglich, nicht zwei. Kein Leak heißt, dass die Website jede routbare Adresse, die WebRTC geliefert hat, schon hat. Leak heißt, dass sie mindestens eine davon nicht hat – oder dass eine Adresse Ihres eigenen Rechners direkt angeboten wurde. Nicht getestet heißt, dass WebRTC ausgeschaltet oder blockiert ist oder kein STUN-Server geantwortet hat, und genau dieses Ergebnis machen die meisten Tools stillschweigend zu einem Bestanden.

Testen Sie zweimal, wenn Sie ein VPN nutzen: einmal ausgeschaltet, um Ihre gewöhnlichen Adressen zu sehen, einmal eingeschaltet. Der zweite Durchlauf ist der entscheidende, und der Unterschied zwischen beiden ist die Antwort. Die Seite behält das erste Ergebnis, sodass Sie vergleichen können, ohne etwas aufzuschreiben.

Drei Ergebnisse, nicht zweiwas jedes bedeutet

  1. Kein Leak

    Jede routbare Adresse, die WebRTC geliefert hat, hat eine Website schon.

    WebRTC lieferte

    • 198.51.100.23Von einem STUN-Server gesehenVon Websites schon gesehen
    • 8b7f4e2a-….localAuf diesem RechnerVon Ihrem Browser maskiert

    Eine Website sieht

    198.51.100.23
  2. Leak

    Mindestens eine Adresse hat die Website noch nicht, oder eine Adresse Ihres eigenen Rechners wurde direkt angeboten.

    WebRTC lieferte

    • 198.51.100.23Von einem STUN-Server gesehenVon Websites schon gesehen
    • 2001:db8:4a1f:7c00::1cAuf diesem RechnerVon Websites nicht gesehen

    Eine Website sieht

    198.51.100.23
  3. Nicht getestet

    WebRTC ist aus oder blockiert, oder kein STUN-Server hat geantwortet. Es wurde nichts gemessen.

    stun.cloudflare.comKeine Antwort

    stun.l.google.comKeine Antwort

    Was die meisten Tools hier zeigenKein Leak

Zweimal testen

VPN aus

WebRTC lieferte203.0.113.7

Eine Website sieht203.0.113.7

Kein Leak

VPN an

WebRTC lieferte198.51.100.23203.0.113.7

Eine Website sieht198.51.100.23

Mit VPN noch da

Leak
Jedes Ergebnis mit einem Durchlauf, der es erzeugt. Mit ausgeschaltetem VPN ist die Adresse von WebRTC dieselbe wie die der Website; mit eingeschaltetem sollten sich beide ändern, und eine, die bleibt, ist die Antwort.

Verhindert ein VPN ein WebRTC-Leak?

Nicht von allein. Ein VPN ändert, wohin Ihr Datenverkehr geht; WebRTC kann Ihr Betriebssystem fragen, welche Schnittstellen es gibt, und die physische ist meist noch da.

Die IETF beschreibt es selbst genau: „Versucht der Client, seinen physischen Standort über ein Virtual Private Network (VPN) zu verbergen, und unterstützen VPN und lokales Betriebssystem das Routing über mehrere Schnittstellen, kann WebRTC nicht nur die öffentliche Adresse des VPN entdecken, sondern auch die öffentliche Adresse des ISP, über den das VPN läuft.“ Beide Adressen werden angeboten, und eine Seite, die danach sucht, kann beide lesen.

Manche VPN-Clients schließen die Lücke, indem sie den gesamten Datenverkehr auf Betriebssystemebene routen oder eine Browsererweiterung mitliefern, die WebRTC einschränkt. Beides funktioniert, und beides sollten Sie prüfen statt voraussetzen – genau dafür ist diese Seite da. Ein VPN, dessen eigene Leak-Test-Seite Ihnen sagt, Sie seien geschützt, ist kein unabhängiger Beleg.

VPN an, WLAN noch aktivzwei Schnittstellen, zwei Antworten

Ihr LaptopVPN10.64.0.2WLAN192.168.1.20VPN-TUNNELVPN-Server198.51.100.23WebsiteIhr SurfenSTUN-ServerRouter (NAT)Ihr Anbieter203.0.113.7WebRTC fragt über beideIhr LaptopVPN10.64.0.2WLAN192.168.1.20VPN-TUNNELVPN-Server198.51.100.23Router (NAT)Ihr Anbieter203.0.113.7Ihr SurfenWebsiteSTUN-ServerWebRTC fragt über beide

Was die Seite bekommt

  • 198.51.100.23srflxVon einem STUN-Server gesehenüber das VPNVon Websites schon gesehen
  • 203.0.113.7srflxVon einem STUN-Server gesehenüber das WLAN, außerhalb des TunnelsVon Websites nicht gesehen

RFC 8828

Was die Lücke schließt

  • Routing auf BetriebssystemebeneNichts verlässt das Gerät außerhalb des Tunnels, also kann ein STUN-Server nur die Adresse des VPN sehen.
  • Die Browsererweiterung des VPNSie schränkt WebRTC im Browser ein, sodass die andere Schnittstelle nie gefragt wird.
  • Dann prüfen, nicht voraussetzenStarten Sie diesen Test mit eingeschaltetem VPN. Die eigene Leak-Test-Seite eines VPN ist kein unabhängiger Beleg.
Der Fall, den die IETF in RFC 8828 beschreibt: VPN und Betriebssystem routen über mehr als eine Schnittstelle, also findet WebRTC die öffentliche Adresse des VPN und darunter die Adresse des Anbieters.

Host, server-reflexiv und Relay: Welcher Kandidat ist welcher?

Ein Host-Kandidat ist eine Adresse auf Ihrem eigenen Rechner. Ein server-reflexiver ist das, was ein STUN-Server gesehen hat – die öffentliche Seite Ihres NAT. Ein Relay-Kandidat ist die Adresse eines TURN-Servers, nicht Ihre.

Der Unterschied zählt, und die meisten Leak-Tests werfen ihn weg. Ein server-reflexiver Kandidat mit Ihrer öffentlichen IPv4 ist meist nichts Neues: Es ist dieselbe Adresse, die die Website von der Verbindung bekommt, die Sie ohnehin aufbauen. Ein Host-Kandidat mit einer routbaren Adresse ist etwas anderes – das ist eine Adresse auf dem Rechner selbst, der Seite direkt angeboten. Sie identifiziert diesen Rechner, nicht nur den Router Ihres Haushalts, und sie ändert sich, wenn sich das Netz ändert.

Die Seite zeigt den Typ neben jeder Adresse, dazu den Transport, den Port und die zugehörige Adresse, die ein reflexiver Kandidat nennt. Ein Relay-Kandidat ist die eigene Adresse des TURN-Servers und verrät nichts über Sie; dieser Test nutzt keinen TURN-Server, ein solcher Kandidat hieße also, dass etwas anderes auf der Seite ihn eingerichtet hat.

Ein Kandidat, Feld für Feldwie eine Seite ihn bekommt

  1. candidate:1467250027Foundation
  2. 1Komponente
  3. udpTransport
  4. 1686052607Priorität
  5. 203.0.113.7Adresse
  6. 54400Port
  7. typ srflxTyp
  8. raddr 0.0.0.0 rport 9Zugehörige Adresse
  9. generation 0Erweiterung

Ausgeblendet als 0.0.0.0, Port 9, wo lokale Adressen maskiert werden

Die vier Typen

  • typ hostAuf diesem Rechner

    Eine Adresse auf einer Ihrer eigenen Netzwerkschnittstellen.

    Eine private wird maskiert. Eine routbare ist das Gerät selbst: der schwerste Befund.

    Am schwersten, wenn routbar

  • typ srflxVon einem STUN-Server gesehen

    Die öffentliche Seite Ihres Routers, wie ein STUN-Server sie gesehen hat.

    Meist die Adresse, die eine Website ohnehin von Ihrer Verbindung hat.

    Meist nichts Neues

  • typ prflxVon der Gegenseite gesehen

    Die öffentliche Seite Ihres Routers, wie das andere Ende eines Anrufs sie gesehen hat.

    Erst beim Verbinden mit der Gegenseite gefunden, daher sieht ein Test ohne Anruf nie einen.

    Nur während eines Anrufs

  • typ relayEigene Adresse eines Relay-Servers

    Die Adresse eines TURN-Servers, der Datenverkehr für Sie weiterleitet.

    Die Adresse des Servers, nicht Ihre. Dieser Test nutzt keinen TURN-Server, also hat ihn hier etwas anderes eingerichtet.

    Nichts über Sie

Die Adresse des Kandidaten wird mit dem verglichen, was eine Website sieht; sein Typ sagt, wie schwer ein Unterschied wiegt. Definitionen aus RFC 8445, Abschnitt 4.

Was ist eine mDNS-Adresse mit .local, und schützt sie mich?

Moderne Browser ersetzen Ihre privaten Adressen durch einen zufälligen Namen mit der Endung .local, bevor sie sie einer Seite anbieten. Das funktioniert – für private Adressen. Eine öffentliche zu verbergen, war nie vorgesehen.

Chrome tut das seit Version 76 standardmäßig, und in Firefox steht media.peerconnection.ice.obfuscate_host_addresses auf true: Statt 192.168.1.20 bekommt eine Seite etwas wie 8b7f4e2a-….local, das außerhalb Ihres Netzes niemandem etwas sagt. Safari geht weiter: Solange eine Website keine Kamera- oder Mikrofonberechtigung hat, bietet Safari überhaupt keine Host-Kandidaten an. Der Test oben erkennt solche zufälligen Namen und meldet sie als funktionierenden Schutz, nicht als Befund.

Der IETF-Entwurf, der das Verfahren festlegt, sagt ausdrücklich, was es nicht tut: „Eine Adresse, die dem Internet bereits offenliegt, muss nicht durch mDNS geschützt werden, da der Webserver sie ohne Weiteres beobachten kann.“ Ein server-reflexiver Kandidat trägt also weiterhin Ihre öffentliche IPv4, und – der Teil, der viele überrascht – ein Rechner mit einer routbaren IPv6-Adresse kann diese Adresse weiterhin als Host-Kandidat anbieten. Eine Lücke sollten Sie noch kennen: Chrome schaltet den Schutz für jede Website ab, die bereits Kamera- oder Mikrofonberechtigung hat; eine Videoanruf-Website, die Sie schon genutzt haben, sieht also Ihre echten lokalen Adressen.

Was der .local-Name ersetztund was er in Ruhe lässt

Was Ihr Browser hat

candidate:3442447574 1 udp 2122260223 192.168.1.20 54400 typ host generation 0

Was die Seite bekommt

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0

Was jeder Browser standardmäßig tut

  • ChromeSeit Version 76, August 2019
  • Firefoxmedia.peerconnection.ice.obfuscate_host_addresses = true
  • SafariKeine Host-Kandidaten, bis eine Website Kamera- oder Mikrofonberechtigung hat

Das Verfahren ist ein IETF-Entwurf, zuletzt überarbeitet im Dezember 2021 und nie als RFC veröffentlicht. draft-ietf-mmusic-mdns-ice-candidates-03

Eine Adresse, die WebRTC anbieten könnteMaskiert?
192.168.1.20Ihre private IPv4, als Host-KandidatMaskiertDurch einen zufälligen Namen ersetzt: Die Seite erfährt nichts über Ihr Netz.
203.0.113.7Ihre öffentliche IPv4, als Kandidat des STUN-ServersSichtbarSchon öffentlich, also bleibt sie. Nur die zugehörige Adresse wird ausgeblendet.
2001:db8:4a1f:7c00::1cEine routbare IPv6, als Host-KandidatSichtbarEbenfalls öffentlich: Die Maskierung war nie dafür gedacht, sie abzudecken.
2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07Eine temporäre IPv6-AdresseKann sichtbar seinDer Entwurf erlaubt einem Browser, sie nach eigener Wahl unmaskiert zu lassen.
192.168.1.20Jede lokale Adresse, auf einer Website mit Kamera- oder MikrofonberechtigungMaskierung ausChrome schaltet die Maskierung dort ab: Die Website sieht Ihre echten lokalen Adressen.
Die Maskierung verbirgt, was nur Ihr eigenes Netz weiß. Was eine Website ohnehin sehen könnte, lässt sie, wie es ist: absichtlich, nicht aus Versehen.

Warum IPv6 das Leak ist, das bleibt

Eine globale IPv6-Adresse gehört einem einzelnen Rechner statt einem Haushalt hinter NAT, und mDNS lässt sie absichtlich in Ruhe. Sie ist das Identifizierendste, was WebRTC noch herausgibt.

Bei IPv4 stellt das NAT Ihres Heimrouters alles hinter eine Adresse, sodass ein server-reflexiver Kandidat einer Seite ungefähr das sagt, was ihr Ihre gewöhnliche Verbindung ohnehin sagt. IPv6 kennt kein NAT: Jedes Gerät hat seine eigene routbare Adresse, und ein Host-Kandidat, der sie trägt, benennt das Gerät, nicht den Anschluss. Trägt Ihr VPN nur IPv4 – das tun viele –, liegt diese IPv6-Adresse außerdem ganz außerhalb des Tunnels.

Privacy Extensions helfen, weil eine temporäre IPv6-Adresse regelmäßig wechselt. Sie verbergen sie aber nicht: Der mDNS-Entwurf sagt, dass solche Adressen unmaskiert bleiben dürfen. Der Test oben wertet einen routbaren IPv6-Host-Kandidaten als den schwersten Befund, den er finden kann, und der IPv6-Test sagt Ihnen, ob Ihre Verbindung überhaupt IPv6 hat.

Wen eine Adresse benenntdieselben drei Geräte, zweimal

RouterIPv4, hinter NATIPv6, ohne NAT
Laptop192.168.1.202001:db8:4a1f:7c00::1c
Handy192.168.1.212001:db8:4a1f:7c00::2b
TV192.168.1.222001:db8:4a1f:7c00::3d
Router203.0.113.7Eine Adresse für den ganzen AnschlussEine Adresse pro Gerät

Eine globale IPv6-Adresse, in zwei Hälften

2001:db8:4a1f:7c00Netzpräfix: Ihr Anschluss /64:8d3:5e2f:a41c:9b07Interface-ID: dieses Gerät

  • Stabil2001:db8:4a1f:7c00::1c
  • Temporär: wechselt2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07

Ein VPN, das nur IPv4 trägt

  • IPv4198.51.100.23Im Tunnel
  • IPv62001:db8:4a1f:7c00::1cAußerhalb des Tunnels
Hinter IPv4-NAT teilt sich ein Haushalt eine Adresse; bei IPv6 hat jedes Gerät seine eigene, und ein Host-Kandidat bietet sie direkt an. Der Test wertet einen routbaren IPv6-Host-Kandidaten als schwersten Befund.

So stoppen Sie ein WebRTC-Leak in jedem Browser

Firefox hat Einstellungen, die funktionieren. Edge hat eine Unternehmensrichtlinie. Safari schränkt Kandidaten bereits ein. Die Browsererweiterungen, die noch empfohlen werden, bewirken nichts mehr.

In Firefox sendet about:config → media.peerconnection.ice.default_address_only nur eine Adresse statt aller, und media.peerconnection.ice.relay_only beschränkt das Sammeln auf Relay-Kandidaten, was direkte Anrufe bricht, aber alles andere verbirgt. Beide sind standardmäßig aus; die mDNS-Maskierung privater Adressen (media.peerconnection.ice.obfuscate_host_addresses) ist bereits an. In Edge legt die Richtlinie WebRtcLocalIpsAllowedUrls fest, welche Websites lokale Adressen sehen dürfen; Microsofts eigene Dokumentation merkt an, dass das Hinzufügen einer Website „den Schutz schwächt“. Chrome hat für gewöhnliche Nutzer keine vergleichbare Einstellung. Safari ist ungefragt am strengsten: Ohne Kamera- oder Mikrofonberechtigung bietet WebKit nur server-reflexive und Relay-Kandidaten an und überhaupt keine Host-Kandidaten.

Zwei Dinge, die noch oft empfohlen werden, sind tot. Die Option „Prevent WebRTC from leaking local IP addresses“ von uBlock Origin wurde in Version 1.38 entfernt, mit dem Hinweis, sie sei „in modernen Browsern nicht mehr nötig, außer in Firefox für Android“. Und Googles Erweiterung WebRTC Network Limiter, die noch im Store steht, kann nicht laufen: Manifest-V2-Erweiterungen sind seit Chrome 138 im Juli 2025 für alle Chrome-Nutzer deaktiviert. Rät Ihnen eine Seite, eines davon zu installieren, wurde diese Seite seit Jahren nicht aktualisiert.

Was jeder Browser bietetgeprüft an der Dokumentation jedes Herstellers

  • FirefoxEinstellungen, die funktionieren

    about:config

    • media.peerconnection.ice.obfuscate_host_addressesStandard trueMaskiert private Adressen. Bereits an.
    • media.peerconnection.ice.default_address_onlyStandard falseSetzen auf trueSendet eine Adresse statt aller.
    • media.peerconnection.ice.relay_onlyStandard falseSetzen auf trueNur Relay-Kandidaten. Verbirgt am meisten und bricht direkte Anrufe.

  • EdgeUnternehmensrichtlinie

    WebRtcLocalIpsAllowedUrls

    Listet die Websites, die lokale Adressen sehen dürfen.

    Nicht konfiguriert: Lokale Adressen bleiben maskiert.

    Microsofts eigener Hinweis: Eine Website hinzuzufügen schwächt den Schutz.

    Windows und macOS, ab Version 80

  • ChromeKeine Einstellung

    Keine Einstellung für gewöhnliche Nutzer.

    Private Adressen seit Version 76 standardmäßig maskiert.

    Nicht auf einer Website mit Kamera- oder Mikrofonberechtigung.

  • SafariStandardmäßig streng

    Ohne Kamera- oder Mikrofonberechtigung nur STUN-Server- und Relay-Kandidaten.

    Überhaupt keine Host-Kandidaten.

Ratschläge, die nicht mehr funktionieren

  • Prevent WebRTC from leaking local IP addresses

    uBlock Origin

    Entfernt in Version 1.38

    In modernen Browsern nicht mehr nötig, so uBlock Origin, außer in Firefox für Android.

  • WebRTC Network Limiter

    Google · Chrome Web Store

    Noch gelistet, kann nicht laufen

    Manifest-V2-Erweiterungen sind seit Chrome 138 (Juli 2025) für alle Chrome-Nutzer deaktiviert.

Die eigene Dokumentation jedes Herstellers, gelesen an dem Tag, an dem diese Seite geprüft wurde. Eine Seite, die Ihnen noch rät, eines der letzten beiden zu installieren, wurde seit Jahren nicht aktualisiert.

WebRTC-Leak, DNS-Leak und IP-Leak: Was ist der Unterschied?

Es sind drei verschiedene Wege, ein VPN zu umgehen. Ein WebRTC-Leak zeigt eine Adresse; ein DNS-Leak zeigt, wer Ihre Abfragen beantwortet; ein IP-Leak ist der schlichte Fall, in dem Ihr Datenverkehr nie in den Tunnel gelangt ist.

Bei einem WebRTC-Leak geht es um Adressen, die Ihr Browser über eine Funktion freiwillig herausgibt, die genau dafür gebaut ist. Bei einem DNS-Leak geht es darum, welcher Resolver Ihre Abfragen beantwortet: Ihr Datenverkehr kann durch das VPN gehen, während Ihre Abfragen weiterhin beim Resolver Ihres Anbieters landen, der so jede Website erfährt, die Sie besuchen. Unser DNS-Leak-Test prüft das mit unserem eigenen Nameserver und sieht so genau, welche Resolver gefragt haben.

Ein IP-Leak im allgemeinen Sinn ist die Adresse, die eine Website einfach sieht; prüfen können Sie sie unter Meine IP-Adresse oder Mein ISP. Führen Sie nach jeder Änderung am VPN alle drei aus: Sie versagen unabhängig voneinander, und ein sauberes Ergebnis bei einem sagt nichts über die anderen.

Drei Wege um ein VPN herumjeder versagt für sich

SieVPN-TUNNELDurch den TunnelIP-Leak · Ihr DatenverkehrDie Website203.0.113.7DNS-Leak · Ihre AbfragenResolver Ihres Anbieters203.0.113.53WebRTC-Leak · Ihre AdressenSkript der Seite203.0.113.7SieVPN-TUNNELDurch den TunnelIP-LeakIhr DatenverkehrDie Website203.0.113.7DNS-LeakIhre AbfragenResolver Ihres Anbieters203.0.113.53WebRTC-LeakIhre AdressenSkript der Seite203.0.113.7

  • IP-Leak

    Was nach außen gelangtDie Adresse, die jede Anfrage trägt

    Wer es erfährtJede Website, die Sie besuchen

    Prüfen mitMeine IP-AdresseMein ISP

  • DNS-Leak

    Was nach außen gelangtWelcher Resolver Ihre Abfragen beantwortet

    Wer es erfährtIhr Anbieter, für jede Website, die Sie abfragen

    Prüfen mitDNS-Leak-Test

  • WebRTC-Leak

    Was nach außen gelangtAdressen, die Ihr Browser einer Seite anbietet

    Wer es erfährtJede Seite, die danach fragt, ohne Berechtigungsabfrage

    Prüfen mitWebRTC-Leak-Test

Sie versagen unabhängig voneinander: Ein sauberes Ergebnis bei einem sagt nichts über die anderen beiden. Führen Sie nach jeder Änderung an Ihrem VPN alle drei aus.

Warum dieser Test mehr als einen STUN-Server fragt

Weil „keine Adresse kam zurück“ und „es gibt keine Adresse“ gleich aussehen und nur eines davon eine gute Nachricht ist.

Eine Firmen-Firewall, ein restriktives VPN oder ein Netz, das UDP blockiert, kann verhindern, dass ein STUN-Server antwortet. Ein Test, der einen einzigen Anbieter fragt und nichts sieht, hat nichts gelernt – trotzdem wird dann meist ein grüner Haken gezeigt. Dieser Test fragt den dokumentierten STUN-Endpunkt von Cloudflare und den von Google, meldet jeden einzeln und meldet „Nicht getestet“, wenn keiner geantwortet hat.

Die Wahl der Server ist bewusst. Cloudflare veröffentlicht stun.cloudflare.com:3478 als Teil eines Produkts, es gibt also Bedingungen zum Nachlesen. Googles stun.l.google.com:19302 ist nur als Voreinstellung von Googles eigenem WebRTC-Validator dokumentiert, ohne veröffentlichte Bedingungen, und dient daher als zweite Meinung statt als einzige Quelle. Der Server von Twilio braucht Zugangsdaten, und Mozilla dokumentiert keinen öffentlichen STUN-Server, so oft auch einer zitiert wird.

Öffentliche STUN-Serverund welche dieser Test fragt

  • CloudflareGefragt

    stun.cloudflare.com:3478

    Ein dokumentierter Endpunkt, Teil eines Produkts, mit Bedingungen zum Nachlesen.

  • GoogleGefragt, als zweite Meinung

    stun.l.google.com:19302

    Nur als Voreinstellung von Googles eigenem WebRTC-Validator dokumentiert. Keine veröffentlichten Bedingungen.

  • TwilioNicht gefragt

    global.stun.twilio.com:3478

    Braucht Zugangsdaten aus der API von Twilio: nicht für jede Seite offen.

  • MozillaNicht gefragt

    Kein öffentlicher Server

    Dokumentiert keinen öffentlichen STUN-Server. Firefox wird ganz ohne voreingestellte ICE-Server ausgeliefert.

Wenn ein Server nichts sagt

CloudflareGoogle
GeantwortetGeantwortetDas Ergebnis steht
GeantwortetStummDas Ergebnis steht; der stumme Server wird genannt
StummGeantwortetDas Ergebnis steht; der stumme Server wird genannt
StummStummNicht getestet
Zwei Betreiber, getrennt gefragt. Ein stummer Server wird genannt, und das Ergebnis steht; antwortet keiner, wurde nichts gemessen, und der Test sagt das, statt ein Bestanden zu zeigen.

Ist meine IP-Adresse ein personenbezogenes Datum?

In der EU ist eine dynamische IP-Adresse ein personenbezogenes Datum für einen Websitebetreiber, der Sie mithilfe der Informationen Ihres Anbieters identifizieren könnte. Der Gerichtshof der EU hat das 2016 entschieden.

Der Fall heißt Breyer, C-582/14, entschieden am 19. Oktober 2016, und die Pressemitteilung des Gerichtshofs fasst ihn so zusammen: „Die dynamische Internetprotokoll-Adresse eines Nutzers stellt für den Betreiber der Website ein personenbezogenes Datum dar, wenn er über rechtliche Mittel verfügt, die es ihm erlauben, den betreffenden Nutzer anhand der Zusatzinformationen, über die dessen Internetzugangsanbieter verfügt, bestimmen zu lassen.“ Dieselbe Pressemitteilung hält fest, dass eine Website ein berechtigtes Interesse daran haben kann, einiges davon zu speichern, um sich gegen Angriffe zu verteidigen.

Genau deshalb erledigt diese Seite ihre Arbeit in Ihrem Browser. Die ICE-Kandidaten werden von Ihrem Browser gesammelt, in Ihrem Browser verglichen und Ihnen angezeigt; keine Adresse, die WebRTC findet, wird an uns gesendet, also gibt es davon nichts, was wir speichern, herausgeben oder verlieren könnten. Sie können den Netzwerk-Tab Ihrer Entwicklertools beobachten, während der Test läuft.

Das Breyer-UrteilGerichtshof der Europäischen Union

C-582/14Breyer v Bundesrepublik Deutschland19. Oktober 2016

  1. Der Websitebetreibereine Adresse und eine Uhrzeit, aus seinen Logs203.0.113.7 · 14:02:37
  2. die rechtlichen Mittel, das zu erfahren
  3. Der Internetzugangsanbieterwer diese Adresse zu dieser Zeit genutzt hat203.0.113.7 · 14:02:37 →
  4. Personenbezogenes Datum, für diesen Betreiber

Die Pressemitteilung des Gerichtshofs: Eine Website kann ein berechtigtes Interesse haben, einiges davon zu speichern, um sich gegen Angriffe zu verteidigen.

Auf dieser Seite

Ihr Browser

  1. Sammelt
  2. Ordnet ein
  3. Vergleicht
  4. Zeigt
  • Sehen Ihre öffentliche Adresse, wie bei jedem Anruf
  • dnsrobot.netKein Kandidat wird gesendet
Rechtssache C-582/14, Breyer. Eine dynamische IP-Adresse ist ein personenbezogenes Datum für einen Websitebetreiber, der die rechtlichen Mittel hat, Sie mit den Daten des Anbieters zu identifizieren. Diese Seite behält die Kandidaten in Ihrem Browser.

WebRTC-Leak-Test: Fragen und Antworten

Was ist ein WebRTC-Leak?

WebRTC ist die Browserfunktion hinter Videoanrufen. Um zwei Menschen direkt zu verbinden, sammelt sie jede Adresse, unter der Ihr Rechner erreichbar ist, und bietet sie der Seite an, ohne Berechtigungsabfrage. Zum Leak wird es, wenn eine dieser Adressen eine ist, die Sie verbergen wollten – typischerweise Ihre echte Adresse bei eingeschaltetem VPN, weil WebRTC nach jeder Netzwerkschnittstelle fragen kann statt nur nach der, die Ihr Surfen nutzt.

Wie teste ich auf ein WebRTC-Leak?

Starten Sie den Test auf dieser Seite. Er fragt drei STUN-Server von zwei Betreibern, listet jede Adresse auf, die WebRTC geliefert hat, mit der Art jeder Adresse, und vergleicht die routbaren mit der Adresse, die eine Website ohnehin sieht. Nutzen Sie ein VPN, testen Sie einmal mit ausgeschaltetem und einmal mit eingeschaltetem VPN: Der Unterschied zwischen beiden Durchläufen ist die Antwort.

Verhindert ein VPN ein WebRTC-Leak?

Nicht von allein. Ein VPN ändert, wohin Ihr Datenverkehr geht, aber WebRTC kann das Betriebssystem fragen, welche Schnittstellen es gibt, und die physische Verbindung ist meist noch eine davon. Der Text der IETF selbst sagt, WebRTC könne „nicht nur die öffentliche Adresse des VPN entdecken, sondern auch die öffentliche Adresse des ISP, über den das VPN läuft“. Manche VPN-Clients schließen die Lücke; dieser Test sagt Ihnen, ob Ihrer es getan hat.

Was bedeutet eine .local-Adresse in den Ergebnissen?

Das ist mDNS, und es ist eine gute Nachricht. Moderne Browser ersetzen Ihre privaten Adressen durch einen zufälligen Namen mit der Endung .local, bevor sie sie einer Seite anbieten, sodass eine Website daraus nichts über Ihr Heimnetz erfährt. Chrome tut das seit Version 76, Firefox ebenso; Safari geht weiter und bietet überhaupt keine Host-Kandidaten an, solange eine Website keine Kamera- oder Mikrofonberechtigung hat. Der Test markiert solche Adressen als funktionierenden Schutz, nicht als Befund.

Wenn mDNS meine lokale IP verbirgt, bin ich dann sicher?

Teilweise. mDNS sollte private Adressen verbergen und ausdrücklich keine, die bereits öffentlich ist – das sagt der IETF-Entwurf, der es festlegt. Ihre öffentliche IPv4 erscheint weiterhin als server-reflexiver Kandidat, und ein Rechner mit einer routbaren IPv6-Adresse kann diese Adresse weiterhin direkt anbieten. Außerdem schaltet Chrome den Schutz für jede Website ab, die bereits Kamera- oder Mikrofonberechtigung hat.

Warum meldet der Test manchmal „Nicht getestet“?

Weil es die Wahrheit ist. Ist WebRTC ausgeschaltet, durch eine Erweiterung oder eine Richtlinie blockiert, oder hat kein STUN-Server geantwortet – eine Firewall, ein restriktives VPN, ein Netz, das UDP blockiert –, dann wurde nichts gemessen. Die meisten Tools zeigen in dieser Lage einen grünen Haken, und das ist das Irreführendste, was ein Leak-Test tun kann. Dieser sagt, was passiert ist, und nennt die Server, die stumm blieben.

Wie deaktiviere ich WebRTC in Firefox?

Die dokumentierten Einstellungen von Firefox schränken WebRTC ein, statt es abzuschalten. In about:config sendet media.peerconnection.ice.default_address_only eine Adresse statt aller, und media.peerconnection.ice.relay_only beschränkt das Sammeln auf Relay-Kandidaten: Das verbirgt am meisten, bricht aber direkte Anrufe. Die Maskierung privater Adressen, media.peerconnection.ice.obfuscate_host_addresses, ist standardmäßig schon an. Testen Sie nach jeder Änderung erneut, um zu sehen, was sie Ihnen gebracht hat.

Wie stoppe ich WebRTC-Leaks in Chrome?

Chrome gibt gewöhnlichen Nutzern dafür keine Einstellung; die mDNS-Maskierung privater Adressen ist standardmäßig an, und das ist der Schutz, den Sie bekommen. Edge, das die Engine von Chrome teilt, hat die Unternehmensrichtlinie WebRtcLocalIpsAllowedUrls. Die noch oft empfohlenen Erweiterungen funktionieren nicht: uBlock Origin hat seine WebRTC-Option in Version 1.38 entfernt, und Googles WebRTC Network Limiter kann nicht laufen, seit Manifest V2 in Chrome 138 deaktiviert wurde.

Was ist der Unterschied zwischen einem Host-Kandidaten und einem server-reflexiven?

Ein Host-Kandidat ist eine Adresse auf Ihrem eigenen Rechner. Ein server-reflexiver Kandidat ist das, was ein STUN-Server gesehen hat – die öffentliche Seite Ihres NAT, meist die Adresse, die die Website ohnehin von Ihrer Verbindung hat. Ein routbarer Host-Kandidat ist der schwerere Befund, weil er eine Adresse auf dem Gerät selbst ist, und bei IPv6 identifiziert er das Gerät statt des Haushalts.

Ist ein WebRTC-Leak dasselbe wie ein DNS-Leak?

Nein. Ein WebRTC-Leak verrät eine Adresse; ein DNS-Leak verrät, welcher Resolver Ihre Abfragen beantwortet, und damit erfährt Ihr Anbieter jede Website, die Sie besuchen, selbst wenn der Datenverkehr durch das VPN geht. Beide versagen unabhängig voneinander, ein sauberes Ergebnis beim einen sagt also nichts über das andere. Führen Sie nach jeder Änderung am VPN auch unseren DNS-Leak-Test aus.

Sendet dieser Test meine IP-Adresse irgendwohin?

Nur dorthin, wo jede Website sie ohnehin sähe. Ihr Browser kontaktiert die STUN-Server, wie jeder Videoanruf: Das ist der Test. Um zu erfahren, was eine Website sieht, fragt die Seite ipify.org und unseren eigenen Server nach Ihren Adressen und deren Netzen, so wie der DNS-Leak-Test. Die Adressen, die WebRTC findet, bleiben in Ihrem Browser: Keine davon wird an uns gesendet. Beobachten Sie den Netzwerk-Tab Ihrer Entwicklertools, während der Test läuft.

Ist meine IP-Adresse nach EU-Recht ein personenbezogenes Datum?

Für einen Websitebetreiber in der EU ist eine dynamische IP-Adresse ein personenbezogenes Datum, wenn dieser Betreiber rechtliche Mittel hat, Sie mithilfe der Informationen Ihres Internetanbieters zu identifizieren. So hat es der Gerichtshof der EU im Fall Breyer, C-582/14, im Oktober 2016 entschieden. Das ist ein Grund, warum diese Seite den WebRTC-Teil des Tests in Ihrem Browser hält statt auf einem Server von uns.

Fehlt Ihnen etwas?Funktion oder neues Tool vorschlagen

Verwandte Tools