Erweiterter IP & DNS Leak Test: Netzwerksicherheit prüfen

Viele Nutzer glauben, mit dem Kauf eines "Residential-Proxys" vollständig als gewöhnlicher Heimnutzer getarnt zu sein. Moderne Risikobewertungssysteme stützen sich jedoch längst nicht mehr nur auf statische Kategorien in GeoIP-Datenbanken (wie IP2Location oder MaxMind). Auch wenn eine Exit-IP als ISP/Wohnsitz eingetragen ist, läuft das weiterleitende Proxy-Gateway fast immer auf einem Linux-Cloud-Server. Dies führt zu offensichtlichen schichtenübergreifenden Widersprüchen: Erstens die TCP-Protokoll-Signatur: Der Exit-Server sendet beim SYN-Handshake typische Linux-Optionsfolgen (MSS, SACK_PERM, TS, NOP, WS) anstelle von Windows- oder Apple-Reihenfolgen. Zweitens die Pfad-MTU: PPPoE-Heimanschlüsse nutzen typischerweise eine MTU von 1492 (Mobilfunk 1400–1430), während Rechenzentren standardmäßig auf 1500 (MSS=1460) laufen. Erkennt das Erkennungssystem eine Residential-IP in Kombination mit Rechenzentrums-MTU und Linux-Stack, wird die Verbindung als Proxy eingestuft.

💡 Prüfen Sie Ihre Verbindung mit dem Proxy-Anonymitätstest, um zu sehen, wo Ihr TCP-Handshake terminiert.

Eine IP-Adresse ist hardwareseitig an keinen festen geografischen Standort gebunden. Das angezeigte Ergebnis hängt maßgeblich von der verwendeten GeoIP-Datenbank und deren Aktualisierungszyklus ab: Erstens unterscheiden sich Datenquellen und Messmethoden — Anbieter wie MaxMind, IP2Location oder DB-IP gewichten BGP-Routing-Routen, Whois-Einträge und Netzwerklatenzmessungen unterschiedlich und aktualisieren in Abständen von Tagen bis Monaten. Zweitens Anycast-Routing und CDN-Netzwerke: Dienste wie Cloudflare nutzen dieselben IP-Blöcke weltweit in hunderten Rechenzentren, wobei Anfragen automatisch an den nächstgelegenen Standort geroutet werden. Drittens internationale IP-Umzüge: Weist ein Hoster IP-Blöcke einem Server in einem anderen Land zu, zeigen veraltete Datenbanken noch den alten Standort an. Unser Tool kombiniert Datenbankabgleiche mit physikalischen RTT-Laufzeitmessungen zur Validierung.

Ein IP-Fraud-Score (oder Risikoscore) ist ein numerischer Wert (meist von 0 bis 100), mit dem Sicherheitssysteme die Wahrscheinlichkeit böswilliger oder verschleierter Aktivitäten quantifizieren. Zu den Hauptfaktoren gehören: Erstens historische Reputations- und Sperrlisten (ob die IP kürzlich für Scraping, Credential Stuffing, Spam oder Angriffe genutzt wurde); zweitens Netzwerktyp und ASN (Rechenzentren und öffentliche Proxys/VPNs tragen ein deutlich höheres Grundrisiko als private Festnetz- oder Mobilfunkanschlüsse); drittens Protokoll- und Mehrpunkt-Konsistenz (ob innerhalb einer Sitzung IPv4- und IPv6-Exits voneinander abweichen, DNS-Server geografisch abdriften oder WebRTC lokale IP-Adressen leckt).

💡 Nutzen Sie den Split-Tunneling-Test, um Routing-Abweichungen aufzudecken.

Selbst bei aktivem VPN oder Proxy kann Ihre echte Identität über Nebenkanäle entweichen: Erstens DNS-Lecks: Wenn der Proxy-Client DNS-Anfragen des Betriebssystems nicht lückenlos abfängt, sendet der Browser unverschlüsselte DNS-Anfragen direkt an den lokalen DNS-Server Ihres Internetanbieters (ISP), wodurch dieser Ihre besuchten Webseiten und Ihren Standort erfährt. Zweitens WebRTC-Lecks: WebRTC ist eine Browsertechnologie für Echtzeit-Medienübertragung, die bei P2P-Verbindungen reguläre HTTP/SOCKS-Proxys umgeht und STUN-Pakete per UDP direkt versendet, was Ihre echte lokale und öffentliche IP offenlegen kann. Unsere Startseite testet Ihre DNS-Exits und den WebRTC-Status in Echtzeit.

💡 Zur Überprüfung von Hardware- und WebRTC-Merkmalen besuchen Sie die Browser-Fingerprint-Prüfung.

