Inhalt des Artikels

Einleitung

In diesem Schritt-für-Schritt-Leitfaden lernen Sie, wie Sie WebRTC-Leaks des echten IP-Adress im Betrieb hinter Proxy erkennen und schließen. Wir erläutern im Detail, warum WebRTC-Leaks ein Risiko für die Privatsphäre darstellen, wie man sie überprüft und wie man sie in den gängigen Browsern, über Erweiterungen und in Antidetect-Browsern zuverlässig schließt. In einem speziellen Abschnitt zeigen wir, wie man die Einstellungen korrekt mit einem mobilen Proxy verknüpft und sicherstellt, dass es tatsächlich keine Leaks gibt. Am Ende erhalten Sie einen Checklisten, typische Fehleranalysen, fortgeschrittene Tipps und Antworten auf die häufigsten Fragen. Wenn Sie die Anweisungen genau befolgen, erreichen Sie von Null bis zu einem stabilen Ergebnis ohne Vermutungen und Experimente.

Dieser Leitfaden eignet sich für Anfänger und Fachleute, die schnell und zuverlässig Leaks beseitigen möchten, sowie für Fortgeschrittene, denen feine Einstellungen, Profilreplikation und vorhersehbare Testergebnisse wichtig sind. Vorwissen ist nicht notwendig. Es genügt, wenn Sie einen Browser bedienen können und wissen, was ein Proxy-Server ist.

Was Sie im Voraus wissen sollten: WebRTC ist eine Browsersystemtechnologie, die die öffentlich und lokal IP-Adressen während des Austausch von Verbindungskandidaten (ICE) mitteilen kann. Hinter Proxy kann dies Ihre echte IP offenbaren, wenn keine Maßnahmen getroffen werden. Im Abschnitt "Grundlagen" erklären wir alle Begriffe in einfacher Sprache.

Wie viel Zeit Sie benötigen: Die grundlegende Überprüfung und Schließung des Leaks in einem Browser — 40-60 Minuten; das Hinzufügen von Erweiterungen, Arbeiten mit dem Antidetect-Browser und abschließenden Tests — weitere 20-30 Minuten. Wenn Sie mehrere Browser und Profile gleichzeitig einrichten, planen Sie etwa 90-120 Minuten ein.

Vorbereitung

Bevor Sie beginnen, stellen Sie sicher, dass Sie alles Notwendige haben und verstehen, wie wir das Ergebnis überprüfen werden. Dieser Schritt reduziert das Fehlerrisiko und spart Ihre Zeit.

Benötigte Werkzeuge und Zugänge

  • Zugang zu einem funktionierenden Browser auf dem Computer (Chrome, Edge, Firefox, Opera oder Safari).
  • Zugang zu den Proxy-Einstellungen, die Sie verwenden (HTTP(S) oder SOCKS5). Wenn Sie mit einem mobilen Proxy arbeiten, bereiten Sie den Zugang zu Ihrem Anbieter-Dashboard vor. Beispiel für einen solchen Dienst: mobileproxy.space.
  • Bereitschaft, eine Erweiterung zur Verwaltung von WebRTC zu installieren (z.B. eine Erweiterung, die WebRTC in Chromium-basierten Browsern einschränkt oder deaktiviert) und uBlock Origin für zusätzlichen Schutz.
  • Wenn Sie einen Antidetect-Browser verwenden: Zugang zu Ihrem Konto und dem Profil-Einstellungsfeld.

Systemanforderungen

  • Windows 10/11, macOS 12+ oder ein moderner Linux-Distro.
  • Aktuelle Versionen der Browser (aktuelle Updates für das Jahr 2026). Aktualisieren Sie Ihren Browser vor Beginn.
  • Stabile Internetverbindung.

Was heruntergeladen und installiert werden muss

  • Den Browser, in dem Sie arbeiten möchten.
  • Eine Erweiterung zur Einschränkung von WebRTC für Ihren Chromium-basierten Browser (z.B. WebRTC Control oder WebRTC Leak Prevent). Installieren Sie auch uBlock Origin und aktivieren Sie die Funktion zur Verhinderung von WebRTC-Leaks, wenn diese in Ihren Einstellungen verfügbar ist.
  • Antidetect-Browser (falls erforderlich), wenn Sie mit Profilen arbeiten. Beispiele sind: AdsPower, Dolphin{anty}, Incogniton, GoLogin, Octo Browser usw.

Sicherheitskopien

Wenn Sie mit einem Antidetect-Browser oder einem Unternehmensprofil arbeiten, exportieren oder speichern Sie die aktuellen Profileinstellungen vor Änderungen. Wenn Sie systemweite Richtlinien oder Browser-Flags ändern, dokumentieren Sie die ursprünglichen Werte.

⚠️ Achtung: Schreiben Sie vor der Änderung versteckter Browsereinstellungen (z.B. about:config in Firefox oder flags in Chromium-basierten Browsern) die aktuellen Werte auf. So können Sie zurücksetzen, falls eine Website nicht mehr wie erwartet funktioniert.

✅ Überprüfung: An diesem Punkt sollten Sie Folgendes haben: Zugang zum Browser, Zugänge zum Proxy, eine Liste der zu installierenden Erweiterungen und Sicherheitskopien (wenn Sie das Profil oder die Richtlinien ändern).

Grundlagen

Schlüsselbegriffe in einfacher Sprache

  • WebRTC — eine Browsersystemtechnologie für den Austausch von Audio, Video und Daten in Echtzeit. Für die WebRTC-Verbindung werden Netzwerkanbieter-Kandidaten (ICE) ausgetauscht, auch über STUN/TURN.
  • ICE-Kandidaten — mögliche Verbindungen zwischen zwei Parteien. Dazu können öffentliche und lokale IP-Adressen gehören.
  • STUN/TURN — unterstützende Server, die helfen, Ihre öffentliche IP zu erkennen, Routen zu definieren und die Verbindung selbst hinter NAT und Firewalls herzustellen.
  • mDNS — eine Methode, um Ihre lokale IP bei der Bereitstellung von ICE-Kandidaten zu verbergen, indem lokale Adressen durch temporäre mDNS-Identifikatoren ersetzt werden.
  • Proxy — ein Zwischenserver, über den Ihr HTTP(S) oder SOCKS5-Verkehr läuft. Der Proxy tarnt Ihre echte IP gegenüber den Websites, die Sie besuchen.

