WebRTC- und DNS-Lecks: Was sie sind und wie Sie sie stoppen

Sie haben in Ihrem Browser einen Proxy eingestellt, die IP-Prüfseite zeigt die Adresse des Proxys, und alles scheint in Ordnung. Eine im selben Browser geöffnete Seite kann Ihre echte IP-Adresse mit ein paar Zeilen JavaScript trotzdem herausfinden. Dafür gibt es zwei verbreitete Wege: WebRTC und DNS-Abfragen. Beide arbeiten außerhalb des HTTP-Verkehrs, den ein Proxy abdeckt, und werden von der Proxy-Einstellung daher womöglich nicht erfasst.

In diesem Artikel erklären wir, was ein IP-Leck ist, über welchen Mechanismus WebRTC Ihre echte Adresse offenlegt, wo DNS-Lecks entstehen und wie Sie beides testen. Danach behandeln wir die Einstellungen in Chrome und Firefox, die das Leck schließen, warum bei SOCKS5 die DNS-Auflösung auf dem Proxy wichtig ist, und weitere Signale neben der IP, die Ihren Standort verraten. Am Ende steht eine Checkliste auf einer Seite.

Was ist ein IP-Leck?#

Ein IP-Leck bedeutet, dass Ihre echte IP-Adresse über einen Teil Ihres Verkehrs sichtbar wird, während Sie einen Proxy oder ein VPN nutzen. Ein Leck heißt nicht, dass der Proxy nicht funktioniert. Die HTTP-Anfragen der Seite laufen über den Proxy, und die Zielseite sieht in diesen Anfragen die Adresse des Proxys. Das Problem ist, dass der Browser neben HTTP noch andere Netzwerkverbindungen öffnen kann.

Die Proxy-Einstellung eines Browsers deckt meist nur HTTP- und HTTPS-Anfragen ab. Weitere Verbindungen, die ein Browser aufbaut:

• WebRTC: direkte Verbindungen über UDP für Videoanrufe, Bildschirmfreigabe und Peer-to-Peer-Datenübertragung.
• DNS-Abfragen: Abfragen, die Betriebssystem oder Browser an einen DNS-Server senden, um Domainnamen in IP-Adressen umzuwandeln.
• Browsererweiterungen und Verbindungen innerhalb von Apps: Komponenten, die eigene Netzwerkeinstellungen nutzen.

Sieht eine Website Ihre echte Adresse über einen dieser Kanäle, kann sie sie mit der Adresse des Proxys vergleichen. Zwei Adressen aus verschiedenen Ländern zeigen klar, dass der Besucher einen Proxy nutzt. Wie ein Proxy grundsätzlich funktioniert, erklären wir in Was ist ein Proxy-Server und wie funktioniert er?.

Wie verrät WebRTC Ihre echte IP?#

WebRTC wurde entwickelt, damit zwei Browser direkt miteinander sprechen können, ohne über einen Server zu gehen. Dazu muss jeder Browser die Adressen kennen, unter denen er erreichbar ist, und sie der Gegenseite mitteilen. Diese Adressen heißen ICE-Kandidaten, und der Suchvorgang ist in RFC 8445 definiert.

Startet eine Seite eine WebRTC-Verbindung, geschieht Folgendes:

1. Die Seite erstellt eine RTCPeerConnection. Sie muss den Nutzer nicht um Erlaubnis bitten; weder Kamera noch Mikrofon werden eingeschaltet. Es genügt, einen Datenkanal anzufordern.
2. Der Browser sammelt lokale Kandidaten. Das sind die Adressen der Netzwerkschnittstellen des Computers (host-Kandidaten). Aktuelle Browser verbergen die lokale Adresse hinter einem zufälligen Namen wie xxxx.local.
3. Der Browser sendet ein UDP-Paket an einen STUN-Server. Der STUN-Server meldet die öffentliche IP-Adresse und den Port zurück, von denen das Paket kam. Diese Adresse wird als srflx-Kandidat (server reflexive) gespeichert.
4. Das UDP-Paket geht nicht über den Proxy. Ein HTTP-Proxy transportiert nur HTTP-Verkehr; der Browser sendet das STUN-Paket direkt über die Netzwerkschnittstelle. Der STUN-Server sieht das Paket von Ihrer echten öffentlichen IP-Adresse kommen.
5. Die Kandidaten werden der Seite gemeldet. JavaScript liest die Kandidatenliste über das Ereignis onicecandidate und kann die öffentliche IP aus dem srflx-Kandidaten an den eigenen Server senden.

