Wie WebRTC deine Adresse am VPN vorbei verraten kann

Kurz gesagt

Warum dein Browser Adressen sammelt

Für einen Videoanruf von Gerät zu Gerät muss dein Browser wissen, unter welchen Adressen er erreichbar ist; die Grundlagen stehen bei WebRTC. Das Verfahren dafür heißt ICE: Es sammelt Kandidaten — mögliche Adressen samt Port — und probiert sie mit der Gegenseite durch. Beim Sammeln entstehen drei Arten; eine vierte ergibt sich erst bei dieser Probe:

• Adressen auf dem Gerät selbst. Dazu zählt die ICE-Spezifikation ausdrücklich auch die Adresse eines VPN-Adapters. Hinter einem Router ist es meist eine Adresse aus deinem eigenen Netz wie 192.168.178.23.
• Die Adresse, unter der dich ein Hilfsserver von außen sieht. Dein Browser schickt dafür ein kleines UDP-Paket an einen STUN-Server, und der antwortet mit Adresse und Port, von denen das Paket bei ihm ankam.
• Die Adresse eines Weiterleitungsservers (TURN), über den das Gespräch notfalls läuft. Sie gehört dem Server, nicht dir.

Die Liste bekommt die Website, damit sie sie an die Gegenseite weiterreicht. Das W3C, das die Browserschnittstelle von WebRTC festlegt, warnt selbst: Preisgegebene Adressen können Ort und Art der Verbindung verraten.

Wo eine zusätzliche Adresse herauskommt

RFC 8828, die Regel der IETF für Adressen in WebRTC, nennt drei Fälle, in denen eine Website darüber mehr erfährt als über den gewöhnlichen Seitenabruf:

• Dein Gerät hat mehr als einen Weg ins Netz. Leitet ein VPN nur einen Teil des Verkehrs durch den Tunnel, kann WebRTC neben der Adresse des VPN auch die deines Anschlusses ermitteln. Das RFC hält diesen Fall für den wichtigsten, weil manche Menschen ein VPN gerade nutzen, um unerkannt zu bleiben.
• Dein Gerät steht hinter einem Router. Dann kann die Adresse aus deinem eigenen Netz herauskommen. Sie zeigt nicht nach außen, taugt laut RFC aber zur Wiedererkennung — dafür gibt es den Zufallsnamen.
• Dein Browser schickt seine Seitenabrufe über einen Proxy, darf aber auch direkt ins Netz. Dann gehen die STUN-Anfragen am Proxy vorbei und verraten deine öffentliche Adresse.

Das Risiko liegt also nicht in WebRTC selbst, sondern im Unterschied zwischen zwei Wegen: dem des Seitenabrufs und dem der UDP-Pakete, mit denen WebRTC den Hilfsserver fragt. Führen beide durch denselben Schutz, gibt es kein WebRTC-Leck.

Was die Browser heute tun

RFC 8828 legt vier Betriebsarten fest, von „alle Netzwege benutzen“ bis „alles über den Proxy“. Alle Netzwege darf ein Browser nur mit deiner Zustimmung benutzen; ohne sie soll er der Routingtabelle folgen, also dem Standardweg, den in aller Regel auch der Seitenabruf nimmt. Als Zustimmung werten die großen Browser die Freigabe von Kamera oder Mikrofon für eine Seite.

Weil der Standardweg schon ab Werk gilt, wirken strengere Stufen vor allem in zwei Fällen: auf Seiten mit Kamera- oder Mikrofonfreigabe — dort benutzen Chrome und Firefox alle Netzwege und nennen die echten Adressen im eigenen Netz — und wenn nur dein Browser über einen Proxy läuft. Dann zwingen die Chromium-Stufe „Disable non-proxied UDP“ oder der genannte Firefox-Schalter, der ab Werk aus ist, WebRTC ebenfalls durch den Proxy.

Ein gewöhnlicher Browser, den du über Tor schickst, ist so ein Proxy-Fall: Ab Werk gehen seine WebRTC-Pakete am Tor-Netz vorbei. Durch Tor selbst kämen sie auch nicht, denn Tor trägt bislang keine UDP-Pakete; Vorschläge dafür gibt es seit 2020. Der Tor Browser schaltet WebRTC deshalb ab und setzt zusätzlich die strengsten Schalter, falls es jemand wieder einschaltet.

Was das VPN-Programm entscheidet