Das Netzwerkstapel-Panel der Startseite führt drei zugehörige Sonden parallel aus: Eine zielt auf eine Domain mit ausschließlich A-Records (iptestv4.myipdns.com), eine auf eine Domain mit ausschließlich AAAA-Records (iptestv6.myipdns.com) und die dritte auf eine Dual-Stack-Domain mit beiden Record-Familien. Die ersten beiden sind verbindlich – jeder Hostname löst nur in eine Adressfamilie auf, sodass Ihr System keine Wahl hat und Ihre tatsächlichen Exits für IPv4 und IPv6 separat erfasst werden. Die dritte Sonde erzwingt nichts, sondern beobachtet, welche Adressfamilie Ihr System von sich aus gewählt hat; dies zeigt die Spalte „Bevorzugtes Protokoll“: Das Ergebnis wird von der Adressauswahlstrategie von Betriebssystem und Browser bestimmt (Happy Eyeballs, RFC 8305: Bei Erreichbarkeit beider Stacks wird zuerst IPv6 versucht, IPv4 dient nur als Fallback) und nicht von uns vorgegeben. Alle drei nebeneinanderzustellen ist entscheidend, da viele Proxy- und VPN-Clients ausschließlich IPv4 tunneln: Wenn Ihr IPv4-Exit im ASN des Proxys liegt, Ihr IPv6-Exit jedoch weiterhin beim Breitbandanbieter verbleibt und das bevorzugte Protokoll IPv6 anzeigt, läuft beim Aufruf von Dual-Stack-Websites der Großteil Ihres Datenverkehrs überhaupt nicht durch den Tunnel – dies ist der häufigste Fall von „VPN aktiv, Identität dennoch exponiert“, und es wird keinerlei Fehler gemeldet.

⚠ Wir können Ihnen lediglich aufzeigen, ob Ihre Exits beider Familien in unterschiedlichen Netzwerken enden; wir können nicht beurteilen, wie Ihre Proxy-Software konfiguriert werden muss. Umgekehrt gilt dasselbe: Wird IPv6 als nicht verfügbar angezeigt, ist dies nicht gleichbedeutend mit Sicherheit; möglicherweise unterstützt Ihr Netzwerk schlicht kein IPv6 oder der Proxy hat IPv6 vollständig deaktiviert – Letzteres ist häufig das beabsichtigte Verhalten.

Wir lesen Ihre lokalen Systemeinstellungen nicht aus – Browser können diese technisch überhaupt nicht erfassen, und jede Webseite, die dies behauptet, rät lediglich. Das tatsächliche Verfahren besteht darin, den Test umzukehren: Unsere Website betreibt einen eigenen autoritativen DNS-Server und generiert bei jedem Test eine zufällige Subdomain (wie k3f9x2ab.leakv4.myipdns.com), die Ihr Browser auflösen soll. Dieser Name existiert weltweit nur ein einziges Mal und liegt in keinem Cache, sodass Ihre rekursive Auflösungskette zwingend bis zu unserem autoritativen Server zurückfragen muss; wir protokollieren, wer die Anfrage tatsächlich stellt, und übermitteln diese Adresse an die Seite. Die Spalte „DNS-Exit“ zeigt folglich die tatsächliche ausgehende Netzwerkadresse Ihres rekursiven Resolvers und nicht die in Ihren Systemeinstellungen eingetragene Adresse: Tragen Sie 8.8.8.8 ein, stammt die Anfrage an uns von einem konkreten Ausgangsserver dieses Clusters, der durchaus in einem anderen Land stehen kann; große öffentliche Resolver nutzen Anycast und Cluster-Strukturen, weshalb mehrere unterschiedliche Adressen innerhalb einer einzigen Messung völlig normal sind. Das echte Kriterium ist nicht die Übereinstimmung der Adresse, sondern: Liegt dieser Exit im Netz Ihres eigenen Breitbandanbieters, während Ihr IP-Exit über den Proxy läuft – dann folgt das DNS nicht dem Tunnel.

⚠ Dieses Verfahren erfasst ausschließlich, wer unseren eigenen autoritativen Server abgefragt hat; welche weiteren Domains Sie aufrufen, sehen wir nicht und können es technisch nicht sehen. Es besteht zudem eine bekannte Einschränkung: Führt Ihr Proxy auch das DNS über den Tunnel, sehen wir den Resolver des Proxy-Anbieters – dies belegt das Ausbleiben eines Lecks zum Provider, Ihre DNS-Anfragen bleiben für den Proxy-Anbieter jedoch sichtbar; dies ist eine separate Fragestellung, die unsere Seite nicht messen kann.

