WebRTC-Leak-Test: Leckt Ihr VPN Ihre echte IP-Adresse?
Dieser WebRTC-Leak-Test führt exakt denselben Peer-Connection-Aufruf aus, den auch Tracking-Skripte nutzen, und zeigt Ihnen, ob dabei Adressen preisgegeben werden, die Ihr VPN eigentlich verbergen sollte. Der Test öffnet eine RTCPeerConnection mit einem leeren Datenkanal — ohne Kamera, ohne Mikrofon und ohne Berechtigungsabfrage —, fragt zwei öffentliche STUN-Server nach Ihrer externen Verbindungsadresse und vergleicht diese mit der IP Ihrer normalen HTTPS-Anfragen.
So lesen Sie die ermittelten ICE-Kandidaten
WebRTC muss sämtliche Adressen ermitteln, unter denen Gegenstellen Sie erreichen könnten, und erstellt dafür eine Liste sogenannter ICE-Kandidaten. Diese Seite zeigt die Rohliste mit Typ und Übertragungsprotokoll und beendet die Suche nach fünf Sekunden.
Darüber sehen Sie Ihre reguläre IPv4 und IPv6 über HTTP — genau die Werte, die auch wie lautet meine IP-Adresse ausgibt. Diese dienen als Referenzwert; das Gesamtergebnis entsteht aus dem direkten Abgleich.
host, srflx und relay — Bedeutung der Kennzeichnungen
- Lokal (host) — eine Adresse Ihres Netzwerkadapters: eine LAN-IP wie
192.168.1.14oder ein anonymer.local-mDNS-Name. - Öffentlich (über STUN) — der
srflx-Kandidat, also die Adresse, von der das STUN-Paket empfangen wurde. Das ist der entscheidende Wert beim Einsatz eines VPNs. - Relay (TURN) — über einen Relay-Server weitergeleitet; da dieser Test nur STUN nutzt, tritt ein Relay-Eintrag selten auf.
Bedeutung der Prüfergebnisse
- Leak entdeckt — ein öffentlicher STUN-Kandidat weicht von Ihrer HTTP-IP ab; bei einem VPN hat das WebRTC-Paket den Tunnel umgangen.
- Kein Leak — beide Adressen stimmen exakt überein.
- Lokale IP sichtbar — eine unverschlüsselte LAN-Adresse erschien anstelle eines mDNS-Namens.
- Geschützt — Ihre lokale Adresse wurde durch einen zufälligen
.local-Hostnamen maskiert. - Keine öffentliche IP / WebRTC blockiert — STUN war nicht erreichbar oder WebRTC ist im Browser deaktiviert.
Warum WebRTC eine vom VPN verborgene IP preisgibt
WebRTC wurde für browserbasierte Video-, Sprach- und Dateiübertragungen zwischen Endgeräten entwickelt. Um zwei Computer hinter getrennten Routern direkt zu verbinden, ist ein NAT-Traversal erforderlich, das eine zentrale Frage klärt: Von welcher IP-Adresse stammt die Verbindung? Ein STUN-Server beantwortet dies, und jede Website kann diesen Vorgang unbemerkt per JavaScript auslösen.
Problematisch wird dies, wenn eine andere IP verborgen bleiben soll. Ein VPN leitet Ihren regulären HTTP-Datenverkehr durch seinen Tunnel; WebRTC sendet jedoch eigene UDP-Pakete an den STUN-Server, die bei Split-Tunneling am Tunnel vorbeilaufen. Browser-Erweiterungs-VPNs sind der typische Fall: Sie leiten nur Web-Requests weiter, nicht den UDP-Netzwerkstack — weshalb dieses Resultat von einer reinen VPN-Prüfung über HTTP abweichen kann.
Ein zufälliger .local-Hostname ist kein Datenleck
Wenn ein Host-Kandidat wie 7b3f9c21-4d0a-48e7.local statt 192.168.1.14 lautet, liegt kein Fehler vor. Dies ist die mDNS-Verschleierung: Der Browser erzeugt einen temporären Multicast-DNS-Namen für die lokale Schnittstelle und übergibt diesen anstelle der LAN-IP. Chrome, Edge, Brave, Firefox und Safari aktivieren dies standardmäßig — uBlock Origin entfernte seine eigene WebRTC-Option ab v1.38, da die Browser dies nativ lösen. Zwei Einschränkungen: Dies schützt nur die lokale IP, verhindert jedoch keinen VPN-Leak, und Websites mit Kamera- oder Mikrofonberechtigung erhalten ohnehin Zugriff auf die reale LAN-IP.
So beheben Sie ein WebRTC-Leak in Chrome und Edge
Keiner der beiden Browser besitzt einen einfachen Aus-Schalter, und Einträge in chrome://flags oder edge://flags deaktivieren WebRTC nicht mehr. Drei Methoden helfen in der Praxis:
- Verwenden Sie einen System-VPN-Client (Full-Tunnel) anstelle einer Browser-Erweiterung. Wenn alle UDP-Pakete den VPN-Tunnel durchlaufen, sieht STUN nur die VPN-Adresse.
- Legen Sie die IP-Verarbeitungsrichtlinie per Erweiterung fest. Tools wie WebRTC Leak Prevent blockieren nichts selbst, sondern setzen
chrome.privacy.network.webRTCIPHandlingPolicyaufdefault_public_interface_onlyoderdisable_non_proxied_udp. Nur diese beiden Modi verhindern die lokale Offenlegung. - Aktivieren Sie Richtlinien auf Betriebssystemebene. Chrome liest
WebRtcIPHandling; Edge wertetWebRtcLocalhostIpHandlingunterSOFTWARE\Policies\Microsoft\Edgeaus, wobeiAllowPublicInterfaceOnlyundDisableNonProxiedUdpwirksam sind. Beide erfordern einen Neustart; prüfen Sie dies unteredge://policy.
So deaktivieren Sie WebRTC in Firefox vollständig
Firefox ist der einzige moderne Desktop-Browser mit einem echten Abschalter. Öffnen Sie about:config, bestätigen Sie die Warnung, suchen Sie nach media.peerconnection.enabled und setzen Sie den Wert per Doppelklick auf false. WebRTC ist danach für alle Websites ohne Neustart deaktiviert, und dieser Test meldet es als blockiert.
Dies ist eine radikale Maßnahme: Web-Meetings in Meet, Teams, Discord oder Zoom funktionieren dann nicht mehr. Damit Konferenzen intakt bleiben, belassen Sie die Option auf true und setzen stattdessen media.peerconnection.ice.default_address_only auf true — Firefox übermittelt dann nur die Adresse der Standardroute, also des VPNs.
So beheben Sie ein WebRTC-Leak in Brave
Brave bietet standardmäßig die Optionen, die Chrome verbirgt. Öffnen Sie brave://settings/privacy und suchen Sie die WebRTC IP handling policy. Für den Einsatz mit VPN oder Proxy eignen sich zwei Einstellungen:
- Default — listet potenziell jede Schnittstelle auf und legt lokale Adressen offen.
- Default Public and Private Interfaces — nutzt die Standardroute, zeigt aber weiterhin die private IP an.
- Default Public Interface Only — nur Standardroute, keine lokalen Adressen, Sprachanrufe funktionieren. Die ideale Alltagseinstellung.
- Disable Non-Proxied UDP — erzwingt TCP durch den Proxy, falls dieser kein UDP unterstützt. Die strengste Stufe, wie in Braves Tor-Fenstern; kann Peer-to-Peer-Gespräche unterbrechen.
Besonderheiten auf Safari, iPhone und Android
Auf mobilen Systemen und WebKit gelten Desktop-Anleitungen oft nicht uneingeschränkt.
Safari auf macOS
Das aktuelle Safari bietet keinen dauerhaften globalen Deaktivierungsschalter mehr. Menüeinträge unter Entwickler > WebRTC gelten nur für die aktuelle Sitzung. Safari schützt lokale Adressen standardmäßig hinter mDNS, bis Sie Kamera- oder Mikrofonzugriff gewähren. Die wirksamsten Mittel sind Website-Berechtigungen unter Safari > Einstellungen > Websites sowie ein systemweites VPN.
iPhone und iPad
Jeder iOS-Browser nutzt die WebKit-Engine. Chrome und Firefox unter iOS verfügen daher über keine about:config-Optionen, keine Flag-Seiten und keine Erweiterungen; Content-Blocker können WebRTC nicht filtern. Um Leaks zu verhindern, aktivieren Sie ein VPN unter Einstellungen > VPN mit UDP-Tunnelführung und wiederholen Sie diesen Test in Safari.
Android
Chrome für Android bietet weder WebRTC-Flags noch Erweiterungsunterstützung. Brave für Android enthält dieselbe WebRTC IP handling policy in den Datenschutzeinstellungen. In Firefox für Android ist about:config nur in Beta- und Nightly-Builds zugänglich. Nutzen Sie ansonsten die Android-Funktion Durchgehend aktives VPN mit der Option Verbindungen ohne VPN blockieren.
Grenzen dieses WebRTC-Leak-Tests
Diese Seite analysiert ausschließlich, was Ihr Browser an Skripte auf dieser Website übergibt. Ein Leak auf Betriebssystemebene — etwa fehlgeleitete Verbindungen oder ein ungetunnelter IPv6-Pfad — kann im Browser nicht vollständig erfasst werden; auch DNS-Leaks werden hier nicht getestet. Bei blockiertem STUN erscheint „Keine öffentliche IP“, was jedoch lediglich bedeutet, dass keine Antwort eintraf. Zudem ist eine IP nur ein Merkmal von vielen: Bildschirmwerte, installierte Schriftarten und HTTP-Header, die auf der Seite Welchen Browser habe ich aufgeführt sind, können Ihr Gerät selbst bei aktiver VPN-Verbindung identifizierbar machen.
Häufig gestellte Fragen (FAQ)
Leckt WebRTC meine echte IP-Adresse auch bei aktivem VPN?
Ja, das kann passieren. WebRTC überträgt eigene UDP-Pakete an STUN-Server. Bei Split-Tunneling oder reinen Browser-Erweiterungs-VPNs laufen diese Pakete oft außerhalb des Tunnels über Ihre normale Leitung. Der STUN-Server übermittelt dann Ihre tatsächliche IP des Providers, die jede Webseite per JavaScript auslesen kann. Ein Full-Tunnel-VPN-Client schließt dieses Leck zuverlässig.
Gibt es eine Möglichkeit, WebRTC in Edge komplett abzuschalten?
Nicht über die normalen Browsereinstellungen. Edge besitzt keinen Ein-/Ausschalter, und das alte Flag in about:flags wurde entfernt. Über Unternehmensrichtlinien können Sie unter SOFTWARE\Policies\Microsoft\Edge den Schlüssel WebRtcLocalhostIpHandling auf AllowPublicInterfaceOnly oder DisableNonProxiedUdp setzen. Dies erfordert einen Neustart; prüfen Sie die Richtlinie unter edge://policy.
Wo kann ich WebRTC und PeerConnection in Firefox deaktivieren?
In about:config: Suchen Sie nach media.peerconnection.enabled und setzen Sie den Eintrag per Doppelklick auf false. Damit wird WebRTC sofort deaktiviert; Videokonferenzen im Browser funktionieren dann allerdings nicht mehr. Um Anrufe zu erhalten, setzen Sie stattdessen media.peerconnection.ice.default_address_only auf true.
Wie kann ich WebRTC in Safari dauerhaft deaktivieren?
Im aktuellen Safari ist das nicht dauerhaft möglich. Der frühere Schalter unter Entwickler > Experimentelle Funktionen existiert nicht mehr, und temporäre Entwickler-Optionen gelten nur sitzungsweise. Da Safari lokale IPs hinter mDNS schützt und erst bei Mikrofon-/Kamerazugriff freigibt, sind restriktive Website-Berechtigungen sowie ein systemweites VPN die beste Lösung.
Welche Einstellungen verhindern ein WebRTC-Leak in Brave am besten?
Wählen Sie unter brave://settings/privacy bei WebRTC IP handling policy die Option „Disable Non-Proxied UDP“, solange Sie ein VPN oder einen Proxy nutzen. Dann verwendet WebRTC TCP über den Proxy und STUN sieht niemals Ihre reale IP. Die Option „Default Public Interface Only“ ist die alltagstaugliche Alternative, bei der Sprachanrufe weiterhin funktionieren.
Welche WebRTC-IP-Verarbeitungsrichtlinie sollte ich wählen?
„Default Public Interface Only“ empfiehlt sich für die meisten Nutzer. Lokale Netzwerkadapter werden verborgen, UDP bleibt aktiv und Online-Meetings laufen stabil. „Disable Non-Proxied UDP“ bietet den stärksten Schutz bei Proxy- oder VPN-Nutzung, kann aber Direktverbindungen stören. Die Standardoptionen hingegen legen interne LAN-Adressen weiterhin offen.
Warum wird meine private IP-Adresse durch WebRTC öffentlich gemacht?
In modernen Browsern geschieht dies nicht mehr unverschlüsselt. Chrome, Edge, Brave, Firefox und Safari ersetzen die rohe LAN-IP durch einen zufälligen mDNS-Namen mit der Endung .local. Websites sehen also nicht mehr 192.168.1.14. Falls bei Ihnen eine rohe IP aufgeführt wird, ist dieser Schutzmechanismus inaktiv und sollte überprüft werden.