WebRTC-Leaks: Wie Ihre echte IP an einem Proxy vorbeikommt, und wie Sie sie testen und beheben

Sie richten einen Proxy ein, öffnen eine IP-Abfrage, und sie zeigt die IP des Proxys. Alles erledigt? Nicht immer. Eine Seite kann Ihre echte IP weiterhin über WebRTC finden, eine Browser-Funktion, die die Proxy-Einstellungen Ihres Browsers von Haus aus ignoriert. Wenn Sie Residential-Proxys nutzen, um eine Website wie ein lokaler Besucher zu sehen, kann ein WebRTC-Leak das ohne sichtbares Anzeichen zunichtemachen.

Dieser Leitfaden erklärt, wie das Leck entsteht, wie Sie es in zwei Minuten testen und wie Sie es in Chrome, Firefox und automatisierten Browsern schließen.

Wie das Leck entsteht

Mit WebRTC können Browser Anrufe führen und Daten direkt aneinander senden. Dafür sammelt jeder Browser „ICE-Kandidaten“: Adressen, unter denen er erreichbar sein könnte. Ein Schritt ist die Frage an einen STUN-Server per UDP: „Von welcher öffentlichen Adresse siehst du mich kommen?“ Die Antwort landet in einem Kandidaten, den das JavaScript der Seite lesen kann.

Das Problem ist der Weg, den diese Frage nimmt. Ein typischer HTTP-Proxy transportiert nur Ihre Webanfragen, kein UDP. Die STUN-Anfrage verlässt Ihr Gerät also über Ihre eigene Verbindung, und die Antwort ist Ihre echte öffentliche IP. RFC 8828, der IETF-Standard zum Umgang mit Adressen in WebRTC, sagt es deutlich: STUN-Prüfungen können einen Proxy umgehen und die öffentliche IP eines Clients preisgeben, wenn direkter Internetzugang erlaubt ist. Er empfiehlt außerdem, WebRTC-Verkehr wegen der Anrufqualität standardmäßig nicht über Proxys zu senden.

Zwei Details sind wichtig:

• Lokale Adressen sind heute meist verborgen. Chrome und Firefox ersetzen Ihre private Netzwerkadresse auf den meisten Seiten durch einen zufälligen .local-Namen. In Firefox ist das die Einstellung media.peerconnection.ice.obfuscate_host_addresses, standardmäßig aktiv. Das eigentliche Risiko ist Ihre öffentliche IP.
• Die Seite braucht keine Berechtigung. Das Sammeln von Kandidaten erfordert keinen Kamera- oder Mikrofonzugriff, es gibt also keine Abfrage.

Test in zwei Minuten

Sie brauchen keine Testseite eines Drittanbieters. Öffnen Sie die Seite, die Sie interessiert, oder irgendeine Seite, bei eingeschaltetem Proxy, öffnen Sie die Entwicklerkonsole (F12) und fügen Sie Folgendes ein:

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

Suchen Sie die Zeilen mit typ srflx. Die Adresse in dieser Zeile ist die öffentliche IP, die der STUN-Server gesehen hat.

• Stimmt sie mit Ihrer IP zu Hause oder im Büro überein, hat WebRTC ein Leck.
• Stimmt sie mit der IP des Proxys überein oder gibt es gar keine srflx-Zeile, ist alles in Ordnung.
• Zeilen mit typ host und einem .local-Namen sind Ihre verborgene lokale Adresse und zu erwarten.

Vergleichen Sie dann mit einer IP-Abfrage wie IP Info im selben Browser. Sie sollte die IP und den Standort des Proxys zeigen. Zeigt die Abfrage den Proxy, die srflx-Zeile aber Sie, funktioniert der Proxy, und WebRTC geht an ihm vorbei.

Lösung für Chrome

Am einfachsten: eine Erweiterung nutzen, die es verwaltet. Die Shifter-Browser-Erweiterung schaltet den WebRTC-Leak-Schutz standardmäßig ein, solange Sie verbunden sind. Technisch steuern Chrome-Erweiterungen dies über die Datenschutzeinstellung webRTCIPHandlingPolicy. Wenn bereits eine andere Erweiterung WebRTC steuert, kann nur eine von beiden gewinnen, und die Shifter-Erweiterung meldet, wenn ihr Schutz nicht aktiv ist. Entfernen oder deaktivieren Sie die andere.

Verwaltete Computer: Chrome hat eine Unternehmensrichtlinie, WebRtcIPHandling, mit vier Werten:

Wert	Was WebRTC nutzt
default	Alle verfügbaren Netzwerkschnittstellen
default_public_and_private_interfaces	Die öffentlich erreichbare Schnittstelle, private Adressen erlaubt
default_public_interface_only	Nur die öffentlich erreichbare Schnittstelle, keine privaten Adressen
disable_non_proxied_udp	TCP über den Proxy; UDP nur, wenn der Proxy es unterstützt

Nur disable_non_proxied_udp stoppt das Leck der öffentlichen IP hinter einem Proxy. Die beiden Werte mit „public interface“ fragen den STUN-Server weiterhin über Ihre eigene Verbindung ab.

Lösung für Firefox

Die Shifter-Erweiterung übernimmt das auch in Firefox. Für die manuelle Einstellung öffnen Sie about:config und setzen:

• media.peerconnection.ice.proxy_only_if_behind_proxy auf true: WebRTC nutzt den Proxy nur, wenn einer konfiguriert ist. Das ist die gezielte Lösung.
• media.peerconnection.ice.default_address_only auf true: Es wird nur die Standardroute verwendet. Das verbirgt zusätzliche lokale Adressen, stoppt allein aber nicht das Leck der öffentlichen IP.
• media.peerconnection.enabled auf false: schaltet WebRTC vollständig ab. Das ist die gröbste Option und macht Anrufe in diesem Browser unbrauchbar.

Führen Sie danach den Test in der Konsole erneut aus: Die srflx-Zeile sollte verschwunden sein oder die IP des Proxys zeigen.

Lösung für automatisierte Browser

Playwright, Puppeteer und Selenium starten einen echten Browser und haben deshalb dasselbe Leck. Starten Sie Chromium mit:

--force-webrtc-ip-handling-policy=disable_non_proxied_udp

Setzen Sie für Firefox dieselben about:config-Einstellungen im Profil, das Ihr Framework startet. Führen Sie dann den obigen Konsolentest aus Ihrem Skript aus und prüfen Sie das srflx-Ergebnis als Teil Ihrer Setup-Checks. Unser Leitfaden zu Residential-Proxys in Selenium und Playwright zeigt, wo diese Optionen hingehören.

WebRTC ist nicht das einzige Leck

Schließen Sie gleich die verwandten Lücken:

• DNS. Namensabfragen können den Proxy umgehen und über Ihr eigenes Netzwerk aufgelöst werden. Unser Leitfaden zum Verhindern von DNS-Leaks behandelt socks5h und die Prüfung.
• IPv6. Wenn Ihr Proxy-Pfad nur IPv4 nutzt, verwendet ein Browser mit zusätzlichem IPv6 dieses eventuell für einige Anfragen.
• Zeitzone und Sprache. Sie verraten Ihre IP nicht, können aber dem Standort Ihres Proxys widersprechen.

Das Fazit

Ein WebRTC-Leak entsteht, weil der Browser einen STUN-Server per UDP nach Ihrer Adresse fragt und die meisten Proxys nur Webverkehr transportieren. Testen Sie es mit dem Konsolen-Snippet: Ist die srflx-Adresse Ihre, kann die Seite sie auch sehen. Schalten Sie den Leak-Schutz in der Shifter-Erweiterung ein oder setzen Sie disable_non_proxied_udp in Chrome und proxy_only_if_behind_proxy in Firefox, und testen Sie dann erneut.