WebRTC in Firefox deaktivieren: die Anleitung und die sanfteren Einstellungen, die oft genügen

Um WebRTC in Firefox zu deaktivieren, öffnen Sie about:config, suchen nach media.peerconnection.enabled und stellen den Wert auf false. Das dauert keine Minute. Wichtiger ist die Frage, ob Sie den Hauptschalter überhaupt brauchen: Firefox kennt drei feinere Einstellungen, die genau die problematischen Adressen entfernen und Videoanrufe trotzdem möglich lassen. Dieser Leitfaden zeigt beide Wege und wie Sie anschließend prüfen, was Ihr Browser tatsächlich preisgibt.

WebRTC in Firefox deaktivieren, Schritt für Schritt

Die Schritte folgen Mozillas Hilfeartikel zum Konfigurationseditor. Die Bezeichnungen in Klammern stammen aus der englischen Fassung, Ihr Firefox zeigt sie in seiner Sprache an.

1. Geben Sie about:config in die Adressleiste ein und drücken Sie die Eingabetaste.
2. Es kann eine Warnseite erscheinen. Klicken Sie auf die Schaltfläche, mit der Sie das Risiko akzeptieren und fortfahren (Accept the Risk and Continue).
3. Tippen Sie in das Suchfeld für Einstellungsnamen media.peerconnection.enabled.
4. Klicken Sie doppelt auf die Zeile oder auf ihre Umschalt-Schaltfläche (Toggle). Der Wert wechselt von true auf false, die Zeile wird fett.

Gespeichert werden muss nichts, und Mozillas Artikel nennt keinen Neustart als Voraussetzung. Laden Sie bereits geöffnete Tabs neu, damit deren Skripte mit der neuen Einstellung starten.

Zum Rückgängigmachen gehen Sie auf dieselbe Zeile und klicken auf Zurücksetzen (Reset). Mozilla weist darauf hin, dass nur geänderte, also fett dargestellte Einstellungen zurückgesetzt werden können.

Was dieser Schalter tatsächlich bewirkt

Mozillas Seite zum Datenschutz bei WebRTC beschreibt media.peerconnection.enabled in einer Zeile: Die Einstellung erlaubt oder unterbindet das Erzeugen von RTCPeerConnection-Objekten. Der Standardwert ist true, sowohl auf dieser Seite als auch im Firefox-Quellcode, Stand 7. Oktober 2026.

RTCPeerConnection ist das Objekt, mit dem eine Webseite eine direkte Verbindung zwischen zwei Browsern aufbaut. Vor dem Verbindungsaufbau sammelt es eine Liste von Netzwerkadressen, die ICE-Kandidaten, und das JavaScript der Seite kann diese Liste lesen. Daher kommt der Begriff „WebRTC-Leak“. RFC 8828, der IETF-Standard zum Umgang von WebRTC mit IP-Adressen, benennt den Fall, der VPN-Nutzer am meisten betrifft: Erlauben VPN und Betriebssystem das Routing über mehrere Schnittstellen, kann WebRTC nicht nur die öffentliche Adresse des VPN ermitteln, sondern auch die öffentliche Adresse des Internetanbieters, über die das VPN läuft.

Steht die Einstellung auf false, ist die Vergleichstabelle auf Mozillas Seite eindeutig: keine lokalen Kandidaten, keine externen Kandidaten, keine Relay-Kandidaten. Es wird nichts gesammelt, weil das Objekt gar nicht erst erzeugt werden kann.

Der Preis ist ebenso eindeutig. Jede Website, die auf eine Peer-Verbindung angewiesen ist, funktioniert in diesem Firefox-Profil nicht mehr: Anrufe im Tab, die Bildschirmfreigabe in diesen Anrufen und Web-Apps, die Dateien oder Spieldaten direkt von Browser zu Browser schicken. Gewöhnliche Seiten, Videostreaming und Downloads hängen nicht davon ab.

Die sanfteren Einstellungen: Anrufe behalten, Adressen entfernen

Wenn Sie in Firefox weiterhin telefonieren, führt dieselbe Mozilla-Seite Einstellungen auf, die festlegen, welche Kandidaten gesammelt werden, statt alle zu verbieten. Sie liegen alle in about:config und werden genauso geändert wie der Hauptschalter.

Drei Details dieser Seite sollten Sie vor der Entscheidung kennen.

default_address_only ist die Einstellung für VPN-Konfigurationen. Mozilla schreibt, dass die gesammelte externe Adresse die der Standardschnittstelle ist, und ergänzt in Klammern, dass dies bei einem VPN der Ausgangspunkt des VPN ist. Führt also der Tunnel die Standardroute, wird die dahinterliegende Adresse nicht mehr angeboten. Der genannte Nachteil: Unterstützt Ihr Router kein „Hairpinning“, läuft ein Anruf zwischen zwei Geräten im selben Heimnetz über einen externen TURN-Server.

