Start · Werkzeuge · WebRTC-Test
WebRTC
WebRTC-Adressen auf diesem Browser ansehen
Eine .local-Adresse ist eine Maske des Browsers, keine Garantie, dass niemand eine öffentliche Adresse sieht. Der Test sagt, was dieser Browser in diesem Lauf gemeldet hat.
- Kandidaten bleiben im Tab
- mDNS gilt nicht als LAN-Leak
- STUN wird genannt
- Kein VPN-Ranking
WebRTC-Adressen auf diesem Browser ansehen?
Eine .local-Adresse ist eine Maske des Browsers, keine Garantie, dass niemand eine öffentliche Adresse sieht. Der Test sagt, was dieser Browser in diesem Lauf gemeldet hat. Es wird nichts gelesen, bevor Sie starten. Das Öffnen zeichnet kein Canvas, öffnet kein WebRTC und fragt keine Adresse ab.
RFC 8828: WebRTC IP Address Handling Requirements
Zuletzt aktualisiert
Browser prüfen
Es wird nichts gelesen, bevor Sie starten. Das Öffnen zeichnet kein Canvas, öffnet kein WebRTC und fragt keine Adresse ab.
Woher die Kandidaten kommen
Die Seite öffnet eine kurze RTCPeerConnection, sammelt ICE-Kandidaten und schließt sie.
Ein STUN-Server lässt den Browser eine Server-Reflexivadresse lernen. Die Anfrage geht an den STUN-Host, nicht in ein CreatorPrivacyKit-Profil. Kandidatenzeilen werden nicht hochgeladen.
Private Adresse und Reflexivadresse
Ein Host-Kandidat mit 192.168.x zeigt der Seite eine private Netzadresse.
Die Server-Reflexivadresse ist die Adresse, die der STUN-Server sah. Weicht sie von der Adresse dieser Website ab, können VPN, Proxy oder eine andere Schnittstelle im Weg liegen. Der Test entscheidet nicht, welche die Anbieteradresse ist.
.local ist nicht die rohe LAN-IP
Namen auf .local sind mDNS-Masken, damit die Seite die rohe LAN-Adresse nicht lernt. Sie gelten als geschützt, nicht als geleakt.
Bei Timeout oder Fehler der ICE-Sammlung lautet das Ergebnis unbestimmt, nicht geschützt. Eine abgeschlossene Sammlung ohne Kandidaten bedeutet nur, dass diesmal keine Kandidaten beobachtet wurden.
Wie die Zeilen zu lesen sind
Eine rohe private Adresse ist direkte Offenlegung. Eine öffentliche Reflexivadresse ist zunächst nur eine Beobachtung; ohne Vergleich mit der HTTP-Adresse dieser Seite und Hinweis auf einen anderen Pfad nennen wir sie kein VPN-Leak.
Nur Relay heißt: der Browser hat eine Relay-Adresse statt der Host-Adresse angeboten. Das ist kein Beleg, dass jedes Programm auf dem Rechner abgedeckt ist.
Was sich versuchen lässt
Der WebRTC-Schutz des Browsers, ein VPN, das WebRTC behandelt, oder WebRTC abschalten, wenn Sie den Funktionsverlust hinnehmen.
Kein Markenname garantiert das. Nach der Änderung erneut scannen.
Ein Headless-Chrome-Lauf, 26. Oktober 2026
Am 26. Oktober 2026 öffnete ein headless Google Chrome 154.0.8037.92 eine RTCPeerConnection mit iceServers stun:stun.cloudflare.com:3478, legte einen Datenkanal namens cpk an und beendete das Sammeln nach 4 Sekunden oder bei abgeschlossenem ICE. Diese STUN-URL, dieser Kanalname und diese 4-Sekunden-Grenze entsprechen collectWebRtcSignals in src/browser-privacy/webrtc.js. Der Scan-Knopf der veröffentlichten Seite wurde nicht gedrückt. Chrome startete mit --no-sandbox und --disable-dev-shm-usage.
Das Sammeln endete als timeout-4000 nach 4002 ms. Zwei UDP-Kandidaten waren schon da: ein host-Kandidat, dessen Adresse ein mDNS-Name .local war und keine rohe private IP, und ein Server-Reflexiv-Kandidat mit öffentlicher IPv4. Es gab kein prflx, kein relay und kein IPv6. Die Adresszeichenfolgen stehen hier nicht. Die vom Server gesehene HTTP-Adresse wurde nicht abgefragt. Das ist der Fall öffentliches srflx ohne Vergleich mit der HTTP-Adresse. Es ist kein Urteil über ein VPN.
Ein zweiter Start ergänzte --force-webrtc-ip-handling-policy=disable_non_proxied_udp. Das Sammeln endete wieder als timeout-4000, nach 4001 ms, mit denselben Zählwerten. Gleiche Zählwerte beweisen nicht, dass das Flag in diesem Headless-Start gegriffen hat.
Die statische WebRTC-Seite von BrowserLeaks, gelesen am 26. Oktober 2026 ohne Ausführung ihres Skripts, zeigt weiter Überschriften für eine entfernte IP, Unterstützung von RTCPeerConnection und RTCDataChannel, eine lokale WebRTC-IP, eine öffentliche WebRTC-IP, eine Sitzungsbeschreibung und Mediengeräte. Die Hinweise zum Abschalten verweisen Firefox weiter auf media.peerconnection.enabled gleich false in about:config und Chrome auf die Erweiterung WebRTC Network Limiter. Diese Site hat diesen Test nicht ausgeführt und kennt den STUN-Host jener Seite weiter nicht. Der Absatz vom 21. Oktober oben bleibt stehen. Dieser Lauf hat keine Mikrofone oder Kameras aufgelistet und kein VPN benutzt.
Fragen
Kontaktiert die Seite sofort einen STUN-Server?
Erst nach dem Start. Dann kann der Browser stun:stun.cloudflare.com:3478 fragen.
Ist eine .local-Adresse meine öffentliche IP?
Nein. mDNS versteckt den Host hinter einem Namen. Eine reflexive Adresse ist die andere Zeile.
Ersetzt das ein VPN?
Nein. Der Test misst, er verschiebt keine Route.