DNS Leak Test: VPN, WebRTC & IPv6 richtig prüfen

Kurz erklärt: Ein DNS Leak Test ist nur dann wirklich hilfreich, wenn du zuerst weißt, was deine Verbindung ohne VPN zeigt. Notiere deshalb zunächst deine öffentliche IPv4-Adresse, eine eventuell vorhandene öffentliche IPv6-Adresse, die sichtbaren DNS-Resolver und die WebRTC-Anzeigen deines Browsers. Verbinde danach das VPN und wiederhole dieselben Prüfungen unter möglichst gleichen Bedingungen.

Wichtig: Ein unbekannter DNS-Server, eine private Adresse wie 192.168.x.x oder eine zufällige .local-Adresse ist nicht automatisch ein Leak. Kritisch wird es vor allem dann, wenn deine öffentliche Anschlussadresse oder der DNS-Pfad deines normalen Internetanbieters trotz aktivem Volltunnel-VPN reproduzierbar sichtbar bleibt, obwohl diese Verbindung durch den Tunnel laufen oder blockiert werden sollte.

Inhaltsverzeichnis

Dein VPN zeigt „verbunden“ – aber ist wirklich alles im Tunnel?

Die VPN-App meldet eine geschützte Verbindung. Die Webseite zeigt eine andere IP-Adresse. Trotzdem tauchen in einem Test mehrere DNS-Server, zusätzliche Adressen oder ein fremder Standort auf. Genau an dieser Stelle beginnt bei vielen die Unsicherheit: Ist das normal, ein Messfehler oder tatsächlich ein Leak?

Genau hier helfen die roten und grünen Ampeln vieler Testseiten nur begrenzt. Ein einzelner Lauf zeigt nur, was dieses Browserprofil in diesem Netzwerk und genau diesem Verbindungszustand preisgibt. Das kann ein wichtiger Hinweis sein – aber kein Beweis für vollständige Anonymität oder den Schutz jeder anderen App.

Deshalb gehst du Schritt für Schritt vor: zuerst die Baseline ohne VPN, danach dieselben vier Signale mit aktivem VPN. Zeigt sich eine Auffälligkeit, veränderst du genau eine mögliche Ursache und testest erneut. So erkennst du nicht nur, dass etwas anders aussieht, sondern welcher Datenpfad tatsächlich geprüft werden muss.

Was prüft ein DNS Leak Test – und was nicht?

Wenn du eine Webseite aufrufst, muss der Domainname zunächst in eine IP-Adresse aufgelöst werden. Diese Aufgabe übernimmt ein DNS-Resolver. Ein DNS Leak Test versucht zu erkennen, welche Resolver deine Testanfragen bearbeiten. Er prüft damit einen wichtigen Teil des Verbindungswegs, aber nicht automatisch die gesamte VPN-Verbindung.

Die öffentliche IP-Adresse ist ein anderes Signal. Sie zeigt, über welchen öffentlichen Anschluss oder Ausgang der Browser die Testseite erreicht. WebRTC wiederum kann im Browser zusätzliche ICE-Kandidaten anzeigen, die aus lokalen Interfaces, VPN-Verbindungen oder erreichbaren Netzwerkpfaden stammen. IPv6 muss ebenfalls getrennt betrachtet werden, weil ein Anschluss gleichzeitig IPv4 und IPv6 verwenden kann.

Ein sauberer DNS-Test bedeutet daher nicht automatisch:

dass deine öffentliche IP korrekt verborgen ist,
dass WebRTC keine zusätzliche öffentliche Adresse zeigt,
dass IPv6 durch den VPN-Tunnel läuft,
dass jede andere App denselben Netzwerkpfad verwendet,
oder dass du vollständig anonym bist.

Umgekehrt ist ein fremder Resolver nicht sofort ein Beweis für ein DNS-Leak. Dein Browser kann Secure DNS beziehungsweise DNS over HTTPS verwenden. Du kannst bewusst einen öffentlichen DNS-Dienst eingerichtet haben. Auch die VPN-App kann einen Resolver nutzen, dessen Betreibername nicht mit dem Markennamen des VPN-Anbieters übereinstimmt.

Vier Signale, die du getrennt prüfen solltest

Öffentliche IPv4-Adresse

Ohne VPN siehst du normalerweise die öffentliche IPv4-Adresse deines Internetanschlusses oder eines vorgeschalteten Netzes. Mit aktivem VPN sollte eine andere öffentliche Adresse erscheinen, die plausibel zum VPN-Ausgang oder zu einem bewusst verwendeten Relay- oder Proxy-Pfad passt.

