FuzeVPNEinfach. Klar. Direkt.
Anmelden Abonnieren
Sprache wählenDE

Sprache wählen

Abonnieren
Menü
Sprache wählenDE

Sprache wählen

Abonnieren

Verbindung und DNS

WebRTC-Leak-Test

Untersuchen Sie WebRTC-Verbindungsadressen und vergleichen Sie öffentliche Kandidaten mit dem erwarteten Ausgang.

Testkonfiguration

Optionale TURN-Konfiguration

Ein TURN-Relay kann zeigen, dass der Browser einen Kandidaten des folgenden Typs verwenden kann: relay. Die eingegebenen Zugangsdaten dienen der Anmeldung bei TURN; dieses Werkzeug speichert sie nicht und sendet sie nicht an unseren Server.

Datenschutz: STUN/TURN- und Echo-Dienste sehen zwangsläufig die Quelladresse, über die sie erreicht werden. Kandidaten und Bericht bleiben im Arbeitsspeicher dieses Tabs, sofern Sie sie nicht exportieren.

Bereit. Der Test greift weder auf Kamera noch Mikrofon zu.

Wie soll ich das Ergebnis interpretieren?

  • host kennzeichnet eine lokale Schnittstelle, oft hinter einem mDNS-Namen verborgen, der endet auf .local.
  • srflx ist eine von einem STUN-Server ermittelte reflexive Adresse; vergleichen Sie sie mit dem erwarteten VPN-Ausgang.
  • relay gehört zum TURN-Relay und stellt Ihre Zugangsadresse nicht unmittelbar dar.
  • Das Fehlen eines öffentlichen Kandidaten kann auf Browserschutz, Netzwerkblockierung oder ein Zeitlimit zurückgehen. Allein beweist dies nicht das Fehlen eines Lecks.

Vorher und nachher vergleichen

Führen Sie denselben Test auf demselben Gerät durch und speichern Sie das Ausgangsergebnis. Aktivieren Sie Ihr VPN oder ändern Sie eine passende Einstellung. Wiederholen Sie den Test unter denselben Bedingungen und speichern Sie das neue Ergebnis.

Speichern Sie ein Vorher- und ein Nachher-Ergebnis, um beide zu vergleichen.

Was zeigt dieser Test?

WebRTC kann andere Netzwerkwege wählen als gewöhnliche Website-Anfragen. Dieser Test zeigt mögliche Verbindungsadressen, ohne einen Anruf zu starten. Eine private IP oder ein mDNS-Name ist etwas anderes als eine öffentliche Adresse Ihres Internetanbieters. Ein TURN-Relais bezeichnet wiederum den Relaisserver und nicht unmittelbar Ihren eigenen Anschluss.

So führen Sie den Test durch

  1. Halten Sie den Verbindungszustand zunächst konstant. Tragen Sie die erwartete VPN-IP nur ein, wenn Sie eine verlässliche, unabhängig bestätigte Referenz besitzen.
  2. Starten Sie die Kandidatensammlung. Optional können direkte IP-Echoanfragen des Browsers den HTTPS-Weg zum Vergleich messen.
  3. Lesen Sie Typ, Familie, Geltungsbereich und Vergleichszustand jedes Kandidaten. Prüfen Sie auch, ob die Sammlung vollständig abgeschlossen wurde.

So funktioniert die Messung

Der Browser sammelt ICE-Kandidaten, mögliche Wege für den Verbindungsaufbau, zunächst ohne und danach mit konfigurierten STUN/TURN-Servern. Er unterscheidet lokale, serverreflexive, peerreflexive und Relais-Kandidaten.

Ein Datenkanal startet die Sammlung ohne Kamera- oder Mikrofonberechtigung. Die Kandidaten bleiben im Browser; STUN, TURN und optionale Echodienste sehen die Quelladresse ihrer jeweiligen Verbindung.

Ergebnisse verstehen

Öffentliche Adresse entspricht der Referenz
Ein Kandidat stimmt mit der erwarteten VPN-Adresse oder einem verwertbaren Echo derselben Familie überein. Das unterstützt die Übereinstimmung für diese Beobachtung.
Unerwartete öffentliche Adresse
Der Kandidat kann einen anderen Weg verwenden. Prüfen Sie Typ und Familie, bevor Sie ein mögliches Umgehen der vorgesehenen VPN-Verbindung annehmen.
Private, vermittelte oder unvollständige Angaben
Private und mDNS-Kandidaten brauchen eine andere Einordnung; Relais-Adressen gehören zu TURN. Eine leere oder fehlerhafte Sammlung bleibt unbestimmt, auch bei erfolgreichem HTTPS-Echo.

Vorher und nachher vergleichen

  1. Speichern Sie im selben Gerät und Browserprofil Typen, Familien, Servereinstellungen, Echooptionen und erwartete Adresse.
  2. Ändern Sie eine passende Routing- oder WebRTC-Einstellung und wiederholen Sie die gleiche Sammlung.
  3. Vergleichen Sie öffentliche Kandidaten je Familie und Typ. Ändern Sie die erwartete IP erst, wenn deren Wechsel unabhängig bestätigt ist.

Grenzen des Tests

  • Auch wenn die Sammlung keine öffentliche Adresse zeigt, ist das kein Beleg dafür, dass jede WebRTC-Verbindung unerwünschte Wege vermeidet.
  • Ohne erwartete IP oder verwertbares passendes Echo lässt sich eine öffentliche Adresse nicht automatisch als Datenleck bezeichnen.

Was Sie gegebenenfalls ändern können

Ein öffentlicher Kandidat scheint den falschen Anbieterweg zu benutzen.
Prüfen Sie Anwendungsrouting und die Behandlung dieser IP-Familie im VPN. Wiederholen Sie mit denselben Servern und einer bestätigten Referenz.
Die Sammlung ist unvollständig.
Prüfen Sie Browser-Regeln, Firewall und Serververfügbarkeit. Behalten Sie bis zu einer verwertbaren Sammlung den unbestimmten Zustand bei.

Häufige Fragen

Wird mein Mikrofon aktiviert?

Nein. Der Test verwendet einen Datenkanal und fordert weder Kamera noch Mikrofon an.

Ist jede andere IP ein Leck?

Nein. Relais, verschiedene IP-Familien und absichtlich getrennte Wege können legitime Unterschiede erklären.

Quellen und technische Hinweise