no_host kümmert sich um die lokale Adresse. Die Einstellung entfernt Adressen wie 192.168.x.x aus der Liste, das zweite Anliegen von RFC 8828, das sie als Angriffsfläche für Fingerprinting einstuft. default_address_only und no_host zusammen auf true kommen dem nahe, was der RFC „Mode 3“ nennt, also nur die Standardroute.

relay_only ist die strenge Variante, die Anrufe erhält. Jeder Anruf läuft dann über einen Relay-Server. Mozillas Hinweis nennt die Grenze offen: Vor dem TURN-Server selbst bleibt Ihre externe Adresse nicht verborgen, und stellt die Website keinen TURN-Server bereit, entsteht kein Kandidat und der Anruf scheitert.

Eine weitere Zeile im Firefox-Quellcode ist wissenswert: media.peerconnection.ice.obfuscate_host_addresses steht in der allgemeinen Einstellungsdatei (all.js) standardmäßig auf true. Dieser Mechanismus sorgt dafür, dass eine lokale Adresse als zufälliger Name mit der Endung .local erscheint statt als Zahl.

Welche Einstellung zu welcher Situation passt

• Sie telefonieren nie in Firefox. Nehmen Sie den Hauptschalter. Er ist die einzige Einstellung mit garantiert leerem Ergebnis, und Sie verlieren nichts, was Sie nutzen.
• Sie nutzen ein VPN und telefonieren gelegentlich im Browser. Stellen Sie default_address_only und no_host auf true. Kandidaten werden weiterhin gesammelt, Anrufe können also weiter funktionieren, und sie folgen der Route, die Ihr Datenverkehr ohnehin nimmt.
• Sie brauchen Anrufe, und die Gegenseite darf keine Ihrer Adressen erfahren. relay_only ist die dokumentierte Option, mit den genannten Einschränkungen.
• Sie nutzen Firefox unter Android. Die Einstellungen heißen gleich. Entscheidend ist, ob Ihre Version about:config öffnet: Geben Sie es in die Adressleiste ein. Öffnet sich die Seite nicht, steht dieser Weg in dieser Version nicht zur Verfügung.

So prüfen Sie das Ergebnis

Eine geänderte Einstellung beweist für sich genommen nichts. Sehen Sie nach, was der Browser vorher und nachher herausgibt.

1. Verbinden Sie Ihr VPN wie gewohnt.
2. Öffnen Sie den WebRTC-Leak-Test dieser Website und starten Sie ihn. Er läuft im Browser: Er baut eine Peer-Verbindung zu einem öffentlichen STUN-Server auf und listet jede Adresse aus den Kandidaten auf, eingeordnet als lokal, öffentlich oder hinter einem .local-Namen verborgen.
3. Notieren Sie, was erscheint. Eine öffentliche Adresse, die nicht die Ihres VPN ist, ist das Leck, das es zu beheben gilt.
4. Ändern Sie die Einstellung, laden Sie die Seite neu und starten Sie den Test erneut.

Mit media.peerconnection.enabled auf false kann der Test die Verbindung nicht mehr erzeugen, es kann also keine Adresse aufgelistet werden. Mit den sanfteren Einstellungen ist die öffentliche Adresse des VPN zu erwarten und keine lokale Adresse in Zahlenform.

Was das Deaktivieren von WebRTC nicht behebt

WebRTC abzuschalten schließt einen Kanal, und nur diesen.

Es verbirgt Ihre Adresse nicht vor den besuchten Websites. Jede Seite sieht weiterhin, woher Ihre HTTP-Anfrage kommt: vom VPN-Server, wenn der Tunnel steht, von der Adresse Ihres Anbieters, wenn nicht.

Es betrifft das DNS nicht. Ein Browser kann WebRTC deaktiviert haben und seine Namensauflösungen trotzdem an den Resolver Ihres Anbieters schicken. Das ist ein anderer Test und eine andere Lösung, beschrieben im Leitfaden zum DNS-Leak-Test.

Es regelt IPv6 nicht. Tunnelt Ihr VPN nur IPv4, kann IPv6-Verkehr unabhängig von den Browsereinstellungen am Tunnel vorbeilaufen. Siehe den Leitfaden zum Schutz vor IPv6-Lecks.

Außerdem gilt die Einstellung pro Profil. Ein zweites Firefox-Profil, ein anderer Browser oder eine Desktop-App mit eigenem WebRTC-Stack behalten ihr Verhalten. Für die vollständige Liste der Kanäle in einem Durchgang folgen Sie dem vollständigen VPN-Leak-Test.

Kurz gesagt

media.peerconnection.enabled auf false in about:config deaktiviert WebRTC in Firefox vollständig, das Zurücksetzen stellt es wieder her. Brauchen Sie weiterhin Anrufe im Browser, entfernen media.peerconnection.ice.default_address_only und media.peerconnection.ice.no_host die entscheidenden Adressen und lassen WebRTC aktiv. In beiden Fällen gilt: WebRTC-Test vorher und nachher ausführen, denn die Einstellung ist nur so viel wert, wie der Test zeigt.