Das Ergebnis: Die Seite sieht über HTTP-Anfragen die Adresse des Proxys und über WebRTC Ihre echte Adresse.

Welche Adressen Browser bei WebRTC offenlegen dürfen, beschreibt RFC 8828 in vier Modi: alle Schnittstellen nutzen, nur die Standardroute mit der zugehörigen lokalen Adresse nutzen, nur die öffentliche Adresse der Standardroute nutzen und UDP über den Proxy erzwingen. Die Einstellungen in Chrome und Firefox entsprechen diesen Modi.

Was ist ein DNS-Leck?#

Bevor eine Verbindung zu einer Website aufgebaut wird, muss ihr Domainname in eine IP-Adresse umgewandelt werden. Ein DNS-Leck liegt vor, wenn diese Abfrage nicht über den Proxy, sondern über den DNS-Server Ihres Internetanbieters oder Ihres lokalen Netzes läuft.

Ein DNS-Leck hat zwei Folgen:

• Die aufgerufenen Websites sind im lokalen Netz sichtbar. Ihr Internetanbieter, Ihr Firmennetz oder jemand im selben WLAN kann sehen, welche Domains Sie abfragen, obwohl Sie einen Proxy nutzen.
• Die Zielseite liefert womöglich eine andere Serveradresse. Websites mit CDN geben den nächstgelegenen Server abhängig vom Standort des Servers zurück, der die DNS-Abfrage stellt. Geht die Abfrage aus der Türkiye hinaus, die Anfrage aber über einen Proxy in Deutschland, landen Sie auf einem weit entfernten Server, und es entsteht ein Standortwiderspruch.

DNS-Lecks treten am häufigsten auf, wenn:

• der Client bei einem SOCKS5-Proxy den Domainnamen selbst auflöst und nur eine IP-Adresse an den Proxy sendet,
• der Proxy nur im Browser eingestellt ist und andere Anwendungen den System-DNS nutzen,
• VPN- oder Proxy-Software die DNS-Einstellungen des Betriebssystems nicht ändert.

Bei HTTP- und HTTPS-Proxys sendet der Browser den Domainnamen in der Anfrage CONNECT example.com:443 an den Proxy, und der Proxy übernimmt die Auflösung. Für den Webverkehr im Browser sind HTTP-Proxys hinsichtlich DNS-Lecks daher weniger riskant. Wie sich beide Protokolle hier unterscheiden, erklären wir in SOCKS- und HTTP-Proxy im Vergleich.

Wie testen Sie auf WebRTC- und DNS-Lecks?#

Es gibt fertige Testseiten, doch den Test einmal selbst durchzuführen, zeigt, worauf Sie achten müssen.

WebRTC-Test#

Öffnen Sie bei aktivem Proxy eine beliebige Seite im Browser, öffnen Sie die Konsole der Entwicklertools (F12) und führen Sie diesen Code aus:

const pc = new RTCPeerConnection({ iceServers: [{ urls: "stun:stun.l.google.com:19302" }] });
pc.createDataChannel("test");
pc.onicecandidate = (e) => {
  if (e.candidate) console.log(e.candidate.candidate);
};
await pc.setLocalDescription(await pc.createOffer());

In der Konsole erscheinen einige Kandidatenzeilen. Suchen Sie die Zeile mit typ srflx. Ist die IP-Adresse in dieser Zeile:

• gleich der Ausgangs-IP des Proxys oder gibt es gar keine srflx-Zeile, liegt kein WebRTC-Leck vor.
• Ihre echte IP-Adresse, liegt ein WebRTC-Leck vor.

Kennen Sie Ihre echte IP-Adresse nicht, öffnen Sie bei ausgeschaltetem Proxy eine IP-Prüfseite.