Eine wechselnde VPN-Ausgangsadresse ist nicht automatisch verdächtig. Viele Dienste verteilen Verbindungen dynamisch auf unterschiedliche Server. Eine Gegenprobe ist aber sinnvoll, wenn der Betreiber oder Standort völlig unerwartet wirkt oder verschiedene Browser gleichzeitig unterschiedliche öffentliche Adressen zeigen.

DNS-Resolver

Der DNS-Test zeigt die Resolver, die seine speziell erzeugten Testnamen auflösen. Erwartbar ist ein Resolver, der zur dokumentierten VPN-Konfiguration, zu deiner bewusst gewählten System-DNS-Einstellung oder zur Secure-DNS-Konfiguration des Browsers passt.

Unklar wird es, wenn mehrere Betreiber gleichzeitig auftauchen, wenn sich Browser stark unterscheiden oder wenn ein Resolver sichtbar bleibt, der bereits in deiner Baseline eindeutig dem normalen Internetanbieter zugeordnet war. Erst nach dem Abgleich mit Browser, Betriebssystem, VPN-App und deinen eigenen DNS-Einstellungen darf daraus ein Leak-Hinweis werden.

WebRTC-/ICE-Signale

WebRTC benötigt für Sprach-, Video- und Echtzeitverbindungen verschiedene mögliche Netzwerkpfade. Der Browser sammelt dafür sogenannte ICE Candidates. Ein Test kann deshalb private, lokale, maskierte und öffentliche Adressen anzeigen.

Private IPv4-Adressen aus den Bereichen 10.x.x.x, 172.16.x.x bis 172.31.x.x und 192.168.x.x sind keine öffentlichen Anschlussadressen. Auch IPv6-Adressen aus lokalen Bereichen sowie zufällige .local- oder mDNS-Namen dürfen nicht vorschnell als öffentliche IP-Leaks bezeichnet werden.

Prüfbedarf besteht, wenn neben der VPN-Ausgangsadresse eine weitere öffentliche Adresse erscheint. Besonders relevant ist der Vergleich zur Baseline: Entspricht sie deiner normalen öffentlichen Anschlussadresse, muss geklärt werden, ob Split Tunneling, ein zweites Interface oder ein nicht erfasster Pfad aktiv ist.

Öffentliche IPv6-Adresse

IPv6 ist ein eigener Adress- und Verbindungsweg. Besitzt dein Anschluss ohne VPN keine öffentliche IPv6-Adresse, fehlt dir auch die Vergleichsbasis für einen klassischen IPv6-Leak-Test.

Manche VPN-Dienste stellen eine eigene IPv6-Verbindung bereit. Andere blockieren IPv6 während der VPN-Verbindung. Beides kann je nach dokumentiertem Funktionsumfang erwartbar sein. Ein starkes Bypass-Signal liegt dagegen vor, wenn dieselbe globale öffentliche IPv6-Adresse aus deiner Baseline mit aktivem VPN reproduzierbar sichtbar bleibt, obwohl der gewählte Tunnel diesen Pfad abdecken oder blockieren soll.

Die schnelle Ergebnismatrix

Erwartet oder erklärbar:

Mit VPN erscheint eine andere öffentliche IPv4-Adresse.
Ein DNS-Resolver passt zur VPN-App, zu Secure DNS oder zu deiner bewusst gewählten Systemkonfiguration.
WebRTC zeigt nur private, lokale oder .local-/mDNS-Werte sowie die VPN-Ausgangsadresse.
IPv6 fehlt, weil der VPN-Dienst es dokumentiert blockiert.
Der VPN-Dienst stellt eine eigene, andere globale IPv6-Adresse bereit.

Gegenprobe nötig:

Betreiber oder Standort einer öffentlichen IP wirken unerwartet.
Mehrere DNS-Betreiber erscheinen gleichzeitig.
Chrome, Edge, Firefox oder Safari liefern unterschiedliche Ergebnisse.
WebRTC zeigt eine zusätzliche öffentliche Adresse.
IPv6 erscheint nur nach einem Reconnect, nur in einem Browser oder nur in einem bestimmten Netzwerk.
Die Dokumentation des VPN-Anbieters lässt offen, wie DNS oder IPv6 behandelt werden.

Starker Leak- oder Bypass-Hinweis:

Deine öffentliche IPv4-Adresse aus der Baseline bleibt mit aktivem Volltunnel-VPN reproduzierbar sichtbar.
Der eindeutig zugeordnete Resolver deines normalen Internetanbieters bleibt trotz VPN reproduzierbar aktiv, obwohl keine bewusste Secure-DNS- oder System-DNS-Ausnahme besteht.
WebRTC zeigt zusätzlich die öffentliche Anschlussadresse aus der Baseline.
Dieselbe globale öffentliche IPv6-Adresse aus der Baseline bleibt mit aktivem VPN sichtbar, obwohl der Dienst diesen Pfad tunneln oder blockieren soll.

Ein starker Hinweis ist noch kein Grund, wahllos Einstellungen abzuschalten. Wiederhole den Test zuerst und prüfe den Befund mit einem zweiten Werkzeug.

So führst du den DNS Leak Test nachvollziehbar durch

Schritt 1: Testumgebung festhalten

Notiere Gerät, Betriebssystem, Browser, Netzwerk und den verwendeten VPN-Dienst. Prüfe außerdem, ob im Browser Secure DNS aktiviert ist und ob in der VPN-App Split Tunneling verwendet wird. Du musst diese Funktionen nicht sofort abschalten. Du solltest nur wissen, ob sie das Ergebnis beeinflussen können.

Verwende für die DNS-Prüfung einen Dienst, der seine Methodik erklärt. In der freigegebenen Testlogik dient dnscheck.tools als primärer Resolver-Test. BrowserLeaks eignet sich als unabhängige Gegenprobe für öffentliche IP, DNS und WebRTC. test-ipv6.com wird nur für die IPv6-Erreichbarkeit verwendet, nicht als vollständiges Sicherheitswerkzeug.

Veröffentliche oder teile keine Screenshots mit deinen echten IP-Adressen, Resolvern oder Standortdaten.

Schritt 2: Baseline ohne VPN aufnehmen

Trenne die VPN-Verbindung vollständig. Öffne den primären DNS-Test und notiere:

öffentliche IPv4-Adresse,
öffentliche IPv6-Adresse, falls vorhanden,
sichtbare DNS-Resolver und deren Betreiber,
WebRTC-/ICE-Anzeigen im verwendeten Browser.

Öffne anschließend die unabhängige Gegenprobe. Die Werte müssen nicht Wort für Wort identisch sein. Entscheidend ist, dass du erkennst, welche öffentlichen Adressen und Resolver zu deinem normalen Anschluss gehören.

Falls dein Browser Secure DNS verwendet, notiere auch den dort gewählten Modus oder Anbieter. Sonst kann später ein absichtlich verwendeter öffentlicher Resolver fälschlich wie ein VPN-Problem aussehen.

Fünfstufige Infografik für einen DNS Leak Test: Baseline ohne VPN notieren, VPN verbinden, vier Signale erneut prüfen, Ergebnis einordnen und nur eine Variable ändern. — Verwende dasselbe Gerät, denselben Browser und dasselbe Netzwerk und ändere bei einer Gegenprobe nur eine Variable.

Schritt 3: VPN verbinden und denselben Test wiederholen

Verbinde das VPN mit dem gewünschten Server. Verwende dasselbe Gerät, denselben Browser und dasselbe Netzwerk. Starte die Tests neu und notiere erneut IPv4, IPv6, DNS und WebRTC.

Führe mindestens eine Wiederholung durch. Bei einem auffälligen Ergebnis verwendest du zusätzlich die unabhängige Gegenprobe. DNS-Tests erzeugen häufig neue, zufällige Testnamen, damit alte Cache-Einträge das Ergebnis weniger verfälschen. Trotzdem solltest du einen Test neu starten, statt nur eine alte Ergebnisseite zu aktualisieren.

Bewerte nicht allein den angezeigten Ländernamen. Standorte und Betreiberzuordnungen können ungenau sein. Wichtiger ist, ob eine öffentliche Adresse oder ein Resolver aus deiner Baseline reproduzierbar wieder auftaucht.

Schritt 4: Ergebnis einer Kategorie zuordnen

Ordne jedes Signal einzeln ein:

erwartet oder erklärbar,
Gegenprobe nötig,
starker Leak- oder Bypass-Hinweis.