Warum WebRTC-Leaks entstehen

Selbst wenn der Browser für den Betrieb über einen Proxy konfiguriert ist, kann WebRTC über den HTTP(S)-Pfad hinaus STUN-Server über UDP ansprechen und die öffentliche IP Ihrer Internetverbindung erhalten. Diese Daten können dann von Skripten auf der Seite gesehen werden. Infolgedessen kann die Website Ihre echte IP erkennen, trotz des Proxys. Das wird als WebRTC-Leak bezeichnet.

Wichtige Informationen vor Beginn

  • Das vollständige Deaktivieren von WebRTC kann Audio- und Videoanrufe, Bildschirmfreigaben und andere Funktionen beeinträchtigen.
  • Das Ziel dieses Leitfadens besteht nicht darin, WebRTC „zu brechen“, sondern sicherzustellen, dass Ihre echte IP nicht aufgedeckt wird. Wo möglich, werden wir „sanfte“ Methoden verwenden: mDNS, Einschränkungen auf die öffentliche Schnittstelle, ICE-Kandidatenregeln.
  • Verschiedene Browser bieten unterschiedliche Kontrollmöglichkeiten. Firefox ermöglicht eine feine Anpassung über about:config. In Chromium-basierten Browsern ist es effektiver, eine Erweiterung oder Richtlinien zu verwenden.

Tipps: Wenn Sie in Ihrer Arbeit überhaupt keine WebRTC-Funktionen benötigen (Anrufe, Dateiübertragungen im Browser), ziehen Sie in Betracht, es in einem für Aufgaben, bei denen Privatsphäre entscheidend ist, strenger abzuschalten.

Schritt 1: Bestimmen Sie die Proxy-Umgebung

Ziel des Schrittes: Verstehen, wie der Verkehr von Ihrem Browser läuft und wo WebRTC den Proxy umgehen kann.

Detaillierte Schritte

  1. Starten Sie den Browser, in dem Sie über Proxy arbeiten.
  2. Überprüfen Sie die aktive Proxy-Konfiguration. Für Chromium-basierte Browser öffnen Sie die Einstellungen: Einstellungen — System — Proxy-Einstellungen öffnen. Stellen Sie sicher, dass Ihr Proxy-Server, Benutzername und Passwort (falls erforderlich) angegeben sind.
  3. Wenn Sie ein Profil in einem Antidetect-Browser verwenden, öffnen Sie die Profileinstellungen und stellen Sie sicher, dass der Proxy dort angegeben ist: Typ (HTTP, HTTPS oder SOCKS5), Host, Port, Benutzername und Passwort, falls erforderlich.
  4. Dokumentieren Sie Ihre aktuelle externe IP, die Websites über Ihren Proxy sehen. Geben Sie in die Suchzeile „my ip“ ein und öffnen Sie einen Dienst, der die externe IP anzeigt. Notieren Sie diese IP als „IP über Proxy“.
  5. Wenn Sie einen mobilen Proxy haben, notieren Sie das Dashboard des Anbieters. Überprüfen Sie beispielsweise in mobileproxy.space die IP-Adresse, den Standort, die Authentifizierungsmethode (über Benutzername/Passwort oder über eine Liste zulässiger IP) und den Status der IP-Rotation.

Wichtige Punkte

  • Proxy ≠ WebRTC. Der Proxy verwaltet HTTP(S)/SOCKS-Verkehr, während WebRTC IP während des ICE-Austauschs offenbart.
  • Wir müssen sicherstellen, dass alle WebRTC-Kandidaten Ihre echte öffentliche und lokale IP nicht enthüllen.

⚠️ Achtung: Wenn Sie Unternehmensrichtlinien im Browser verwenden, können alle Änderungen von Flags oder Erweiterungen durch den Administrator überschrieben werden. Überprüfen Sie, ob es zentrale Richtlinien gibt, die Ihnen erforderliche Optionen entziehen.

Tipps: Erstellen Sie btw sofort ein Notizbuch mit Aufzeichnungen: „IP über Proxy“, „Datum und Uhrzeit“, „Profilname“, „Erweiterung und Version“. Diese Notizen helfen Ihnen, die Einstellungen schnell zu wiederholen oder Probleme zu debuggen.

✅ Überprüfung: Sie haben die IP, die über den Proxy sichtbar ist, dokumentiert und sind sich bewusst, wo und wie der Proxy im Browser oder im Profil konfiguriert ist.

Mögliche Probleme und Lösungen

  • Problem: Der Browser verwendet keinen Proxy. Grund: Falsche Adresse oder Port angegeben. Lösung: Überprüfen Sie das Format des Protokoltyps, Host, Port, Benutzername/Passwort.
  • Problem: Der Proxy erfordert eine Authentifizierung, der Browser fragt jedoch nicht nach Benutzername/Passwort. Grund: Falsches Authentifizierungsschema. Lösung: Geben Sie die Daten manuell im Profil an oder konfigurieren Sie sie in den Systemeinstellungen.

Schritt 2: Überprüfen Sie WebRTC-Leaks in Desktop-Browsern

Ziel des Schrittes: Bestätigen Sie das Vorhandensein oder Fehlen eines Leaks vor Beginn der Konfiguration.