Gegen einen Weg, der schon am Tunnel vorbeiführt, hilft keine Browserstufe, die beim Standardweg bleibt — sie folgt ihm ja. Ob wirklich alles durch den Tunnel geht, entscheiden dein VPN-Programm und dein Betriebssystem. Für WebRTC zählen vor allem zwei Stellen:

• IPv6. Das Betriebssystem leitet IPv4 und IPv6 getrennt. Richtet ein VPN nur IPv4 ein, kann IPv6 daneben direkt ins Netz gehen — beim Seitenabruf wie bei WebRTC; die IETF hat dieses Leck 2014 beschrieben. Android sperrt eine Adressfamilie, die das VPN-Programm nicht einrichtet, ab Werk, solange das Programm sie nicht ausdrücklich freigibt.
• Geteilter Tunnel. VPN-Programme können einzelne Apps oder Ziele am Tunnel vorbeileiten; eine ausgenommene App benutzt auf Android das Netz, „als liefe kein VPN“. Für WebRTC zählt, dass dein Browser im Tunnel bleibt; mit Kamerafreigabe auch, dass kein zweiter Weg offensteht.

Was beim Abbruch des Tunnels geschieht und wie du alles nachprüfst, steht in der Anleitung zum dichten VPN. Dass auch das Nachschlagen von Namen am Tunnel vorbeigehen kann, erklärt Was das Nachschlagen von Namen verrät.

Ein Beispiel: Paula, ein Proxy und die Netzmessung

Die Netzmessung von HexWarte fragt nur den eigenen Messpunkt und vergleicht die Antwort im Tab mit Kammer 1, getrennt nach IPv4 und IPv6.

Paula schickt Firefox über eine Proxy-Erweiterung, die WebRTC nicht mitregelt. Ihr Anschluss zu Hause hat nur IPv4.

• Kammer 1 zeigt unter „Deine IP-Adresse“ die Adresse des Proxys und als Netzbetreiber dessen Netz.
• Die Karte „Öffentliche IPv4-Adresse über WebRTC“ nennt dagegen Paulas Adresse zu Hause und steht auf „Erkennbar“. Firefox hat die Frage an den Messpunkt direkt geschickt, am Proxy vorbei — der dritte Fall aus RFC 8828.
• Den Weg schließt erst der Firefox-Schalter für den Proxy-Zwang oder ein VPN-Programm, das das ganze Gerät umleitet. Ob es gewirkt hat, zeigt eine neue Messung.

Anders sieht es bei einem VPN aus, das nur IPv4 umleitet: Dort nennt WebRTC über IPv6 dasselbe Netz wie Kammer 1, und die Karte bleibt „Unauffällig“, weil WebRTC nichts Zusätzliches verrät. Das Leck steckt dann schon im Seitenabruf, und der Hinweis an der Karte sagt das. Schritt für Schritt zeigt das die Anleitung zum dichten VPN.

Wann aus einer Adresse ein Leck wird

Ein Leck setzt zweierlei voraus: dass du deine Adresse verbergen willst, und dass ein Weg nach draußen nicht durch deinen Schutz führt. Auslösen kann es dann jede Website, ohne deinen Klick.

Was die Adresse deines Anschlusses selbst verrät, steht in Was deine IP-Adresse verrät — und wie genau der Ort ist.

Was dieser Artikel nicht sagt

• Dieser Artikel nennt und vergleicht keine VPN-Anbieter; was ein VPN leistet, steht in Wie anonym bin ich wirklich?.
• Das Verhalten der Browser beruht auf Quelltext, Versionshinweisen und Herstellerangaben, Stand Oktober 2026; ausgelieferte Fassungen können einige Wochen zurückliegen. Für Safari stammt der Standardweg allein aus dem WebKit-Quelltext, für Edge ist er nicht eigens belegt.
• Den Standardweg wählt das Betriebssystem nach seinen Routen. Dass er dem Weg des Seitenabrufs entspricht, ist der Regelfall, keine Zusage: Leitet ein VPN nur bestimmte Ziele um, können beide auseinanderfallen.
• Die Netzmessung von HexWarte fragt nie nach Kamera oder Mikrofon. Sie prüft deshalb nur den Zustand ohne Freigabe, nur diesen Browser und nur diesen Moment — eine installierte Konferenz-App prüft sie gar nicht.

Quellen

Geprüft am 3. Oktober 2026. Die Einordnung ist eine fachliche Bewertung, keine Rechtsberatung. Einen Fehler gefunden? Die Kontaktdaten stehen im Impressum.