Mische die Ergebnisse nicht. Ein sauberer IPv4-Ausgang kann gleichzeitig mit einem unklaren DNS-Resolver auftreten. Ein fehlendes IPv6 kann erwartbar sein, während WebRTC eine zusätzliche öffentliche Adresse zeigt. Genau deshalb werden die vier Signale getrennt geprüft.

Ergebnismatrix zur Einordnung von IPv4-, DNS-, WebRTC- und IPv6-Ergebnissen in erklärbar, Gegenprobe nötig und starker Bypass-Hinweis. — Auffällige Ergebnisse werden zuerst mit der eigenen Baseline abgeglichen, wiederholt und mit einem zweiten Werkzeug gegengeprüft.

Schritt 5: Nur eine Ursache pro Gegenprobe verändern

Bei einem auffälligen Ergebnis beginnst du mit der risikoärmsten Prüfung:

VPN sauber trennen und neu verbinden.
In der offiziellen Hilfe deines Anbieters prüfen, wie DNS, IPv6, Kill Switch und Leak-Schutz behandelt werden.
Kontrollieren, ob der Browser oder die Test-App durch Split Tunneling vom VPN ausgeschlossen ist.
Secure-DNS-Einstellung des Browsers dokumentieren und nur für eine kontrollierte Gegenprobe ändern, wenn die Herstellerdokumentation dies erlaubt.
VPN-App, Browser und Betriebssystem über die offiziellen Wege aktualisieren.
In einem zweiten Browser oder einem anderen Netzwerk erneut testen.
Den VPN-Support mit deiner dokumentierten Baseline und dem reproduzierten Ergebnis kontaktieren.

Tiefgreifende Änderungen an Registry, Firewall, Treibern oder Routingtabellen gehören nicht in diese Diagnose. Auch experimentelle Browserflags und zufällige Erweiterungen sind kein sauberer erster Schritt.

Wenn nach einer Änderung mit VPN gar kein Internet mehr funktioniert, nutze den Ratgeber VPN verbunden, aber kein Internet unter Windows 11.

Warum Chrome, Edge, Firefox und Safari unterschiedlich reagieren können

Browser verwenden nicht zwangsläufig denselben DNS-Pfad. Chrome und Edge besitzen Secure-DNS-Modi, die je nach Konfiguration automatische oder fest vorgegebene Resolver nutzen und teilweise unterschiedlich mit einem Fehlschlag umgehen. Firefox kann DNS over HTTPS abhängig von seiner Schutzstufe, dem Netzwerk, Richtlinien oder einem erkannten VPN anders behandeln.

Auf Apple-Geräten kann zusätzlich iCloud Private Relay relevant sein. Dieser Dienst ist kein normaler Volltunnel-VPN und kann insbesondere Safari-IP- und DNS-Ergebnisse über einen eigenen Relay-Pfad verändern. Ein auffälliges Safari-Ergebnis muss deshalb nicht identisch mit dem Ergebnis einer anderen App sein.

Android unterstützt Always-on-VPN, das Blockieren von Verbindungen ohne VPN und je nach App Per-App-VPN beziehungsweise ausgeschlossene Anwendungen. Wird der Browser aus dem VPN-Pfad ausgenommen, kann sein Testergebnis korrekt den normalen Anschluss zeigen, obwohl andere Apps durch das VPN laufen.

Unterschiedliche Browserergebnisse sind daher zunächst ein Diagnosehinweis. Sie beweisen nicht automatisch, welcher Browser „richtig“ oder „falsch“ arbeitet.

DNS Leak richtig einordnen und gezielt beheben

Prüfe zuerst, ob der sichtbare Resolver beabsichtigt ist. Gehört er zu einem Secure-DNS-Anbieter, den du im Browser ausgewählt hast? Ist im Betriebssystem ein eigener DNS-Dienst eingetragen? Dokumentiert dein VPN-Anbieter einen extern betriebenen Resolver?

Bleibt dagegen der eindeutig zugeordnete Resolver deines normalen Internetanbieters trotz aktivem Volltunnel-VPN reproduzierbar sichtbar, obwohl keine bewusste Ausnahme besteht, liegt ein starker Prüfbedarf vor.

Die sinnvolle Reihenfolge lautet:

VPN neu verbinden,
Split Tunneling kontrollieren,
offizielle DNS- oder Leak-Schutz-Einstellungen der VPN-App prüfen,
Secure DNS des Browsers mit der Herstellerdokumentation abgleichen,
zweiten Browser und zweiten Testdienst verwenden,
Anbieter-Support kontaktieren.