DNS-Test#

Ein DNS-Leck lässt sich im Browser allein nicht messen, weil nur der Inhaber der Domain sieht, von welchem DNS-Server eine Abfrage kam. Deshalb lassen DNS-Leck-Testseiten zufällig erzeugte Subdomains auflösen und zeigen Ihnen, welche DNS-Server diese Abfragen gestellt haben. Sehen Sie im Ergebnis die DNS-Server Ihres eigenen Internetanbieters, laufen die Abfragen nicht über den Proxy.

Auf der Befehlszeile zeigt die ausführliche Ausgabe von cURL, wie ein SOCKS5-Proxy mit DNS umgeht:

# Lokale Auflösung: Der Domainname wird auf Ihrem Rechner in eine IP umgewandelt
curl -v -x "socks5://user:pass@pr.proxynet.io:1080" https://httpbin.org/ip

# Auflösung auf dem Proxy: Der Domainname wird an den Proxy gesendet, der ihn auflöst
curl -v -x "socks5h://user:pass@pr.proxynet.io:1080" https://httpbin.org/ip

In der Ausgabe des ersten Befehls meldet cURL, dass es die Domain vor dem Verbindungsaufbau aufgelöst und eine IP-Adresse an den Proxy gesendet hat. Beim zweiten wird der Domainname selbst an den Proxy gesendet. Alle Proxy-Optionen von cURL finden Sie in Proxy mit cURL verwenden.

Wie stoppen Sie WebRTC-Lecks in Chrome?#

Das Einstellungsmenü von Chrome bietet keine Option, WebRTC abzuschalten. Dieses Verhalten ändern Sie über eine Unternehmensrichtlinie oder mit Erweiterungen. Der Weg über die Richtlinie braucht keine Erweiterung und stützt sich auf die offizielle Google-Dokumentation.

Die Chrome-Enterprise-Richtlinie WebRtcIPHandling kennt diese Werte:

Der Wert, der das Leck bei Proxy-Nutzung schließt, ist disable_non_proxied_udp. Unter Windows schreiben Sie diese Richtlinie mit einer als Administrator geöffneten PowerShell in die Registry:

New-Item -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Name "WebRtcIPHandling" -Value "disable_non_proxied_udp"

Beenden Sie Chrome vollständig, öffnen Sie es erneut und geben Sie chrome://policy in die Adressleiste ein, um zu prüfen, ob die Richtlinie geladen wurde. Wiederholen Sie dann den WebRTC-Test oben.

Diese Einstellung hat ihren Preis: Browserbasierte Videoanrufe und Bildschirmfreigaben können kein UDP nutzen, laufen daher langsamer oder gar nicht. Erledigen Sie auf demselben Rechner Proxy-Arbeit und Videoanrufe, ist ein eigenes Browserprofil oder ein eigener Browser für jede Aufgabe praktischer. Woher Chrome seine Proxy-Einstellung liest, erklären wir in Proxy-Einstellungen in Windows und Chrome.

Wie stoppen Sie WebRTC-Lecks in Firefox?#

Firefox bietet diese Einstellungen auf der Seite about:config. Geben Sie about:config in die Adressleiste ein, bestätigen Sie die Warnung und suchen Sie die folgenden Einstellungen.

Die erste Einstellung soll das Leck bei Proxy-Nutzung schließen, ohne Anruftools ganz lahmzulegen. media.peerconnection.enabled auf false zu setzen ist die eindeutigste Lösung, deaktiviert aber alle Videoanruf- und Bildschirmfreigabefunktionen im Browser.

Setzen Sie für DNS in Firefox außerdem auf dem Bildschirm der Proxy-Einstellungen das Häkchen bei „DNS über Proxy bei Verwendung von SOCKS v5". In about:config heißt diese Option network.proxy.socks_remote_dns. Die vollständige Proxy-Einrichtung in Firefox beschreibt Proxy-Einstellungen in Firefox; für die Proxy-Verwaltung pro Profil lesen Sie unseren Leitfaden zu SwitchyOmega.

Warum ist DNS-Auflösung auf dem Proxy bei SOCKS5 wichtig?#