Über WebRTC werden einzelne Sonden an mehrere STUN-Server gesendet, um die zurückgemeldeten srflx-Kandidaten zu erfassen – also die öffentliche IP und den Port, wie sie die Gegenseite nach der NAT-Umsetzung tatsächlich sieht. Es gibt nur ein entscheidendes Kriterium: Die Kandidaten werden nach der zugeordneten öffentlichen IP gruppiert; treten unter derselben IP zwei oder mehr unterschiedliche Ports auf, wird auf symmetrisches NAT entschieden (für jedes neue Ziel wird ein neuer externer Port zugewiesen); andernfalls auf Cone-NAT (derselbe interne Port wird nach außen stets auf denselben öffentlichen Port abgebildet). Die vorherige Gruppierung vor dem Portvergleich ist eine bewusste Maßnahme: In Split-Tunnel-Proxy-Umgebungen nutzen verschiedene STUN-Server eventuell unterschiedliche Exits, wodurch Ports naturgemäß abweichen; dies resultiert jedoch aus unterschiedlichen Pfaden und nicht aus dem NAT-Verhalten – ohne Gruppierung würde ein solches Szenario fälschlicherweise stets als symmetrisch eingestuft. Die Anzeige „Unbekannt“ hat zwei Ursachen: Erstens ging innerhalb des 4-Sekunden-Timeouts kein einziger srflx-Kandidat ein (WebRTC im Browser deaktiviert, durch Erweiterungen blockiert oder UDP ausgehend gefiltert); zweitens wurde nur ein einzelner Kandidat empfangen, dessen öffentliche IP nicht mit der Zugangs-IP zu dieser Website übereinstimmt – da sich hier Browser-Deduplizierung nicht von Split-Routing unterscheiden lässt, zeigen wir bewusst unbekannt an.

⚠ Ehrliche Klarstellung: Wir unterscheiden ausschließlich zwischen Cone- und symmetrischem NAT und verzichten auf eine Unterteilung in Full Cone, Restricted Cone oder Port-Restricted Cone. Die Vierer-Klassifizierung nach RFC 3489 erfordert die gezielte Kontrolle von Quellport- und Zielkombinationen über wiederholte Sonden; WebRTC im Browser bietet diese Kontrollmöglichkeiten nicht. Web-Tools, die eine dieser vier Kategorien ausweisen, versehen diese beiden Ergebnisse meist nur mit einer alternativen Bezeichnung.

Eine Messung auf der Startseite sendet parallel sechs Sonden an jeweils unterschiedliche Domains: Eine reine IPv4-Sonde, eine reine IPv6-Sonde, zwei Sonden zur Erfassung der Protokollstapel-Fingerabdrücke über IPv4 bzw. IPv6, eine Sonde zu einer Dual-Stack-Domain zur Ermittlung der bevorzugten Adressfamilie sowie eine dezidiert auf HTTP/1.1 festgelegte Sonde. Es handelt sich nicht um redundante Anfragen; jede Sonde erfasst grundlegend andere Messwerte. Die Trennung ist zwingend erforderlich, da unsere Diagnostik auf einem schichtenübergreifenden Abgleich basiert: Dasselbe Endgerät weist über IPv4 versus IPv6 sowie über HTTP/1.1 versus HTTP/2 (und HTTP/3, sofern verfügbar) unterschiedliche Protokollmerkmale auf, die erst durch getrennte Erfassung vergleichbar werden. Zudem dient die Parallelität nicht primär der Geschwindigkeit: Würden die Sonden sequenziell gesendet, könnte ein zwischenzeitlicher Netzwechsel, Proxy-Umschaltung oder Tunnel-Neuaufbau die Messwerte zu einem real nicht existierenden Hybridsystem kombinieren; die parallele Ausführung stellt sicher, dass alle sechs Sonden denselben Netzwerkpfad zum exakt selben Zeitpunkt beobachten. Die HTTP/1.1-Sonde sendet dabei bewusst nur eine einzige Anfrage – HTTP/1.1 besitzt keine dynamische HPACK-Tabelle, sodass zusätzliche Anfragen keinen Informationsgewinn bringen, während ein Einzelaufruf garantiert, dass die erfassten Header exakt demselben Messdatensatz zugeordnet bleiben.

⚠ Dies führt dazu, dass beim ersten Laden Verbindungen zu mehreren Subdomains aufgebaut werden, was Werbeblocker oder strenge Datenschutz-Erweiterungen gelegentlich unterbinden. In diesem Fall verbleibt das betreffende Feld mit einem grauen Punkt im Zustand „Unbekannt“; wir ergänzen keinesfalls Werte anderer Sonden, um ein scheinbar vollständiges Ergebnis vorzutäuschen.