Trage nicht einfach einen beliebigen öffentlichen DNS-Server ein. Damit veränderst du den sichtbaren Resolver, ohne zu beweisen, dass der ursprüngliche VPN-Pfad repariert wurde.

WebRTC Leak richtig einordnen

Eine private Adresse oder ein .local-Wert ist für sich genommen kein öffentlicher IP-Leak. Entscheidend ist, ob eine zusätzliche öffentliche Nicht-VPN-Adresse sichtbar wird.

Vergleiche diese Adresse mit deiner Baseline. Passt sie zur öffentlichen Anschlussadresse ohne VPN, wiederhole den Test nach einem sauberen Reconnect. Kontrolliere dann Split Tunneling und aktive Netzwerkinterfaces. Nutzt du Ethernet, WLAN, Mobilfunk-Hotspot oder virtuelle Adapter gleichzeitig, können mehrere Pfade sichtbar werden.

WebRTC komplett abzuschalten ist keine pauschale Standardlösung. Echtzeitkommunikation in Browsern kann dadurch beeinträchtigt werden. Erst muss feststehen, dass tatsächlich eine öffentliche Baseline-Adresse über WebRTC sichtbar bleibt und welche offiziell dokumentierte Einstellung dafür verantwortlich ist.

IPv6 Leak richtig einordnen

Prüfe zuerst, ob deine Baseline überhaupt eine globale öffentliche IPv6-Adresse besitzt. Fehlt sie bereits ohne VPN, kannst du aus einem fehlenden IPv6-Ergebnis mit VPN keinen Fehler ableiten.

Zeigt der VPN-Test eine andere globale IPv6-Adresse, kann der Dienst IPv6 tunneln. Zeigt er gar keine öffentliche IPv6-Adresse, kann der Dienst IPv6 bewusst blockieren. Beides muss mit der aktuellen Anbieterbeschreibung abgeglichen werden.

Bleibt hingegen dieselbe globale IPv6-Adresse aus der Baseline sichtbar, liegt ein starker Bypass-Hinweis vor. Wiederhole den Test, prüfe einen zweiten Dienst und dokumentiere Server, Netzwerk und Zeitpunkt.

IPv6 dauerhaft abzuschalten ist keine neutrale Reparatur. Betriebssysteme und Anwendungen können IPv6 voraussetzen oder bevorzugen. Eine zeitlich begrenzte Deaktivierung wäre höchstens eine klar begründete, reversible Diagnose- oder Übergangsmaßnahme nach offizieller Plattform- oder Anbieteranleitung – nicht der erste Tipp eines allgemeinen Ratgebers.

Typische Fehler bei VPN Leak Tests

Nur einen Testlauf verwenden

Ein einzelner Test kann durch einen Reconnect, einen Browserzustand oder einen temporären Resolver beeinflusst sein. Wiederhole auffällige Ergebnisse und nutze eine unabhängige Gegenprobe.

Jeden fremden Resolver als Leak bezeichnen

Browser-Secure-DNS, ein bewusst gewählter DNS-Dienst oder die Infrastruktur des VPN-Anbieters können einen fremden Namen erklären. Entscheidend sind Baseline und Konfiguration.

Private IP-Adressen mit der öffentlichen IP verwechseln

192.168.x.x, 10.x.x.x, 172.16.x.x bis 172.31.x.x und lokale IPv6-Bereiche sind nicht deine öffentliche Anschlussadresse.

Nur auf das Land achten

Geolokalisierung ist eine Zusatzinformation, kein alleiniger Beweis. Betreiber und tatsächliche Adresse sind wichtiger.

Mehrere Einstellungen gleichzeitig ändern

Wer gleichzeitig IPv6, WebRTC, Secure DNS, Firewall und Kill Switch verändert, kann die Ursache später nicht mehr nachvollziehen. Ändere eine Variable und teste erneut.

Einen Browser-Test auf alle Apps übertragen

Der Test beschreibt das Verhalten des verwendeten Browsers im aktuellen Zustand. Andere Apps können eigene DNS-Mechanismen nutzen oder durch Per-App-VPN und Split Tunneling anders geroutet werden.

Wann du den VPN-Support kontaktieren solltest

Ein Supportfall ist sinnvoll, wenn eine Auffälligkeit nach einem sauberen Reconnect und einer unabhängigen Gegenprobe reproduzierbar bleibt. Besonders hilfreich sind folgende Angaben:

Betriebssystem und Version,
VPN-App und Version,
gewählter Server und Protokollmodus,
Browser und Secure-DNS-Einstellung,
aktiviertes Split Tunneling oder Always-on-VPN,
Ergebnis ohne VPN und mit VPN,
Art des Signals: IPv4, DNS, WebRTC oder IPv6,
Zeitpunkt und verwendete Testdienste.

Teile keine vollständigen Screenshots öffentlich. Sende sensible Werte nur über den offiziellen Supportkanal und nur soweit sie für die Diagnose erforderlich sind.

Dexters klare Einordnung

Ein Leak-Test ist kein Zauberlicht, das deine Verbindung mit einem Klick für sicher oder unsicher erklärt. Der wichtigste Schritt ist nicht das Öffnen irgendeiner Testseite, sondern der Vergleich mit deiner eigenen Ausgangslage.

Wenn du IPv4, DNS, WebRTC und IPv6 getrennt betrachtest, lassen sich viele scheinbare Alarme schnell erklären. Ein fremder Resolver kann beabsichtigt sein. Eine .local-Adresse kann ein Schutzmechanismus statt eines Leaks sein. Fehlendes IPv6 kann zum vorgesehenen Funktionsumfang des VPN-Dienstes gehören.

Ernst wird es, wenn deine öffentliche Anschlussadresse oder ein eindeutig zugeordneter normaler DNS-Pfad trotz aktivem Volltunnel-VPN reproduzierbar sichtbar bleibt. Dann gilt: erneut prüfen, nur eine Ursache verändern und sauber dokumentieren. So kommst du schneller zu einer belastbaren Antwort als mit zehn hektischen Sicherheitstipps.

Weitere Anleitungen zu VPN-Verbindungen, Datenschutz und Fehlerdiagnose findest du bei den weiteren VPN-Ratgebern und Sicherheitsanleitungen.

Häufige Fragen

Ist ein unbekannter DNS-Server automatisch ein DNS-Leak?

Nein. Er kann durch Secure DNS im Browser, eine bewusste System-DNS-Einstellung oder die Infrastruktur des VPN-Anbieters erklärt werden. Prüfe Betreiber, Konfiguration und deine Baseline, bevor du ihn als Leak bewertest.

Ist eine 192.168.x.x- oder .local-Adresse im WebRTC-Test gefährlich?

Nicht automatisch. 192.168.x.x ist eine private Adresse. Zufällige .local-Werte können aus mDNS-basierter Maskierung stammen. Kritisch ist vor allem eine zusätzliche öffentliche Adresse, die deiner normalen Anschlussadresse entspricht.

Muss ich IPv6 deaktivieren?

Nicht pauschal. Fehlendes IPv6 kann bei einem VPN erwartbar sein, und eine dauerhafte Deaktivierung kann andere Funktionen beeinträchtigen. Prüfe zuerst, ob deine Baseline eine öffentliche IPv6 besitzt und wie dein VPN-Anbieter IPv6 behandelt.

Sollte ich WebRTC vollständig ausschalten?

Nicht als Standardlösung. WebRTC wird für Browsertelefonie, Videokonferenzen und andere Echtzeitfunktionen benötigt. Zuerst muss ein reproduzierbarer öffentlicher Nicht-VPN-Pfad bestätigt werden.

Beweist ein sauberer Test vollständige Anonymität?

Nein. Der Test prüft bestimmte Netzwerk- und DNS-Signale in einem Browser. Er deckt weder alle Apps noch Tracking, Cookies, Konten, Fingerprinting oder zukünftige Verbindungszustände vollständig ab.

Wann sollte ich erneut testen?

Nach Updates der VPN-App oder des Browsers, nach Änderungen an DNS oder Split Tunneling und wenn du zwischen WLAN, Mobilfunk oder anderen Netzwerken wechselst. Ein Retest ist außerdem sinnvoll, wenn ein Problem nur nach Standby, Reconnect oder einem Kill-Switch-Ereignis auftritt.

Quellen und technische Grundlage

Die technischen Aussagen dieses Ratgebers wurden am 4. August 2026 anhand der folgenden Standards, Herstellerdokumentationen und Testmethoden geprüft. Testdienste dienen als praktische Werkzeuge; ihre Ergebnisse werden immer mit der eigenen Baseline und einer Gegenprobe eingeordnet.

DNS Leak Test: So prüfst du VPN, WebRTC und IPv6 richtig