Detaillierte Schritte

  1. Öffnen Sie ein Browserfenster im normalen Modus. Wenn im Browser Erweiterungen aktiviert sind, deaktivieren Sie diese vorübergehend für einen sauberen Test.
  2. Öffnen Sie jeden Dienst, der die Ergebnisse eines WebRTC-Detektors im Browser anzeigt. Führen Sie den Test durch. Achten Sie auf zwei Adresstypen: öffentlichen IP-Kandidaten und lokalen IP-Kandidaten (z.B. Adressen wie 192.168.x.x, 10.x.x.x oder 172.16–31.x.x).
  3. Vergleichen Sie die öffentliche IP, die der WebRTC-Detektor anzeigt, mit der „IP über Proxy“, die Sie zuvor notiert haben. Wenn sie unterschiedlich sind und WebRTC Ihre echte Anbieter-IP zeigt — dann ist das ein Leak.
  4. Wenn lokale IP-Kandidaten klar sichtbar sind, ist das ebenfalls ein potenzielles Konfigurationsleck, da die Website diese Daten nutzen kann, um Fingerprints zu korrelieren und eindeutige Identifikationen zu erstellen.
  5. Dokumentieren Sie die Ergebnisse mit Screenshots oder notieren Sie die öffentlichen und lokalen Adressen, die der Test angezeigt hat. Später können Sie diese mit dem Ergebnis nach der Konfiguration vergleichen.

Wichtige Punkte

  • Testen Sie jeden Browser separat. Ziehen Sie keine Schlussfolgerungen nur aufgrund eines Browsers.
  • Die Ergebnisse hängen von den Versionen und aktivierten Funktionen ab, insbesondere bei Safari und Firefox.

Tipps: Führen Sie den Test im Inkognito-Modus und im normalen Modus durch. Manchmal sind Erweiterungen im Inkognito deaktiviert, und Sie sehen das „nackte“ Bild.

✅ Überprüfung: Sie haben dokumentierte Ergebnisse vor der Konfiguration: Welche öffentlichen und lokalen Adressen WebRTC jetzt ausgibt. Dies ist der Ausgangspunkt.

Mögliche Probleme und Lösungen

  • Problem: Tests zeigen unterschiedliche Ergebnisse auf verschiedenen Websites. Grund: Unterschiedliche Prüfmethoden, Cache und WebRTC-Richtlinien. Lösung: Vergleichen Sie mehrere Ergebnisse; das Hauptziel ist, dass Ihre echte öffentliche IP nirgendwo sichtbar ist.
  • Problem: Nichts wird angezeigt. Grund: Die Website hat keine Erlaubnis erhalten oder der Test ist fehlerhaft. Lösung: Aktualisieren Sie die Seite, erlauben Sie den Zugriff auf Medieneinheiten bei der Aufforderung oder verwenden Sie einen alternativen Tester.

Schritt 3: Schließen Sie WebRTC in Browsern über die Standardkonfiguration

Ziel des Schrittes: Minimieren oder beseitigen Sie das Leak durch die integrierten Browsereinstellungen, wo dies möglich ist.