Das SOCKS5-Protokoll erlaubt dem Client, dem Proxy das Ziel auf zwei Arten mitzuteilen: als IP-Adresse oder als Domainname. Sendet der Client eine IP-Adresse, hat er den Domainnamen selbst aufgelöst, und die DNS-Abfrage ist aus Ihrem eigenen Netz gegangen.

In Bibliotheken und Tools heißt dieses Verhalten unterschiedlich:

• cURL: socks5:// löst lokal auf, socks5h:// auf dem Proxy.
• Python Requests und HTTPX: das Schema socks5h:// in der Proxy-Adresse.
• Firefox: die Option „DNS über Proxy bei Verwendung von SOCKS v5".
• Chrome: sendet bei SOCKS5 den Domainnamen an den Proxy.
• Umleitungstools wie Proxifier: eine Option in der Art von „Resolve hostnames through proxy".

Der zweite Vorteil der Auflösung auf dem Proxy ist Standortkonsistenz: Löst der Proxy den DNS auf, liefern CDNs einen Server in der Nähe des Proxy-Standorts. Technische Details zu SOCKS5 finden Sie in Was sind SOCKS5-Proxys?. Aufbauten, die auch Anwendungsverkehr abdecken, nutzen SOCKS5-Proxy-Tarife.

Signale neben Lecks, die Ihren Standort verraten#

Auch nachdem IP- und DNS-Lecks geschlossen sind, kann eine Seite aus dem, was sie über den Browser selbst weiß, Hinweise auf Ihren Standort sammeln. Das sind keine Netzwerklecks, doch wenn sie dem Standort des Proxys widersprechen, haben sie dieselbe Wirkung.

• Zeitzone. JavaScript liest die Systemzeitzone mit Intl.DateTimeFormat().resolvedOptions().timeZone. Eine IP aus Deutschland mit der Zeitzone Europe/Istanbul ist ein Widerspruch.
• Spracheinstellungen. navigator.languages und der Header Accept-Language zeigen die Sprachreihenfolge des Browsers.
• Standortfreigabe. Haben Sie einer Website im Browser den Standortzugriff erlaubt, kann die Geolocation-API Ihren echten Standort anhand umliegender WLAN-Netze liefern.
• Cookies und Sitzungen. Ein Sitzungs-Cookie aus einem Besuch ohne Proxy wird auch beim Besuch mit Proxy gesendet und verbindet beide Besuche.
• Browser-Fingerprint. Bildschirmauflösung, Schriften und Grafikkarteninformationen identifizieren den Browser unabhängig von der IP. Details finden Sie in Browser-Fingerprinting.

Müssen Sie mit mehreren Identitäten arbeiten, gibt es Aufbauten, die Proxy, Zeitzone und Sprache jedes Profils aufeinander abstimmen; wir erklären sie in Was ist ein Antidetect-Browser?.

Anwendungsfälle#

• Ein Team, das Anzeigen und Inhalte in verschiedenen Ländern prüft: Ein WebRTC-Leck kann dazu führen, dass die Website Sie am falschen Standort einordnet. Neben einem Residential-Proxy, der über echte Nutzeranschlüsse ins Netz geht, müssen auch die Browsereinstellungen stimmen.
• Ein Entwickler, der Verkehr mit mobilem Profil testet: Eine Mobilfunk-IP, die in WebRTC zusammen mit der echten Adresse eines Desktop-Netzes erscheint, erzeugt einen Widerspruch. Dieselbe Prüfung gilt bei der Nutzung eines Mobile-Proxy.
• Ein Nutzer, der eine Desktop-Anwendung über einen Proxy leitet: Die DNS-Abfragen der Anwendung laufen womöglich über den System-DNS; im Umleitungstool muss die Auflösung auf dem Proxy aktiviert sein.
• Ein Team mit Browserautomatisierung: Auch Automatisierungsbrowser unterstützen WebRTC. Beim Start von Chrome sollte dieselbe Richtlinie oder eine gleichwertige Starteinstellung genutzt werden.

Häufige Fehler#

• Das Ergebnis der IP-Prüfseite für ausreichend halten. Diese Seiten zeigen nur die Adresse der HTTP-Anfrage; WebRTC und DNS müssen gesondert getestet werden.
• Die Einstellung ändern, ohne den Browser neu zu starten. Chrome-Richtlinien werden erst geladen, wenn der Browser vollständig geschlossen und wieder geöffnet wird.
• VPN und Proxy zusammen nutzen und die geleakte Adresse falsch deuten. Mit aktivem VPN erscheint im WebRTC-Test die Adresse des VPN; das ist nicht Ihre echte Adresse, passt aber auch nicht zur Proxy-Adresse.
• Das Schema socks5:// als Standard belassen. Die meisten Bibliotheksbeispiele nutzen das Schema, das lokal auflöst.
• WebRTC ganz abschalten und sich dann wundern, warum Anruftools nicht funktionieren. proxy_only_if_behind_proxy oder ein eigenes Profil erreichen dasselbe mit weniger Nebenwirkungen.
• Zeitzone und Sprache vergessen. Auch wenn Netzwerklecks geschlossen sind, verraten diese Signale einen Standortwiderspruch.

Checkliste#

Häufig gestellte Fragen#

Betreffen WebRTC-Lecks nur Proxy-Nutzer?#

Sie können auch VPN-Nutzer betreffen, doch weil die meisten VPNs auf Betriebssystemebene arbeiten und auch UDP-Verkehr durch den Tunnel leiten, sind Lecks seltener. Ein Proxy deckt nur den HTTP-Verkehr des Browsers ab, daher ist das Risiko höher.

Beeinträchtigt das Abschalten von WebRTC Websites?#

Browserbasierte Videoanrufe, Sprachchats, Bildschirmfreigaben und manche Dateiübertragungsdienste funktionieren dann nicht oder langsamer. Die große Mehrheit gewöhnlicher Websites ist nicht betroffen.

Leckt meine lokale IP-Adresse (192.168...) noch?#

Aktuelle Versionen von Chrome und Firefox verbergen lokale Adressen standardmäßig hinter zufälligen Namen mit der Endung .local. Das eigentliche Risiko ist die über STUN ermittelte öffentliche IP-Adresse.

Kann bei einem HTTP-Proxy ein DNS-Leck auftreten?#

Beim Webverkehr im Browser meist nicht, weil der Domainname in der CONNECT-Anfrage an den Proxy gesendet wird. Andere Anwendungen und Betriebssystemkomponenten ohne Proxy-Einstellung stellen jedoch weiterhin eigene DNS-Abfragen.

Gibt es WebRTC-Lecks auch auf Mobilgeräten?#

Ja. Auch mobile Browser unterstützen WebRTC, und ein am Telefon eingestellter WLAN-Proxy deckt nur HTTP-Verkehr ab. Die Proxy-Einrichtung auf dem iPhone erklären wir in Proxy-Einstellungen auf dem iPhone; denselben WebRTC-Test können Sie im mobilen Browser durchführen.

Ich habe das Leck geschlossen, doch die Website erkennt den Proxy trotzdem. Warum?#

Die IP-Adresse selbst gehört womöglich zu einem Rechenzentrum, Zeitzone und Sprache widersprechen dem Proxy-Standort, oder der Browser-Fingerprint stimmt mit Ihrem letzten Besuch überein. Ein Netzwerkleck ist nur eines dieser Signale.

Fazit#

Ein Proxy transportiert den HTTP-Verkehr des Browsers; UDP-Verbindungen von WebRTC und manche DNS-Abfragen liegen womöglich außerhalb dieses Bereichs. Schließen Sie WebRTC-Lecks in Chrome mit der Richtlinie WebRtcIPHandling und in Firefox mit den media.peerconnection-Einstellungen. Nutzen Sie gegen DNS-Lecks bei SOCKS5 die Auflösung auf dem Proxy und bestätigen Sie die Ergebnisse mit dem Konsolentest. Stellen Sie danach sicher, dass Zeitzone, Sprache und Cookies zum Standort des Proxys passen. Tarife für Browser- und Anwendungsverkehr finden Sie in unseren Proxy-Diensten.