Chromium-basierte Browser (Chrome, Edge, Opera, Brave usw.)

  1. Öffnen Sie die Browser-Einstellungen. Gehen Sie zu „Datenschutz und Sicherheit“ — „Website-Einstellungen“ — „Erweiterte Berechtigungen“ (Bezeichnungen können abweichen). Suchen Sie nach Abschnitten, die mit Kamera und Mikrofon verbunden sind. Obwohl dies WebRTC nicht deaktiviert, wird der Medienzugriff verweigert, was die Fälle verringert, in denen ICE-Austausch bei Anrufen gestartet wird.
  2. Öffnen Sie die Flags-Seite (chrome://flags oder edge://flags, opera://flags). Suchen Sie nach der Einstellung, die für die Anonymisierung der lokalen IPs in WebRTC verantwortlich ist (z.B. „Anonymize local IPs exposed by WebRTC“ oder „mDNS ICE candidates“). Stellen Sie dies auf „Aktiviert“. Starten Sie den Browser neu.
  3. Überprüfen Sie Unternehmensrichtlinien (falls anwendbar). In Umgebungen mit Richtlinien kann WebRtcIpHandlingPolicy auf „default_public_interface_only“ oder „disable_non_proxied_udp“ gesetzt werden, um direkte nicht-proxierte UDP-Verbindungen zu verbieten. Für normale Benutzer ist dieser Weg nicht zwingend erforderlich.

Firefox (Desktop)

  1. Geben Sie in die Adresszeile about:config ein und bestätigen Sie, dass Sie das Risiko verstehen.
  2. Suchen Sie nach dem Parameter media.peerconnection.enabled und, wenn Sie keine Anrufe über den Browser benötigen, stellen Sie diesen auf false, um WebRTC vollständig zu deaktivieren. Wenn Anrufe benötigt werden, deaktivieren Sie nicht global und verwenden Sie die folgenden Einstellungen.
  3. Setzen Sie media.peerconnection.ice.no_host auf true, um keine lokalen IP-Adressen als ICE-Kandidaten zu übermitteln.
  4. Setzen Sie media.peerconnection.ice.default_address_only auf true, um die Kandidaten nur auf Standardadressen zu beschränken, nicht auf alle Schnittstellen.
  5. Setzen Sie media.peerconnection.ice.obfuscate_host_addresses auf true, um das mDNS-Verstecken der lokalen Adressen zu aktivieren.
  6. Starten Sie Firefox neu.

Safari (macOS, iOS/iPadOS)

  1. Aktivieren Sie das Menü „Entwicklung“ in macOS (Safari — Einstellungen — Erweitert — „Entwicklungsmenü in der Menüleiste anzeigen“).
  2. Gehen Sie zu „Entwicklung“ — „Experimentelle Funktionen“ und überprüfen Sie die mit mDNS ICE-Kandidaten verbundenen Optionen. Aktivieren Sie mDNS ICE-kandidaten, damit lokale IPs nicht direkt offengelegt werden.
  3. In den Website-Einstellungen beschränken Sie den Zugriff auf die Kamera und das Mikrofon für unnötige Websites, damit WebRTC nicht unnötig aktiviert wird.
  4. In iOS/iPadOS aktivieren Sie in „Einstellungen — Safari — Erweiterungen/Experimentelle Funktionen“ die Äquivalente von mDNS ICE-Kandidaten, falls verfügbar, und beschränken Sie den Zugriff auf Kamera/Mikrofon für Websites.

⚠️ Achtung: Das vollständige Deaktivieren von WebRTC kann Webanrufe, Bildschirmfreigaben und einige Unternehmensanwendungen beeinträchtigen. Wenn Sie die Anrufeinrichtungen benötigen, verwenden Sie den Modus mit mDNS und Einschränkung der Kandidaten, anstatt vollständige Deaktivierung.

Tipps: Wenn Sie häufig zwischen Netzwerken und Schnittstellen wechseln (z.B. Ethernet und Wi-Fi), überprüfen Sie die Flags und about:config nach Browser-Updates erneut. Manchmal setzen Updates experimentelle Funktionen zurück.

✅ Überprüfung: Führen Sie den Test aus dem vorherigen Schritt durch. Lokale IPs sollten nicht explizit angezeigt werden, der öffentliche Kandidat sollte sich nicht mit der echten IP des Anbieters decken. Wenn der Test immer noch die echte IP zeigt, gehen Sie zu den Schritten mit den Erweiterungen über.

Mögliche Probleme und Lösungen

  • Problem: Bei den Chromium-Flags gibt es keine Option zur Anonymisierung lokaler IPs. Grund: Browser-Version oder Richtlinien. Lösung: Verwenden Sie eine Erweiterung für WebRTC und uBlock Origin, oder wenden Sie die Richtlinie auf Systemebene an (verfügbar für Administratoren).
  • Problem: Firefox „bricht“ Anrufe nach dem Deaktivieren von WebRTC. Grund: Sie haben media.peerconnection.enabled deaktiviert. Lösung: Aktivieren Sie es erneut und wenden Sie die punktuellen Einstellungen no_host, default_address_only und obfuscate_host_addresses an.

Schritt 4: Schließen Sie WebRTC mit Erweiterungen

Ziel des Schrittes: Erreichen Sie vorhersehbares Verhalten in Chromium-basierten Browsern und fügen Sie eine zusätzliche Schutzebene hinzu.

Detaillierte Schritte

  1. Öffnen Sie das Erweiterungsverzeichnis Ihres Browsers. Finden und installieren Sie eine Erweiterung, die die WebRTC-Richtlinie verwaltet (z.B. WebRTC Control oder WebRTC Leak Prevent). Diese Erweiterungen ermöglichen es Ihnen, die Strategie zu definieren: „Standard öffentliche Schnittstelle nur“, „Nicht-proxierte UDP deaktivieren“ usw.
  2. Öffnen Sie nach der Installation die Einstellungen der Erweiterung. Wählen Sie die Richtlinie aus, die die lokalen Kandidaten verbirgt und nicht-proxiertes UDP verweigert. In der Benutzeroberfläche könnte dies als „Nicht-proxierte UDP deaktivieren“ oder „Verwenden Sie nur die standardmäßige öffentliche Schnittstelle“ bezeichnet werden. Speichern Sie die Einstellungen.
  3. Installieren Sie auch uBlock Origin. Öffnen Sie die Einstellungen und aktivieren Sie die Option, die WebRTC-Leaks verhindert (wenn diese in Ihrer Version verfügbar ist). Dies bietet zusätzlichen Schutz.
  4. Starten Sie den Browser neu oder schalten Sie die Erweiterungen aus und wieder ein, um sicherzustellen, dass die Politik angewendet wurde.

Wichtige Punkte

  • Die Erweiterung sollte in normalen und privaten Fenstern aktiviert sein, wenn Sie beide Modi testen. Überprüfen Sie die Berechtigungen der Erweiterungen.
  • Einige Websites, die WebRTC für Streaming verwenden, können nach Aktivierung einer strengen Richtlinie anders funktionieren. Bewerten Sie den Einfluss auf Ihre Szenarien.

⚠️ Achtung: Installieren Sie keine Erweiterungen aus unsicheren Quellen. Die Berechtigungen für den Zugriff auf „Website-Daten“ geben der Erweiterung umfangreiche Möglichkeiten. Verwenden Sie nur vertrauenswürdige Shops und Entwickler.

Tipps: Wenn Sie zwischen mehreren Richtlinien wechseln (z.B. für Anrufe und für den täglichen Gebrauch), erstellen Sie zwei Browserprofile: „Arbeitsprofil (strenges WebRTC)“ und „Anrufe (mäßiges WebRTC)“.

✅ Überprüfung: Wiederholen Sie den WebRTC-Test. Die öffentliche IP sollte sich nicht mit Ihrer echten Anbieter-IP decken, lokale IPs sollten nicht explizit sichtbar sein. Wenn das Ergebnis negativ ist, wurde das Leak geschlossen.

Mögliche Probleme und Lösungen

  • Problem: Die Erweiterung funktioniert im Inkognito-Modus nicht. Grund: Im privaten Modus deaktiviert. Lösung: Gehen Sie zu „Erweiterungsverwaltung“ und aktivieren Sie „Im Inkognito-Modus zulassen“.
  • Problem: Die Anrufseite kann nicht mehr eine Verbindung herstellen. Grund: Nicht-proxiertes UDP ist verboten. Lösung: Erstellen Sie ein separates Profil mit einer weniger strengen Richtlinie oder deaktivieren Sie vorübergehend das Häkchen für die gewünschte Domain.

Schritt 5: Konfiguration von WebRTC in Antidetect-Browsern

Ziel des Schrittes: Erreichen Sie reproduzierbare Ergebnisse bei der Arbeit mit vielen Profilen, bei denen der Fingerabdruck und die Verhaltensstabilität wichtig sind.

Detaillierte Schritte (universelles Schema)

  1. Öffnen Sie das Dashboard Ihres Antidetect-Browsers (z.B. AdsPower, Dolphin{anty}, Incogniton, GoLogin, Octo Browser usw.).
  2. Erstellen Sie ein neues Profil oder öffnen Sie ein vorhandenes. Suchen Sie im Profilbereich nach „WebRTC“ oder „Netzwerk-/Medien-/Fingerprint-Einstellungen“.
  3. Wählen Sie die WebRTC-Strategie aus: Dies sind in der Regel Optionen wie „Deaktiviert“, „Echt“, „Verändert/Fälscht“, „Nur die Standard öffentliche Schnittstelle“, „Nur Proxy“ oder ähnliche. Wenn Sie keine Anrufe benötigen und maximale Privatsphäre wünschen, wählen Sie „Deaktiviert“ oder eine Option, die lokale Kandidaten ausschließt und nicht-proxiertes UDP verbietet. Wenn Anrufe erforderlich sind, verwenden Sie „Nur Proxy“ oder „nur öffentliche Schnittstelle“ plus mDNS, falls dies im Antidetect-Browser unterstützt wird.
  4. Geben Sie den Proxy im Profil an: Typ (HTTP(S) oder SOCKS5), Host, Port, Benutzername/Passwort. Überprüfen Sie die Verbindung über die eingebaute „Test“-Schaltfläche (in der Regel gibt es im Profil eine Überprüfung).
  5. Speichern Sie das Profil und starten Sie es. Öffnen Sie den WebRTC-Tester und stellen Sie sicher, dass die echte IP nicht sichtbar ist. Dokumentieren Sie das Ergebnis.

Wichtige Punkte

  • In Antidetects gibt es oft Mimikry der WebRTC-Parameter: Generierung von ufrag, ICE-Passwort, SDP-Felder. Versuchen Sie, die Werte nicht ohne Notwendigkeit zu ändern. Ihr Ziel ist es, das Leak zu blockieren, nicht von der Norm abzuweichen.
  • Gleiche WebRTC-Richtlinien in verschiedenen Profilen gewährleisten das gleiche Verhalten auf den Websites.

Tipps: Erstellen Sie eine Profilvorlage mit bereits eingestellter WebRTC-Richtlinie und Proxy. Klonen Sie diese für neue Arbeitsprofile. Das spart Zeit und verringert das Risiko von Fehlern.

✅ Überprüfung: In jedem gestarteten Profil sollten Sie den Test wiederholen. Die echte öffentliche IP sollte nicht angezeigt werden, lokale IP-Kandidaten sollten verborgen oder durch mDNS ersetzt sein.

Mögliche Probleme und Lösungen

  • Problem: Das Profil zeigt bei jedem Start unterschiedliche WebRTC-Ergebnisse an. Grund: Zufällige Generierung von Parametern. Lösung: Stellen Sie den WebRTC-Modus auf „Deaktiviert“ oder „Nur Proxy“ ein und ändern Sie ihn nicht zwischen den Starts.
  • Problem: Die Erweiterung im Profil steht in Konflikt mit den Antidetect-Richtlinien. Grund: Doppelte Einstellung. Lösung: Verwenden Sie entweder die Antidetect-Richtlinie oder die Erweiterung, jedoch nicht gleichzeitig eine von beiden zu ändern.

Schritt 6: Verbindung mit mobilen Proxys

Ziel des Schrittes: Eine korrekte Kombination des Schließens von WebRTC mit mobilen Proxys, um die endgültige Konfiguration sauber und stabil zu gestalten.

Detaillierte Schritte

  1. Bereiten Sie den Zugang zu mobilen Proxys vor. Überprüfen Sie im Dashboard des Anbieters (z.B. mobileproxy.space) die Verbindungseinstellungen: Hostadresse, Port, Proxytyp, Authentifizierung (Benutzername/Passwort oder Liste zulässiger IPs).
  2. Wenn der Anbieter IP-Rotation unterstützt, klären Sie, wie und wann die Rotation erfolgt. Stellen Sie sicher, dass Sie den Test nach der Rotation reproduzieren können.
  3. Geben Sie den mobilen Proxy im Browser oder Antidetect-Profil an: Typ (HTTP(S)/SOCKS5), Host, Port, Benutzername/Passwort. Führen Sie den Verbindungstest (meistens gibt es eine „Proxy überprüfen“-Schaltfläche) durch oder gehen Sie auf eine Website und stellen Sie sicher, dass die Seite geladen wird.
  4. Stellen Sie sicher, dass die WebRTC-Richtlinie bereits eingestellt ist: im Chromium-Browser — durch eine Erweiterung und Flag zur Anonymisierung lokaler IPs, im Firefox — durch about:config, im Antidetect-Browser — durch das Profil.
  5. Öffnen Sie den WebRTC-Tester. Überprüfen Sie, welche öffentliche IP als Kandidat angezeigt wird. Diese sollte mit der IP des mobilen Proxys übereinstimmen und nicht mit Ihrer echten Anbieter-IP. Lokale IPs sollten verborgen sein oder über mDNS bereitgestellt werden.

Wichtige Punkte

  • Mobile Proxys bieten oft zusätzliche Variabilität im Netzwerk (Anbieter, Region). Das ist nützlich, erhöht jedoch die Anforderungen an die Vorhersagbarkeit der WebRTC-Einstellungen.
  • Versuchen Sie, nicht mehrere Parameter auf einmal zu ändern: Zuerst das Leak schließen, danach die IP-Rotation und andere Funktionen aktivieren.

Tipps: Wenn in Ihren Aufgaben die Geolokalisierung wichtig ist, fixieren Sie die Region auf der Seite des mobilen Proxys (z.B. in mobileproxy.space) und vermischen Sie nicht WLAN und Mobilnetz bei gleichzeitiger Verwendung.

✅ Überprüfung: Der Test zeigt die öffentliche IP des mobilen Proxys und nicht Ihre echte. Lokale Adressen sind nicht direkt sichtbar. Nach der Rotation der IP des mobilen Proxys zeigt der erneute Test die neue öffentliche IP an, während die echte IP des Anbieters weiterhin verborgen bleibt.

Mögliche Probleme und Lösungen

  • Problem: Der Test zeigt die echte IP und nicht die mobile. Grund: Nicht-proxiertes UDP ist aktiviert oder die Erweiterung wurde nicht angewendet. Lösung: Überprüfen Sie die WebRTC-Politik in der Erweiterung und in about:config, starten Sie den Browser neu, stellen Sie sicher, dass das Profil wirklich den mobilen Proxy verwendet.
  • Problem: Nach der IP-Rotation sind die Ergebnisse nicht stabil. Grund: Cache oder die Rotation hat nicht rechtzeitig stattgefunden. Lösung: Leeren Sie den Cache, starten Sie den Browser neu, warten Sie auf die bestätigte Rotation im Dashboard des Anbieters und wiederholen Sie den Test.

Schritt 7: Zusätzliche Kontrolle auf der Ebene von Browser und System

Ziel des Schrittes: Erhöhen Sie die Vorhersagbarkeit des Verhaltens, ohne die Legitimität und Benutzerfreundlichkeit zu beeinträchtigen.

Detaillierte Schritte

  1. Überprüfen Sie die Berechtigungen der Websites: Einstellungen — Datenschutz und Sicherheit — Website-Einstellungen — Berechtigungen. Beschränken Sie den automatischen Zugang zu Kamera und Mikrofon; verlangen Sie eine Anfrage vor der Nutzung.
  2. Erstellen Sie ein separates Profil für Aufgaben mit erhöhtem Datenschutz. Verwenden Sie in diesem Profil strenge WebRTC-Richtlinien und ein minimales Set an Erweiterungen.
  3. Wenn Sie Administrator sind, wenden Sie Browser-Richtlinien an, um zentral die WebRTC-Richtlinie festzulegen. Für Benutzer ohne Administratorrechte ist dieser Schritt nicht erforderlich.
  4. Überprüfen Sie nach Updates: Manchmal ändern Browser das Standardverhalten von mDNS oder WebRTC-Flags. Führen Sie einmal im Monat einen Kontrolltest durch.

Wichtige Punkte

  • Sogar bei strengen Richtlinien kann eine Erweiterung bei einem Fehler oder Konflikt deaktiviert werden. Regelmäßige Überprüfungen sind Ihr Freund.
  • Antidetect-Browser werden oft aktualisiert. Überprüfen Sie nach einem Update des Kerncodes die Funktionsweise des WebRTC-Plugins und der Profile erneut.

Tipps: Entwickeln Sie eine Routine: „Neues Profil - sofort WebRTC-Test“, „Browser-Update - sofort WebRTC-Test“, „Proxy oder Anbieter gewechselt - sofort WebRTC-Test“. Dies dauert 1-2 Minuten und spart viele Stunden.

✅ Überprüfung: Sie haben bestätigt, dass die neue organisatorische Routine und Richtlinien funktionieren: Testergebnisse zeigen in keinem Profil und nach Updates die echte IP an.

Mögliche Probleme und Lösungen

  • Problem: Nach dem Update hat die Erweiterung die Einstellungen zurückgesetzt. Grund: Konfiguration zurückgesetzt. Lösung: Exportieren Sie die Erweiterungseinstellungen, um sie schnell bei einem Reset zu importieren.
  • Problem: Browser-Richtlinien sind nicht verfügbar. Grund: Keine Administratorrechte. Lösung: Verwenden Sie eine Erweiterung und eine Profilstrategie ohne systemweite Richtlinien.

Schritt 8: Diagnose mit mehreren Tests

Ziel des Schrittes: Lernen Sie, das Ergebnis mit verschiedenen Methoden zu überprüfen und Abweichungen zu finden.

Detaillierte Schritte

  1. Wiederholen Sie den WebRTC-Test auf zwei bis drei verschiedenen Seiten. Vergleichen Sie, dass die echte IP des Anbieters nicht sichtbar ist und keine lokalen IPs ausdrücklich angezeigt werden.
  2. Führen Sie einen einfachen Netzwerktest auf DNS-Ebene durch. Öffnen Sie die Eingabeaufforderung. Unter Windows führen Sie aus: nslookup -type=txt o-o.myaddr.l.google.com 8.8.8.8. Unter macOS/Linux führen Sie aus: dig +short TXT o-o.myaddr.l.google.com @8.8.8.8. Stellen Sie sicher, dass die Adresse dem Pfad über das Proxy-Netzwerk entspricht, wenn Sie einen systemweiten Proxy oder Tunnel konfiguriert haben. Wenn der Proxy nur im Browser konfiguriert ist, kann dieser Test Ihre echte IP anzeigen, was für Systemebene normal ist.
  3. Testen Sie den Zugriff auf Kamera und Mikrofon auf Websites, wo diese tatsächlich benötigt werden. Überprüfen Sie, ob der Anruf funktioniert, wenn Sie absichtlich die „mäßige“ WebRTC-Strategie gewählt haben.

Wichtige Punkte

  • Der DNS-Ebenentest ersetzt keinen WebRTC-Test, hilft aber zu verstehen, wohin der systemweite Verkehr außerhalb des Browsers fließt.
  • Die Hauptmetrik für uns ist, dass JavaScript auf der Seite Ihre echte öffentliche IP nicht sieht.

Tipps: Führen Sie ein Testprotokoll: Datum, Browser, Profil, Ergebnis, Notizen. Das hilft, seltene Regressionen nach Updates zu identifizieren.

✅ Überprüfung: Alle Browser-Tests geben ein einheitliches Ergebnis: Die echte IP wird nicht offengelegt, lokale IPs werden nicht ausdrücklich veröffentlicht.

Mögliche Probleme und Lösungen

  • Problem: Unterschiedliche WebRTC-Tester zeigen unterschiedliche Felder an. Grund: Unterschiedliche Tiefe der Sammlung. Lösung: Achten Sie auf das Wesentliche — das Auftreten der echten öffentlichen IP oder lokaler IP-Kandidaten; lassen Sie sich nicht von sekundären Metriken verunsichern.
  • Problem: Zufällige Leak-Spitzen. Grund: Die Erweiterung hat sich deaktiviert oder die Richtlinie wurde nicht angewendet. Lösung: Starten Sie den Browser neu, überprüfen Sie die Berechtigungen der Erweiterung, wiederholen Sie den Test.

Ergebnisüberprüfung

Checkliste, was funktionieren sollte

  • Der WebRTC-Test in Ihrem Hauptbrowser zeigt nicht die echte öffentliche IP des Anbieters an.
  • Die lokalen IP-Adressen sind nicht ausdrücklich sichtbar oder wurden durch mDNS-Kandidaten ersetzt.
  • Wenn ein mobiler Proxy verwendet wird, stimmt der öffentliche IP-Kandidat mit der IP des mobilen Proxys überein.
  • Bei der Rotation von mobilen IPs ändert sich das Ergebnis im Test auf eine neue öffentliche IP, aber nicht auf die echte IP des Anbieters.
  • Anrufe und erforderliche Funktionen funktionieren im Profil mit einer moderaten WebRTC-Politik (wenn dies für Ihre Aufgabe erforderlich ist).

Wie man es testet

  1. Starten Sie die endgültige Konfiguration: Browser/Profil mit aktiviertem Proxy und WebRTC-Politik.
  2. Öffnen Sie den WebRTC-Tester und notieren Sie das Ergebnis.
  3. Wenn Sie einen mobilen Proxy verwenden, führen Sie nach Möglichkeit eine IP-Rotation durch und wiederholen Sie den Test.
  4. Vergleichen Sie mit den ursprünglichen Notizen. Stellen Sie sicher, dass die echte IP in keinem Fall erscheint.

DNS-Lecktest

Für interne DNS-Ebenenprüfungen verwenden Sie das allgemeine Prinzip: Führen Sie die systemweiten Befehle aus dem vorherigen Schritt aus oder verwenden Sie jeden zuverlässigen Dienst zur Überprüfung von DNS-Lecks. Es ist wichtig zu verstehen: Wenn der Proxy nur im Browser konfiguriert ist, kann der systemweite DNS-Test Ihre echte IP anzeigen — das ist normal und bedeutet nicht, dass es ein WebRTC-Leck im Browser gibt. Im Kontext dieses Leitfadens bleibt der browserseitige WebRTC-Test die zentrale Quelle der Wahrheit. Um schnell zu den DNS-Überprüfungen zurückzukehren, verwenden Sie den internen Link DNS-Lecktest.

Tipps: Wenn Sie eine gemeinsame Dokumentation im Team erstellen, fügen Sie Ihre „Vorher“ und „Nachher“-Screenshots mit Kommentaren hinzu. Das wird zum Maßstab und erleichtert das Onboarding neuer Mitarbeiter.

✅ Überprüfung: Alle Punkte der Checkliste sind bestätigt; in den Browser-Tests wird die echte IP nicht offengelegt; bei der Rotation des mobilen Proxys ändert sich nur der öffentliche IP-Kandidat des Proxys.

Typische Fehler und Lösungen

  • Problem: Nach allen Schritten ist die echte IP immer noch in einem der Tester sichtbar. Grund: Die Erweiterung hat keine Berechtigungen im privaten Modus erhalten oder die Richtlinie wurde nicht angewendet. Lösung: Aktivieren Sie die Erweiterung für private Fenster, starten Sie den Browser neu, überprüfen Sie Flags und about:config, wiederholen Sie den Test.
  • Problem: Anrufe im Browser sind verschwunden. Grund: WebRTC wurde vollständig deaktiviert. Lösung: Aktivieren Sie WebRTC wieder, aber verbergen Sie lokale IPs und verwenden Sie mDNS; verbieten Sie nur das nicht-proxierte UDP.
  • Problem: Antidetect-Profile geben unterschiedliche Ergebnisse. Grund: Verschiedene WebRTC-Modi oder unterschiedliche Erweiterungssets. Lösung: Erstellen Sie eine Profilvorlage, synchronisieren Sie den WebRTC-Modus, dokumentieren Sie die Liste der Erweiterungen.
  • Problem: Nach einem Browser-Update ist das Leak zurückgekommen. Grund: Zurücksetzen von Flags/Erweiterungseinstellungen. Lösung: Führen Sie eine schnelle Prüfung der Einstellungen durch, importieren Sie die gespeicherte Konfiguration, überprüfen Sie mit Tests.
  • Problem: Auf einer Website gibt es kein Leak, auf einer anderen schon. Grund: Unterschiedliche Testmethoden, möglicher direkter STUN-Aufruf. Lösung: Stellen Sie sicher, dass „Nicht-proxiertes UDP deaktivieren“ aktiviert ist, überprüfen Sie uBlock Origin und die Berechtigungen der Erweiterung.
  • Problem: Der mobile Proxy ändert die IP, und der Test zeigt manchmal Zwischenwerte. Grund: Die Rotation dauert etwas, Cache. Lösung: Warten Sie auf das Ende der Rotation, leeren Sie den Cache, aktualisieren Sie die Seite, wiederholen Sie den Test.
  • Problem: Betriebsrichtlinien der Betriebssystemebene verbieten die benötigten Flags. Grund: Unternehmensrichtlinie. Lösung: Fragen Sie den Administrator oder verwenden Sie den unterstützten Weg mit Erweiterungen ohne Konflikte.

Zusätzliche Möglichkeiten

Fortgeschrittene Einstellungen

  • Chromium Enterprise-Richtlinie: Stellen Sie WebRtcIpHandlingPolicy zentral für alle Arbeitsstationen auf „default_public_interface_only“ oder „disable_non_proxied_udp“ ein.
  • Firefox about:config: Kombinieren Sie mDNS und das Verbot von Host-Kandidaten, um Signaturen zu minimieren.
  • Antidetect: Speichern Sie die Version des Kernels und die WebRTC-Richtlinie in einer Vorlage, um bei einer Aktualisierung des Kernels schnell nur ein Beispielprofil zu überprüfen.

Optimierung

  • Reduzieren Sie die Anzahl der Erweiterungen. In den meisten Fällen genügt eine erstellte WebRTC-Erweiterung plus uBlock Origin.
  • Trennen Sie die Profile nach Zweck: strenges Profil für Privatsphäre, moderates für Anrufe.

Was sonst noch getan werden kann

  • Erstellen Sie einen Richtlinienregulationsplan für das Team: Wer und wann führt Nachprüfungen der Tests nach Updates durch.
  • Digitalisieren Sie die Ergebnisse: Speichern Sie Testprotokolle in einem gemeinsamen Repository, um die Dynamik zu sehen und zufällige Regressionen auszuschließen.

Tipps: Wenn Sie häufig die Proxys oder Anbieter wechseln, erstellen Sie eine kurze Checkliste aus 6-8 Punkten und halten Sie sie griffbereit. Das beschleunigt Ihre tägliche Arbeit.

FAQ

1. Warum kann WebRTC über Proxy immer noch meine echte IP anzeigen?

Weil WebRTC ICE-Kandidaten und STUN verwendet, die den HTTP(S)-Pfad umgehen können, einschließlich nicht-proxiertem UDP. Ohne spezielle Maßnahmen kann der Browser Ihre öffentliche IP des Anbieters aufdecken.

2. Ist es genug, WebRTC einfach zu deaktivieren?

Das ist radikal und beendet leaks, könnte aber Anrufe und einige Anwendungen beschädigen. Es ist besser, die Modi mit mDNS, Einschränkung lokaler IPs und Blockierung von nicht-proxiertem UDP zu verwenden, wenn Sie WebRTC-Funktionen benötigen.

3. Braucht man sowohl die Erweiterung als auch die Änderungen der Flags?

Häufig reicht die Erweiterung aus. Aber aktives mDNS auf der Flag-Ebene plus die Erweiterung bieten ein vorhersehbareres Ergebnis, besonders nach Updates.

4. Welchen Modus sollte man in einem Antidetect-Browser wählen?

Wenn Anrufe nicht benötigt werden – „Deaktiviert“ oder „Nur Proxy“ mit der Blockierung nicht-proxierter UDP. Wenn Anrufe nötig sind - „nur öffentliche Schnittstelle“ plus mDNS und Medienzugriffssteuerung.

5. Wie kann man feststellen, dass lokale IPs nicht sichtbar sind?

In der Zeile mit ICE-Kandidaten sollten keine bekannten Muster wie 192.168.x.x, 10.x.x.x oder 172.16–31.x.x sichtbar sein. Stattdessen sollten mDNS-Identifikatoren erscheinen.

6. Ich habe einen mobilen Proxy, aber der Test zeigt immer noch die echte IP an.

Überprüfen Sie die Erweiterung und die WebRTC-Politik. Häufig ist nicht-proxiertes UDP aktiviert, oder die Erweiterung ist in diesem Profil oder im privaten Modus nicht aktiv.

7. Was bringt ein mobiler Proxyanbieter wie mobileproxy.space?

Er bietet eine stabile mobile IP mit der Möglichkeit, die Region zu wählen. In Kombination mit richtig konfiguriertem WebRTC erhalten Sie eine saubere und vorhersehbare Konfiguration ohne Lecks Ihrer echten IP.

8. Muss man einen DNS-Lecktest durchführen?

Für das Verständnis der Systemebenen sei dies nützlich, aber der browserseitige WebRTC-Test ist entscheidend in diesem Leitfaden. Der DNS-Test ersetzt nicht den WebRTC-Test. Verwenden Sie den internen Link DNS-Lecktest für eine schnelle Navigation zu den Details.

9. Was tun, wenn nach dem Browser-Update alles kaputt ist?

Überprüfen Sie die mDNS-Flags und die Politiken der Erweiterung, installieren Sie die Erweiterungen gegebenenfalls neu und wiederholen Sie die Tests. Halten Sie die Exportkonfiguration bereit.

10. Kann man alle Risiken eines Leaks vollständig ausschließen?

Praktisch ist es möglich, sie für Browserszenarien auf null zu reduzieren. Halten Sie sich an das Reglement: Erweiterungen, Flags, Tests nach Updates und Überprüfung der Profile. Dies sorgt für ein stabiles, leakfreies Ergebnis.

Fazit

Sie haben den kompletten Prozess durchlaufen: Sie haben gelernt, was ein WebRTC-Leak ist und warum es hinter Proxy gefährlich ist, Sie haben gelernt, wie man ein Leak überprüft, wie man es mit eingebauten Browsermitteln, mit Erweiterungen und in Antidetect-Browsern schließt, und Sie haben alles richtig mit einem mobilen Proxy verknüpft sowie die finalen Tests durchgeführt. Jetzt haben Sie eine Checkliste, einen Satz fertiger Lösungen für typische Probleme und das Verständnis, wie Sie die Konfiguration nach Updates aufrecht erhalten können.

Was zu tun ist: Wenden Sie die Einstellungen auf alle Browser und Profile an, mit denen Sie arbeiten; automatisieren Sie die Test-Routine; falls erforderlich, implementieren Sie zentrale Richtlinien in Ihrer Organisation. Wenn Sie mobile Proxys verwenden, wie z.B. mobileproxy.space, standardisieren Sie die Rotation und Dokumentation der Ergebnisse, damit jeder Mitarbeiter die Konfiguration ohne Fehler reproduzieren kann.

Wohin Sie sich weiterentwickeln können: Lernen Sie die Besonderheiten der Abwehr anderer kontextbedingter Leaks (Canvas, AudioContext, WebGL), verstehen Sie die Isolationsrichtlinien von Websites, Cookie-Strategien und das Fingerabdruckmanagement. Aber die Basis — das Fehlen eines Web-Leaks der echten IP über WebRTC — ist bereits konfiguriert und getestet.

Über den Autor

Roman Melnikov

Roman Melnikov

Technical Writer and System Administrator

Berufserfahrung: Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.
Ausbildung: Bauman Moscow State Technical University. Information Systems and Technologies
Expertise:
Technical Documentation DevOps System Administration Linux Docker and Kubernetes CI/CD Infrastructure Automation Cloud Technologies System Monitoring Bash and Python Scripting

Diesen Artikel teilen: