Inhalt des Artikels

Einleitung: Warum dein Proxy perfekt sein kann und man dich trotzdem sieht

Stell dir folgende Situation vor. Du hast einen hochwertigen mobilen Proxy gekauft, einen Antidetect-Browser eingerichtet und deine IP bei drei verschiedenen Diensten geprüft – überall die Adresse eines Mobilfunkanbieters in der gewünschten Region. Du startest dein Werbekonto, wärmst Accounts auf, betreibst Scraping. Und ein paar Tage später bekommst du eine Sperrung mit dem Hinweis auf verdächtige Aktivität. Kommt dir bekannt vor? Eine der am meisten unterschätzten Ursachen für solche Geschichten ist ein dns leak, also ein Leck von DNS-Anfragen am Proxy vorbei.

Das Paradoxe daran: Die IP-Adresse ist tatsächlich ausgetauscht. Die Website sieht Traffic von einem Mobilfunkanbieter. Aber vor jeder Verbindung fragt dein Computer still seinen Provider: „Wo ist denn der Server soundso?“ Und diese Frage geht direkt raus, ohne den Proxy. Für die beobachtende Seite entstehen dadurch zwei Bilder, die nicht zusammenpassen: Die Verbindung kommt aus dem Mobilfunknetz einer Region, doch die Namen werden über den Resolver des Heim-Internetproviders in einer ganz anderen Stadt aufgelöst. Für Antifraud-Systeme im Jahr 2026 ist diese Diskrepanz keine Kleinigkeit, sondern eines der zuverlässigsten Signale.

Nach unseren Beobachtungen in Support-Anfragen entpuppt sich ein erheblicher Teil der Beschwerden wie „Proxy funktioniert nicht, Geo wird falsch erkannt, Accounts fliegen ohne Grund“ bei genauerer Analyse gar nicht als Proxy-Problem. Es ist ein Problem der DNS-Ebene auf Client-Seite. Und Menschen, die vor Arbeitsbeginn gezielt DNS prüfen, sind nach wie vor in der Minderheit – die meisten beschränken sich auf die IP-Prüfung.

In diesem Leitfaden behandeln wir das Thema vollständig. Du erfährst, wie Namensauflösung funktioniert und an welchem Punkt sie am Proxy vorbeiläuft. Du verstehst, worin sich HTTP- und SOCKS-Proxys in Bezug auf DNS unterscheiden, warum ein einziger Buchstabe in der Verbindungszeichenfolge alles entscheidet und wie Browser mit aktiviertem verschlüsselten DNS eine neue Kategorie von Leaks schaffen. Wir geben dir vier praktische Methoden – Diagnose, Konfiguration von Client-Software, Browser und Antidetects, Systemebene – jede mit Schritt-für-Schritt-Anleitungen und Checklisten. Wir besprechen typische Fehler, Fälle mit Zahlen und beantworten schwierige Fragen.

Eine wichtige Grenze: Dieser Artikel behandelt die DNS-Ebene. Leaks über WebRTC, Browser-Fingerprints, Timings und andere De-Anonymisierungs-Kanäle sind separate Themen, die in anderen Blogbeiträgen behandelt werden. Hier konzentrieren wir uns auf einen, aber fundamentalen Kanal, denn ohne dessen Verständnis steht jede andere Konfiguration auf Sand.

Grundlagen: Wie DNS funktioniert und was ein dns leak ist

Das Telefonbuch des Internets

Jedes Mal, wenn ein Browser oder Skript sich mit einer Website verbinden will, braucht es keine Domain, sondern eine IP-Adresse. Die Domain ist ein für Menschen verständlicher Name. Die Adresse sind für das Netz verständliche Koordinaten. Der Dienst, der das eine in das andere übersetzt, heißt DNS (Domain Name System). Die einfachste Analogie ist ein Telefonbuch: Du kennst den Namen, das Buch liefert die Nummer. Nur ist dieses Buch über Tausende Server verteilt und arbeitet in Millisekunden.

So sieht die Namensauflösung in der Praxis aus:

  1. Die Anwendung ruft eine Systemfunktion auf (in der Unix-Welt meist getaddrinfo) und übergibt ihr den Domainnamen.
  2. Das Betriebssystem prüft den lokalen Cache und die Datei hosts.
  3. Wenn keine Antwort vorliegt, schickt der Stub-Resolver des OS eine Anfrage an die DNS-Server-Adresse, die in den Netzwerkeinstellungen hinterlegt ist. Meist ist das der Provider-Server, der per DHCP zugewiesen wurde, oder ein öffentlicher Resolver, den du manuell eingestellt hast.
  4. Der rekursive Resolver des Providers geht die Kette der Root-Server, Zonen-Server und autoritativen Server der Domain durch, findet die Antwort und gibt sie dir zurück.
  5. Die Anwendung erhält die IP und baut erst jetzt die Verbindung auf.

Achte auf die Reihenfolge. Erst DNS, dann Verbindung. Der Proxy ist ein Werkzeug, das in die Verbindung eingreift. Ob er aber in DNS eingreift, hängt vom Proxy-Typ, vom Protokoll und davon ab, wie genau die Anwendung ihn nutzt.

Was genau man als Leck bezeichnet

Ein DNS leak ist die Situation, in der der Traffic einer Anwendung über den Proxy läuft, die Anfragen zur Namensauflösung aber nicht. Sie gehen direkt über dein reales Netzwerk-Interface an den im System konfigurierten Resolver. Das Ergebnis: Die Website, mit der du dich verbindest, sieht die Proxy-IP, aber dein Provider und der Besitzer des Resolvers sehen die Liste aller Domains, die du aufgerufen hast. Und der Zielservice kann unter bestimmten Umständen zuordnen, woher die Verbindung kam und woher die DNS-Anfrage kam.

Warum ist das gerade für Nutzer mobiler Proxys wichtig? Weil der ganze Wert einer mobilen IP in ihrer Glaubwürdigkeit liegt. Die Adresse gehört einem Mobilfunkanbieter, hinter ihr stehen Tausende echte Teilnehmer, sie ändert sich, sie hat einen guten Ruf. Aber ein echter Mobilfunk-Teilnehmer löst Namen über die DNS-Server desselben Anbieters auf. Wenn dein Traffic aus dem Mobilfunknetz kommt, die Namen aber über den Kabel-Provider in einer anderen Region aufgelöst werden, bist du keinem echten Teilnehmer mehr ähnlich. Du wirst jemandem ähnlich, der einen Proxy benutzt. Genau das ist auch der Fall – und du hast es selbst erzählt.

Drei Rollen, die dein Leck sehen

  • Dein Internetprovider. Er sieht die Anfragen an seinen Resolver und weiß, welche Domains du besuchst, selbst wenn der Inhalt selbst über den Proxy lief.
  • Der Besitzer des Resolvers. Wenn du einen öffentlichen DNS eingestellt hast, sieht dessen Betreiber die vollständige Liste deiner Domains und deine reale IP.
  • Die Zielwebsite und ihre Antifraud. Direkt bekommt sie die DNS-Anfrage nicht, aber sie hat indirekte Kanäle: die Geografie der autoritativen Server, den Mechanismus EDNS Client Subnet, CDN-Routing und spezielle Testdomains, die für eine konkrete Session generiert werden. Dazu ausführlich im nächsten Abschnitt.

Tiefenanalyse: Anatomie eines DNS-Leaks bei der Arbeit über einen Proxy

HTTP-Proxy: warum es meist nicht leckt, aber Ausnahmen existieren

Bei der Arbeit über einen HTTP-Proxy schickt der Browser ihm eine Anfrage, in der die Domain als Text steht. Für unverschlüsseltes HTTP ist das die vollständige URL in der ersten Zeile der Anfrage. Für HTTPS sendet der Browser den Befehl CONNECT mit Hostname und Port, und der Proxy löst den Namen selbst auf und baut den Tunnel auf. In beiden Fällen muss der Client die IP des Zielservers nicht kennen. Die Auflösung macht der Proxy, auf seiner Seite, mit seinen Resolvern. Im Fall eines mobilen Proxys – auf Seite des Modems oder Telefons, über die DNS-Server des Anbieters. Genau so soll es sein.

Woher kommen dann Leaks bei HTTP-Proxys? Ihre Quellen sind indirekt:

  • PAC-Skripte. Die Datei zur automatischen Proxy-Konfiguration kann eine Funktion dnsResolve enthalten, die eine Domain lokal auflöst, um zu entscheiden, ob die Anfrage über den Proxy geht. Die Entscheidung wird also erst nach der lokalen DNS-Anfrage getroffen.
  • Vorzeitige Namensauflösung. Manche Anwendungen prüfen die Erreichbarkeit eines Hosts vor der Verbindung: pingen, auflösen, und dann erst durch den Proxy. Java-Anwendungen mit InetAddress, einzelne Parser, Link-Check-Plugins.
  • Hintergrunddienste des Browsers. Seiten-Vorladen, DNS-Prefetch, Safe-Browsing- und Update-Checks können mit eigenen Regeln arbeiten und respektieren die Proxy-Einstellungen nicht immer.

SOCKS: ein Buchstabe zwischen sauberer Session und Leck

Jetzt wird es interessant. Das Protokoll SOCKS4 kann in der Originalversion dem Proxy nur die Ziel-IP übergeben. Das heißt, der Client muss den Namen selbst auflösen, vor der Verbindung. Das Leck ist ins Protokoll eingebaut. Die Erweiterung SOCKS4a fügte die Möglichkeit hinzu, einen Hostnamen zu übergeben. SOCKS5 unterstützt drei Typen von Zieladressen: IPv4, IPv6 und Domainnamen.

Eigentlich löst SOCKS5 das Problem. Aber die Unterstützung des Domainnamens im Protokoll bedeutet nicht, dass der Client sie nutzt. Viele Bibliotheken und Programme lösen den Namen standardmäßig lokal auf und schicken dem Proxy eine fertige IP. Das Protokoll erlaubt das – das Leck passiert einfach einen Schritt früher.

Daher der berühmte Buchstabe h. In curl und in Bibliotheken, die seiner Konvention folgen, bedeutet das Schema socks5:// lokale Namensauflösung, und socks5h:// die Übergabe des Hostnamens an den Proxy zur entfernten Auflösung. Ein Buchstabe. Der Unterschied zwischen einer sauberen Session, in der alles, inklusive DNS, aus dem Mobilfunknetz des Anbieters kommt, und einer Session, in der jeder Name zuerst zu deinem Provider leckt.

Warum der Proxy-Server besser selbst auflösen sollte

Hier gibt es einen nicht offensichtlichen Punkt, den viele übersehen. Es geht nicht nur um Privatsphäre. Wenn die entfernte Seite des mobilen Proxys den Namen auflöst, wird die DNS-Antwort mit Blick auf den Standort des Anbieters gebildet. Große Dienste nutzen CDNs und Geo-DNS: Für dieselbe Domain werden verschiedenen Clients unterschiedliche, ihnen nächstgelegene IPs zurückgegeben. Löst dein Heim-Provider auf, bekommst du die Adresse eines CDN-Knotens in der Nähe deines realen Standorts. Und verbindest dich dann über den mobilen Proxy aus einer anderen Region mit diesem Knoten. Für den Dienst sieht das seltsam aus: Ein Client aus dem Mobilfunknetz der Region A kommt plötzlich zu einem Knoten, der für Region B gedacht ist. Das ist der indirekte Erkennungskanal eines dns leaks, der keinerlei Zugriff auf deine DNS-Anfragen benötigt.

EDNS Client Subnet: wie der Resolver dein Subnetz weitergibt

Der Mechanismus EDNS Client Subnet (ECS) wurde erdacht, damit öffentliche Resolver autoritativen Servern einen Teil der Client-Adresse übermitteln können – üblicherweise die ersten 24 Bit für IPv4. So versteht das CDN, woher der echte Nutzer kommt, und liefert den nächstgelegenen Knoten. Das ist praktisch für die Geschwindigkeit. Aber aus Sicht von Leaks bedeutet das: Bei lokaler Auflösung über einen öffentlichen DNS mit ECS-Unterstützung erhält der autoritative Server der Zieldomain das Subnetz deiner echten Verbindung. Nicht die vollständige Adresse, aber genug, um Provider und Stadt zu verstehen. Und die Verbindung kommt dann von einer mobilen IP. Zwei Subnetze, zwei Anbieter, ein Nutzer.

Verschlüsseltes DNS: eine neue Kategorie von Leaks

Seit den 2020er-Jahren sind Browser und Betriebssysteme massenhaft auf DNS over HTTPS (DoH) und DNS over TLS (DoT) umgestiegen, und bis 2026 kam noch DNS over QUIC hinzu. Die Idee ist gut: Der Provider sieht deine Anfragen nicht mehr. Aber für die Arbeit über einen Proxy entstand ein Nebeneffekt. Ein Browser mit aktiviertem „sicheren DNS“ wendet sich mit eigenem Client an den gewählten DoH-Server, und dieser Traffic folgt keineswegs immer den Proxy-Einstellungen. Das heißt, die Namen werden nicht beim Mobilfunkanbieter aufgelöst, sondern bei einem großen öffentlichen Resolver, und zwar von deiner realen IP aus. Die Verschlüsselung schützt vor dem Provider, aber nicht vor der Diskrepanz zwischen DNS-Seite und Verbindungsseite.

Eine zusätzliche Komplexitätsebene bringt Encrypted Client Hello (ECH). Dafür fragt der Browser spezielle HTTPS-Einträge im DNS ab. Je mehr Websites ECH nutzen, desto mehr DNS-Anfragen macht der Browser – und desto mehr Anlässe für ein Leck, wenn DNS nicht den richtigen Weg geht.

IPv6 und Happy Eyeballs

Moderne Systeme fragen gleichzeitig A-Einträge (IPv4) und AAAA-Einträge (IPv6) ab und versuchen, sich mit dem zu verbinden, was schneller antwortet – der Algorithmus Happy Eyeballs. Wenn dein reales Netz IPv6 unterstützt, der Proxy aber nur über IPv4 arbeitet, können manche Anwendungen direkt über IPv6 gehen und den Proxy komplett umgehen. Streng genommen ist das kein dns leak, sondern ein Verbindungsleck, aber der Auslöser ist genau die DNS-Antwort mit dem AAAA-Eintrag. Deshalb muss man IPv6 im Kontext der DNS-Hygiene im Blick behalten.

Cache und hosts: das Leck aus der Vergangenheit

Das OS cacht DNS-Antworten. Wenn du ohne Proxy gearbeitet hast und dann den Proxy einschaltest, liegen einige Namen bereits im Cache mit Adressen, die über den Heim-Resolver bezogen wurden. Neue Anfragen gibt es nicht, aber die Verbindungen gehen zu den „heimischen“ CDN-Knoten. Ähnlich die Datei hosts: Einträge darin ersetzen die Namensauflösung vollständig, und der Proxy erfährt nichts davon.

Methode 1. Diagnose: Wie du selbst einen dns leak prüfst

Bevor du etwas konfigurierst, musst du das Problem sehen. Die gute Nachricht: Eine DNS-Leck-Prüfung ist eine Fünf-Minuten-Prozedur, die man zu einem Ritual vor jeder Arbeitssession machen kann und sollte.

Wie Online-Tests funktionieren

Jeder Dienst zur Prüfung von dns leak ist gleich aufgebaut. Die Seite generiert mehrere eindeutige Subdomains der Form zufalls-string.test-domain und lässt deinen Browser sie auflösen, meist über das Laden unsichtbarer Bilder oder Skripte. Da die Subdomains eindeutig sind, sind sie garantiert in keinem Cache. Die Anfrage erreicht also auf jeden Fall den autoritativen Server der Testdomain, der dem Dienst gehört. Er protokolliert, von welcher IP die Anfrage kam – das ist die Adresse des rekursiven Resolvers, den du nutzt. Dann zeigt dir die Seite zwei Spalten: die Adresse, von der die HTTP-Verbindung kam, und die Resolver-Adressen. Wenn die Verbindung vom Mobilfunkanbieter kommt, der Resolver aber dem Heim-Provider oder einem öffentlichen DNS-Dienst gehört – gibt es ein Leck.

Wichtig zu verstehen: Genau dasselbe kann jede Website tun. Der Mechanismus erfordert keine besonderen Rechte. Antifraud-Systeme großer Plattformen setzen ähnliche Techniken als Teil der Risikobewertung einer Session ein. Das ist keine Verschwörungstheorie, sondern Standard-Engineering.

Schritt-für-Schritt-Prüfprozedur

  1. Erfasse die Baseline. Schalte den Proxy aus, öffne den dns leak test, notiere, welche Resolver angezeigt werden. Das ist dein „heimischer“ Fingerprint. Du solltest ihn auf einen Blick erkennen.
  2. Leere den DNS-Cache. In Windows der Befehl ipconfig /flushdns, in macOS der Neustart des mDNSResponder-Dienstes, in Linux hängt es vom Resolver ab (z. B. resolvectl flush-caches für systemd-resolved). Starte den Browser neu – er hat einen eigenen Cache.
  3. Aktiviere den Proxy so, wie du tatsächlich arbeiten wirst: über ein Antidetect-Profil, eine Erweiterung, Systemeinstellungen oder Code.
  4. Starte einen erweiterten Test, der nicht eine, sondern Dutzende Prüfungen macht. Ein Leck kann teilweise sein: Neun von zehn Anfragen gehen über den Proxy, die zehnte direkt. Ein einzelner Test übersieht das.
  5. Vergleiche. Alle Resolver sollten dem Mobilfunkanbieter gehören, über den der Proxy läuft, oder der Infrastruktur des Proxy-Dienstes. Keine einzige Adresse aus der Baseline. Kein öffentlicher Resolver, den du nicht bewusst gewählt hast.
  6. Prüfe IPv6 separat. Wenn der Test irgendeine IPv6-Adresse zeigt, die nicht zum Proxy gehört – Leck.
  7. Wiederhole nach zehn Minuten Arbeit. Manche Hintergrundprozesse starten verzögert.

Prüfung ohne Drittanbieter-Dienste: eigene Testdomain

Für alle, die mit Account-Farmen oder Scraping in industriellem Maßstab arbeiten, ist ein eigenes Tool sinnvoll. Das Schema: Du registrierst eine günstige Domain und betreibst dafür einen autoritativen DNS-Server auf deinem VPS mit aktiviertem Query-Logging. Dann rufst du in jedem Projekt beim Start jeder Session eine eindeutige Subdomain der Form session-identifikator.deine-domain auf. Im Log des DNS-Servers erscheint ein Eintrag: welche Subdomain angefragt wurde und von welcher Resolver-IP. Du vergleichst mit der Session-ID und siehst sofort, welche Session, welches Profil, welcher Worker geleckt hat. Das verwandelt eine einmalige Prüfung in kontinuierliches Monitoring.

Low-Level-Prüfung: ins Netzwerk schauen

Die ehrlichste Methode ist, zu sehen, was tatsächlich das Netzwerk-Interface verlässt. Starte einen Traffic-Analyzer (Wireshark oder tcpdump) auf dem physischen Interface der Maschine und filtere Port 53 UDP und TCP sowie Port 853 für DoT. Dann arbeite fünf Minuten über den Proxy. In der idealen Welt bleibt der Filter leer: Alle Namen werden auf der Proxy-Seite aufgelöst, es gibt überhaupt keine lokalen DNS-Pakete. Wenn Pakete da sind, siehst du sofort, welche Domains wohin gehen. Bei DoH ist der Filter komplizierter, weil es normales HTTPS auf Port 443 ist, aber ein Hinweis sind Verbindungen zu bekannten Adressen öffentlicher DoH-Anbieter, die nicht über den Proxy erscheinen.

Diagnose-Checkliste

  • Baseline ohne Proxy notiert.
  • OS- und Browser-Cache vor dem Test geleert.
  • Erweiterter Test mit Dutzenden Anfragen durchgeführt.
  • Alle Resolver entsprechen der Proxy-Seite.
  • IPv6-Adressen fremder Netze fehlen.
  • Wiederholter Test nach 10 Minuten Arbeit bestanden.
  • Für kritische Projekte: Traffic-Analyzer auf Port 53 zeigt null Pakete.

Methode 2. Richtige Konfiguration von Client-Software und Code

Du hast das Leck gefunden. Jetzt musst du verstehen, wo genau die Anwendung entscheidet, den Namen lokal aufzulösen, und sie auf entfernte Auflösung umstellen. Wir gehen die häufigsten Umgebungen aus der Praxis von Media-Buyern und Entwicklern durch.

Prinzip: Der Hostname muss beim Proxy ankommen

Die Regel ist eine, und sie ist universell. Der Proxy muss von dir den Domainnamen bekommen, nicht die IP. Bei HTTP-Proxys passiert das natürlich. Bei SOCKS5 musst du explizit den Modus für entferntes DNS wählen. Bei SOCKS4 ohne Erweiterung a ist das prinzipiell unmöglich – solche Proxys sind für saubere Arbeit ungeeignet. Mobile Proxys moderner Dienste unterstützen sowohl HTTP als auch SOCKS5 mit entferntem Resolving, die Einschränkung liegt also nur auf Client-Seite.

curl und Kommandozeile

Für SOCKS5 immer das Schema mit dem Buchstaben h verwenden. Beispiel für einen korrekten Aufruf:

curl -x socks5h://user:pass@host:port https://example.com/

Ohne den Buchstaben h löst curl den Namen lokal auf. Das gilt auch für alle Tools, die auf libcurl aufbauen. Für HTTP-Proxys reicht das Schema http:// im Parameter -x: Der Name geht in der CONNECT-Anfrage mit.

Python: requests, httpx, aiohttp

In der Bibliothek requests mit installiertem SOCKS-Support gilt dieselbe Regel: socks5:// bedeutet lokales Resolving, socks5h:// entferntes. Das ist der häufigste Fehler in Parsern: Der Entwickler kopiert ein Beispiel aus der Dokumentation, in dem socks5 steht, und betreibt jahrelang Traffic mit dns leak, ohne es zu ahnen. In httpx und aiohttp wird SOCKS-Unterstützung über Drittanbieter-Transports realisiert, und der Modus für entferntes Resolving muss in der Dokumentation des konkreten Transports geprüft werden – mal ist es der Parameter rdns, mal ebenfalls das Schema mit h. Prüfe nicht nach der Dokumentation, sondern nach der Realität: Starte das Skript gegen deine eigene Testdomain und schau im Log, woher die Anfrage kam.

Eine separate Falle sind Low-Level-Socket-Bibliotheken, die das Standardmodul socket monkeypatchen, um den gesamten Traffic in SOCKS zu verpacken. Sie haben ein Flag für entferntes Resolving, aber es ist standardmäßig oft aus. Außerdem geht jeder Aufruf von socket.gethostbyname in deinem Code oder in Abhängigkeiten daran vorbei und löst den Namen über den System-Resolver auf.

Node.js und Headless-Browser

Im Node.js-Ökosystem übergeben SOCKS-Agenten den Hostnamen normalerweise an den Proxy, aber das hängt vom konkreten Paket und seiner Version ab. Für Puppeteer und Playwright wird der Proxy auf der Ebene des Browser-Starts gesetzt, und das Verhalten wird von der Chromium-Engine geerbt – über ihre Besonderheiten mit SOCKS5 sprechen wir im nächsten Abschnitt. Wenn du mit dem HTTP-Modus des mobilen Proxys arbeitest, entfällt die Frage: Chromium sendet CONNECT mit dem Hostnamen.

Go, Java und andere Sprachen

In Go übergibt das Standardpaket golang.org/x/net/proxy für SOCKS5 den Hostnamen entfernt, aber nur, wenn du seinen Dialer direkt nutzt und nicht vorher auflöst. In Java funktionieren die System-Properties für SOCKS-Proxys, aber viele HTTP-Clients erstellen ein InetSocketAddress-Objekt mit vorheriger Auflösung, was das Leck verursacht. Die Lösung ist, eine nicht aufgelöste Adresse zu erstellen (Methoden wie createUnresolved) und sicherzustellen, dass der Client die Übergabe des Namens unterstützt. Ein universeller Tipp für jede Sprache: Finde im Code und in den Abhängigkeiten alle Stellen, an denen eine Domain in eine IP verwandelt wird, und stelle sicher, dass das nach dem Verbindungsaufbau mit dem Proxy passiert, nicht davor.

Schrittweises Projekt-Audit

  1. Finde im Code alle Verbindungszeichenfolgen zum Proxy. Prüfe die Schemata: socks5 ohne h – rote Flagge.
  2. Finde alle expliziten Aufrufe der Namensauflösung: gethostbyname, getaddrinfo, dns.lookup, InetAddress.getByName. Jeder ist ein potenzielles Leck.
  3. Prüfe Abhängigkeiten: Bibliotheken für Erreichbarkeitsprüfung, Health-Check, Retries mit vorherigem Ping.
  4. Starte das Projekt gegen deine eigene Testdomain mit einer eindeutigen Subdomain pro Worker. Das DNS-Server-Log zeigt, wer leckt.
  5. Füge einen Autotest hinzu: Eine Session gilt nicht als gültig, bis die DNS-Prüfung bestätigt hat, dass der Resolver zur Proxy-Seite gehört.
  6. Halte das Ergebnis in der Projektdokumentation fest: welche Bibliothek, welche Version, welcher Modus.

Checkliste für Entwickler

  • Alle SOCKS5-Verbindungen nutzen entferntes Resolving.
  • Kein vorheriges Resolving vor der Verbindung.
  • Bibliotheken nicht nach Dokumentation geprüft, sondern nach dem Log der Testdomain.
  • Automatische DNS-Prüfung in den Session-Start eingebaut.
  • Für den HTTP-Modus des Proxys geprüft, dass CONNECT genutzt wird und nicht eine IP-Substitution.

Methode 3. Browser und Antidetect-Browser ohne DNS-Leaks

Ein großer Teil der Zielgruppe mobiler Proxys arbeitet nicht im Code, sondern im Browser: Werbekonten, soziale Netzwerke, Marktplätze, Multi-Accounting. Hier gelten eigene Regeln, und sie unterscheiden sich von Engine zu Engine.

Firefox und seine Verwandten

Firefox bietet historisch die transparenteste Kontrolle. Der Schlüsselparameter in about:config ist network.proxy.socks_remote_dns. Bei true werden Namen an den SOCKS-Proxy zur entfernten Auflösung übergeben. Bei false werden sie lokal aufgelöst. In vielen alten Builds und Profilen ist er ausgeschaltet. Der zweite Parameter ist network.trr.mode, der verschlüsseltes DNS steuert: Der Wert 5 deaktiviert es vollständig, was für die Arbeit über einen Proxy vorzuziehen ist, weil der Browser sonst mit eigenem Client einen DoH-Server ansprechen kann. Der dritte Block ist das Prefetching: network.dns.disablePrefetch auf true und network.predictor.enabled auf false deaktivieren das spekulative Auflösen von Namen für Links auf der Seite, das sonst vor dem tatsächlichen Klick am Proxy vorbeigehen kann. Antidetect-Browser auf Firefox-Basis setzen diese Parameter normalerweise korrekt, aber nach jedem Update lohnt sich eine Prüfung.

Chrome, Chromium und Antidetects auf ihrer Basis

Bei Chromium ist die Geschichte komplizierter. Bei der Arbeit über einen HTTP-Proxy sendet er CONNECT mit dem Namen – kein Leck. Bei der Nutzung eines SOCKS5-Proxys über ein Start-Flag löst die Engine jedoch in manchen Konfigurationen Namen lokal auf, und eine Standard-Einstellung „entferntes DNS“ gibt es in der Oberfläche nicht. Ein bekannter Engineering-Trick ist das Flag --host-resolver-rules mit einer Regel, die alle Namen auf „nicht gefunden“ mappt, mit Ausnahme der Proxy-Adresse. Dadurch kann der lokale Resolver nichts auflösen, und der Browser ist gezwungen, Namen an den Proxy zu übergeben. Es sieht wie ein Workaround aus, funktioniert aber zuverlässig. Der zweite wichtige Punkt ist die Einstellung sicheres DNS im Datenschutzbereich: Bei aktiviertem Zustand nutzt Chromium DoH zum gewählten Anbieter, und dieser Traffic folgt nicht immer dem Proxy. Für die Arbeit über einen mobilen Proxy sollte man ihn deaktivieren oder in Tests sicherstellen, dass er korrekt getunnelt wird. Der dritte Punkt ist das Seiten-Vorladen: In den Leistungseinstellungen gibt es eine Option zum Vorladen, die DNS-Anfragen für Links auslöst, auf die du noch nicht geklickt hast.

Was ein Antidetect-Browser können muss

Ein guter Antidetect übernimmt diese ganze Routine. Aber die Qualität der Umsetzung variiert stark. Das solltest du bei der Auswahl und nach jedem Update prüfen:

  • Modus für entferntes DNS bei SOCKS5 ist standardmäßig für jedes Profil aktiviert, nicht global.
  • DNS-Isolation zwischen Profilen. Der Cache aufgelöster Namen darf nicht geteilt werden: Sonst bekommt ein Profil auf dem mobilen Proxy einer Region eine IP, die vom Profil auf dem Proxy einer anderen Region gecacht wurde.
  • Deaktiviertes oder getunneltes verschlüsseltes DNS. Frag den Support direkt: Wie verhält sich das integrierte DoH bei der Arbeit über einen Proxy?
  • Deaktiviertes Prefetch. Spekulative Auflösung darf nicht in einem Profil leben, das einen normalen Mobilnutzer simuliert.
  • Integrierte Prüfung auf dns leak beim Start des Profils oder zumindest ein bequemer Zugang zum Test.
  • Verhalten beim Proxy-Abbruch. Was macht der Browser, wenn der Proxy nicht erreichbar ist: Verbindungen blockieren oder direkt rausgehen? Letzteres ist eine Katastrophe, nicht nur für DNS.

Proxy-Erweiterungen: dünnes Eis

Browser-Erweiterungen, die den Proxy umschalten, arbeiten über die Browser-API. Sie können den Proxy für Verbindungen setzen, aber ihre Kontrolle über DNS ist durch die Fähigkeiten der Engine begrenzt. Eine Erweiterung kann Chromium nicht dazu zwingen, für SOCKS5 entferntes DNS zu nutzen, wenn die Engine das in dieser Konfiguration nicht tut. Außerdem verwaltet die Erweiterung die Hintergrunddienste des Browsers nicht. Deshalb sind Erweiterungen eine akzeptable Option für den HTTP-Modus des mobilen Proxys und schnelle Prüfungen, aber nicht für ernsthafte Arbeit mit sensiblen Accounts.

Schrittweise Profileinrichtung

  1. Erstelle ein Profil und gib den mobilen Proxy an. Bevorzuge den HTTP-Modus, wenn der Antidetect entferntes DNS für SOCKS5 nicht garantiert.
  2. Deaktiviere verschlüsseltes DNS in den Engine- oder Profil-Einstellungen.
  3. Deaktiviere Seiten-Vorladen und DNS-Prefetch.
  4. Wenn es eine Firefox-ähnliche Engine ist – prüfe socks_remote_dns manuell.
  5. Starte das Profil, leere den Cache und führe den erweiterten dns leak test durch.
  6. Surfe auf mehreren Seiten mit aktiver Analytics und wiederhole den Test: Sind neue Resolver aufgetaucht?
  7. Speichere das Ergebnis als Referenz für dieses Profil.

Methode 4. Systemebene und Infrastruktur: Leaks zwangsweise schließen

Alle vorherigen Methoden arbeiten nach dem Prinzip Vertrauen: Wir konfigurieren die Anwendung und hoffen, dass sie sich richtig verhält. Der Ingenieursansatz ist anders: Ein Leck technisch unmöglich machen. Selbst wenn die Anwendung versucht, eine DNS-Anfrage direkt zu senden, darf sie nicht rausgehen.

Prinzip „alles verboten, was nicht über den Proxy geht“

Auf dem Arbeitsrechner oder dem Server einer Farm richtet man eine Firewall ein, die ausgehenden Traffic auf Port 53 (UDP und TCP) und Port 853 für alle Prozesse blockiert, außer für explizit erlaubte. In Windows sind das Regeln für ausgehende Verbindungen in der Firewall, in Linux nftables oder iptables, in macOS pf. Der Sinn: Wenn der Browser oder das Skript versucht, einen Namen lokal aufzulösen, bekommt er einen Fehler statt eines stillen Leaks. Der Fehler ist sofort sichtbar – du siehst ihn und korrigierst die Anwendungskonfiguration. Ein stilles Leck kann monatelang leben.

Eine Feinheit bei DoH: Es geht auf Port 443, den man nicht komplett blockieren kann. Die Lösung ist, nicht den Port zu blockieren, sondern die Adressen bekannter öffentlicher DoH-Resolver für die Prozesse, die ausschließlich über den Proxy gehen sollen. Das erfordert Pflege einer Liste, aber die Liste ändert sich selten.

Isolation durch Container und Netzwerk-Namespaces

Für Entwickler und Farmbetreiber auf Linux ist das mächtigste Werkzeug Netzwerk-Namespaces und Container. Die Idee: Jeder Worker, jedes Browser-Profil oder eine Gruppe von Profilen lebt in einem eigenen Netzwerk-Namespace, in dem es überhaupt keine Default-Route ins Internet gibt. Der einzige Weg nach draußen ist die Proxy-Adresse. Was auch immer die Anwendung versucht – einen Namen auflösen, über IPv6 rausgehen, eine direkte Verbindung öffnen – sie hat physisch keine Route. Das ist die zuverlässigste Methode, um dns leak im Maßstab zu garantieren. In Docker erreicht man das mit einem benutzerdefinierten Netzwerk ohne externes Gateway plus explizitem Zugriff nur auf die Proxy-Adresse. Zusätzlich kann man in der Resolver-Konfiguration des Containers eine absichtlich unerreichbare Adresse angeben, damit jeder Versuch lokaler Auflösung sofort fehlschlägt, statt auf Timeout zu hängen.

IPv6 auf Systemebene

Wenn dein mobiler Proxy über IPv4 arbeitet und die Maschine eine IPv6-Verbindung hat, ist die einfachste und zuverlässigste Lösung, IPv6 auf dem Interface zu deaktivieren, mit dem die Proxy-Profile arbeiten, oder ausgehendes IPv6 per Firewall zu verbieten. Ja, das ist grob. Aber es schließt eine ganze Klasse von Problemen aus, bei denen ein AAAA-Eintrag in der DNS-Antwort die Verbindung direkt leitet.

System-Resolver und seine Besonderheiten

Moderne OS haben mehrschichtige Resolver. In Windows 11 gibt es DoH-Unterstützung auf Systemebene, und wenn sie für deinen Adapter aktiviert ist, gehen alle lokalen Auflösungen an den gewählten DoH-Server. Für einen Arbeitsrechner mit Proxy muss man sich dessen bewusst sein: Aktiviertes System-DoH verändert das Leck-Bild, beseitigt es aber nicht. Android nutzt die Funktion Private DNS – eine ähnliche Geschichte für alle, die mit Proxys auf Mobilgeräten oder Emulatoren arbeiten. In Linux mit systemd-resolved sollte man prüfen, welche DNS-Server jedem Interface zugewiesen sind, denn der Resolver kann Anfragen nach Domänensuffixen zwischen Interfaces routen, und das erzeugt unerwartete Wege.

Monitoring als Prozess

Auf Infrastrukturebene wird die Prüfung auf dns leak von einer einmaligen zu einer kontinuierlichen. Was sich lohnt einzuführen:

  • Logging blockierter DNS-Versuche durch die Firewall. Jeder Eintrag im Log ist eine Anwendung, die versucht, lokal aufzulösen. Das ist deine Liste zum Abarbeiten.
  • Eigene Testdomain mit eindeutigen Subdomains pro Session und automatischer Alert bei Erscheinen eines fremden Resolvers.
  • Periodischer Netzwerk-Traffic-Snapshot auf Port 53 vom physischen Interface – täglich, automatisch, mit Alert bei nicht-null Zähler.
  • Prüfung nach jedem Update von Browser, Antidetect, Bibliotheken. Updates sind die Hauptquelle für Regressionen: Entwickler ändern Defaults, aktivieren neue Prefetch-Features, fügen verschlüsseltes DNS hinzu.

Checkliste auf Systemebene

  • Ausgehender Traffic auf Ports 53 und 853 ist für Arbeitsprozesse blockiert.
  • Bekannte öffentliche DoH-Adressen sind für dieselben Prozesse blockiert.
  • IPv6 ist auf Arbeits-Interfaces deaktiviert oder blockiert.
  • Kritische Worker sind in Netzwerk-Namespaces ohne direkte Route isoliert.
  • Firewall-Logs zu DNS werden gesammelt und durchgesehen.
  • Testdomain und Alerting sind eingerichtet.

Typische Fehler: Was man nicht tun sollte

Fehler 1. Nur die IP prüfen

Der häufigste. Man sieht die Adresse eines Mobilfunkanbieters auf der IP-Prüfseite und hält die Aufgabe für erledigt. Aber die IP-Prüfung beantwortet nur die Frage „Woher kam die Verbindung“, nicht „Woher kamen die DNS-Anfragen“. Das sind verschiedene Fragen mit verschiedenen Antworten.

Fehler 2. Öffentlichen DNS eintragen und sich beruhigen

Die Logik ist verständlich: Wenn der Provider meine Anfragen sieht, gebe ich einen öffentlichen Resolver an. Aber für die Arbeit über einen Proxy ist das keine Lösung, sondern der Austausch eines Lecks gegen ein anderes. Die Anfragen gehen weiter von deiner realen IP aus, jetzt an einen anderen Beobachter. Und öffentliche Resolver nutzen zudem aktiv ECS und übermitteln dein Subnetz an autoritative Server. Die Diskrepanz zwischen DNS-Seite und Verbindungsseite bleibt.

Fehler 3. SOCKS5 ohne entferntes DNS nutzen

Das Schema socks5 statt socks5h im Code, ausgeschaltetes socks_remote_dns im Browser, Antidetect mit Standard-lokalem Resolving. Tausende Projekte leben jahrelang mit diesem Fehler.

Fehler 4. Verschlüsseltes DNS für die Lösung des Problems halten

DoH schützt den Inhalt der Anfragen vor dem Provider. Aber bei der Arbeit über einen Proxy schafft es einen separaten Kanal, der nicht über den Proxy geht. Verschlüsselung ist nicht gleich richtiges Routing.

Fehler 5. Prefetch und Hintergrunddienste ignorieren

Der Browser löst Namen von Links auf, die du noch nicht geöffnet hast. Das Antivirus prüft URLs. Der Updater sucht den Update-Server. All das sind DNS-Anfragen, die am Proxy vorbeigehen können. Eine Prüfung mit einem einzelnen Test fängt solche Dinge nicht.

Fehler 6. Gemeinsamer DNS-Cache zwischen Profilen

Wenn zwei Profile auf Proxys verschiedener Regionen einen Cache teilen, verbindet sich das zweite Profil mit einem CDN-Knoten, der für die erste Region gewählt wurde. Die Isolation von Profilen muss DNS einschließen.

Fehler 7. Nach Updates nicht testen

Eine neue Browserversion hat sicheres DNS standardmäßig aktiviert. Eine aktualisierte Bibliothek hat das SOCKS-Verhalten geändert. Ein Antidetect-Update hat Engine-Einstellungen zurückgesetzt. All das sind reale Szenarien, die nur durch erneute Prüfung aufgedeckt werden.

Fehler 8. Direkten Ausgang bei Proxy-Nichtverfügbarkeit erlauben

Einstellungen wie „Wenn der Proxy nicht antwortet, direkt gehen“ verwandeln jeden Ausfall in eine vollständige De-Anonymisierung der Session, angefangen bei DNS. Das richtige Verhalten ist, Verbindungen bis zur Wiederherstellung des Proxys zu blockieren.

Fehler 9. Manuelles Resolving „wegen der Geschwindigkeit“

Manche Parser lösen die Domain einmal auf und gehen dann über die IP, um DNS zu sparen. Neben dem Leck der Anfrage selbst bekommen sie eine IP, die das Geo-DNS für ihre reale Region gewählt hat, und schicken dann Traffic über den mobilen Proxy zu einem „fremden“ CDN-Knoten. Die Millisekunden-Ersparnis führt zu einem inkonsistenten Profil.

Tools und Ressourcen

Online-Leak-Tests

Dienste zur Prüfung von dns leak teilen sich in Basis- und erweiterte. Basis-Dienste machen ein bis zwei Anfragen und eignen sich für eine schnelle Einschätzung. Erweiterte generieren Dutzende eindeutige Subdomains und decken teilweise Lecks auf. Für die Arbeit wähle die, die nicht nur die Resolver-IP zeigen, sondern auch deren Zugehörigkeit: Organisation, autonomes System, Land. Ein guter Test zeigt zudem IPv4 und IPv6 separat und kann das Verhalten bei wiederholten Anfragen prüfen.

Traffic-Analyzer

Wireshark – grafischer Analyzer mit Filtern wie dns oder udp.port == 53. tcpdump – Konsolen-Pendant für Server und Linux-Maschinen. Beide lassen dich die Wahrheit sehen: Was verlässt tatsächlich das Netzwerk-Interface. Für DoH schau zusätzlich auf TLS-Verbindungen zu Adressen öffentlicher Resolver.

Eigener autoritativer DNS

Für Monitoring im Maßstab: ein beliebiger leichter DNS-Server mit Query-Logging (CoreDNS, Unbound im autoritativen Modus, BIND, kompakte Server in Go oder Python) plus eigene Domain. Der Aufwand ist minimal, das Ergebnis ist permanente Aufsicht über alle Worker und Profile.

Kommandozeilen-Tools

dig und nslookup zeigen, welchen Resolver das System anspricht und was er antwortet. resolvectl in Linux mit systemd-resolved zeigt die DNS-Konfiguration pro Interface. curl mit ausführlicher Ausgabe zeigt, ob es den Namen an den Proxy übergibt oder selbst auflöst. In Windows zeigt ipconfig /displaydns den Cache-Inhalt, und Get-DnsClientServerAddress in PowerShell die zugewiesenen Server pro Adapter.

Firewalls

Die integrierte Windows-Firewall mit Regeln pro Programm, nftables und iptables in Linux, pf in macOS. Zur bequemen Verwaltung von Regeln pro Anwendung gibt es grafische Aufsätze. Die Kernanforderung ist die Möglichkeit, Ports für konkrete Prozesse zu blockieren und ein Log der Blockierungen zu führen.

Containerisierung

Docker und Podman mit benutzerdefinierten Netzwerken, Linux-Netzwerk-Namespaces über ip netns, und für Browser-Farmen Profil-Orchestratoren, die Netzwerk-Isolation auf Profilebene unterstützen. Sie verwandeln die Regel „nur über den Proxy“ von einer Einstellung in eine architektonische Garantie.

Möglichkeiten auf Seiten des Proxy-Dienstes

Achte darauf, was der Anbieter mobiler Proxys selbst bietet: Unterstützung von SOCKS5 mit entfernter Namensauflösung, HTTP-Modus mit korrekter CONNECT-Behandlung, DNS-Stabilität auf Seiten des Anbieters, keine DNS-Antwort-Substitution auf Seiten der Infrastruktur. Es ist nützlich, beim Support nachzufragen, über welche Resolver Namen beim entfernten Resolving aufgelöst werden – die richtige Antwort: über die Resolver des Mobilfunkanbieters, mit dessen Netz das Modem verbunden ist.

Fälle und Ergebnisse

Fall 1. Werbekonto-Farm und die unsichtbare Ursache von Bans

Ein Media-Buying-Team betrieb etwa 120 Werbekonten auf mobilen Proxys über einen populären Antidetect. Die durchschnittliche Lebensdauer eines Kontos bis zur Sperrung lag bei 9–12 Tagen bei äußerlich einwandfreier Konfiguration: mobile IPs der richtigen Region, sorgfältige Fingerprints, Warm-up. Das Audit zeigte, dass nach einem Antidetect-Update in der Engine verschlüsseltes DNS aktiviert war und alle Profile Namen über denselben öffentlichen DoH-Resolver von der realen IP des Büros auflösten. 120 „unabhängige“ Nutzer aus verschiedenen Städten lösten Namen von einem Punkt aus auf. Nach Deaktivierung von DoH, Aktivierung von entferntem DNS und Blockierung von Port 53 per Firewall stieg die durchschnittliche Lebensdauer der Konten auf 30+ Tage, und der Anteil früher Sperrungen in der ersten Woche sank etwa um das Dreifache. Die Kosten der Behebung: zwei Stunden Arbeit eines Spezialisten.

Fall 2. Marktplatz-Parser und rätselhafte Geo-Preise

Ein Entwickler sammelte Preise von einem großen Marktplatz nach Regionen über mobile Proxys verschiedener Städte. Die Daten stimmten nicht mit dem überein, was echte Nutzer in diesen Regionen sahen: Ein Teil der Preise und Verfügbarkeiten entsprach einer ganz anderen Stadt. Die Ursache lag in der Verbindungszeichenfolge: die Bibliothek requests mit dem Schema socks5 ohne h. Die Namen wurden lokal in der Stadt des Entwicklers aufgelöst, das Geo-DNS des Marktplatzes lieferte den Knoten seiner Region, und dann kamen die Anfragen über den mobilen Proxy einer anderen Stadt bei einem „fremden“ Knoten an, der die regionale Ausgabe nach seiner Logik zurückgab. Der Austausch eines Buchstabens in der Konfiguration und das Hinzufügen einer automatischen DNS-Prüfung beim Start jedes Workers stellten die Korrektheit der Daten wieder her. Nebeneffekt: Der Anteil der Anfragen, auf die der Marktplatz mit Captcha antwortete, sank – die Sessions wurden konsistenter.

Fall 3. Werbetests für regionale Zielgruppen

Eine Marketingagentur prüfte, wie Werbeanzeigen und Landingpages Nutzern verschiedener Regionen angezeigt werden, und arbeitete über mobile Proxys und einen Chromium-Browser mit SOCKS5-Verbindung. Ein Teil der Prüfungen zeigte Inhalte der falschen Region. In den Logs der eigenen Testdomain der Agentur gehörten die Resolver dem Provider des Büros. Der Wechsel in den HTTP-Modus derselben mobilen Proxys, bei dem Chromium Namen über CONNECT übergibt, plus die Deaktivierung des Seiten-Vorladens beseitigten die Diskrepanz. Ein zusätzlicher Bonus – stabile Prüfergebnisse ohne wiederholte Durchläufe sparten dem Team etwa 15 Prozent Zeit bei regelmäßigen Audits.

Fall 4. Multi-Accounting in einem sozialen Netzwerk und gemeinsamer Cache

Ein Betreiber von Dutzenden Accounts in einem sozialen Netzwerk bemerkte, dass Konten, die am selben Tag arbeiteten, in Gruppen gesperrt wurden. Die Analyse zeigte zwei Faktoren auf der DNS-Ebene: Der Antidetect nutzte einen gemeinsamen DNS-Cache zwischen Profilen, und ein Teil der Profile lief auf SOCKS5 ohne entferntes Resolving. Infolgedessen verbanden sich Profile auf Proxys verschiedener Regionen mit denselben CDN-Knoten, und ein Teil von ihnen löste Namen zudem von einer realen IP auf. Nach Aktivierung der Cache-Isolation pro Profil und Umstellung aller Verbindungen auf entferntes DNS hörten die Gruppen-Sperrungen auf; in den folgenden zwei Monaten kehrten die Account-Verluste auf das Niveau zurück, das für sorgfältige manuelle Arbeit typisch ist.

Allgemeine Schlussfolgerung aus den Fällen

In allen vier Geschichten waren die Proxys einwandfrei. Das Problem lebte auf Client-Seite und kostete Wochen an Arbeit, Budgets und Accounts. Die Behebung dauerte jedes Mal Stunden. Dieses Verhältnis ist charakteristisch für dns leak: Das Problem ist ohne spezielle Prüfung unsichtbar, aber einfach zu beheben, wenn man weiß, wo man hinschauen muss.

FAQ: schwierige Fragen zu DNS-Leaks

Wenn die Website meine DNS-Anfragen nicht bekommt, wie erfährt sie dann vom Leck?

Über drei indirekte Wege. Erstens eindeutige Test-Subdomains: Die Website kann deinen Browser dazu bringen, eine Domain aufzulösen, die sie selbst kontrolliert, und sehen, von welchem Resolver die Anfrage kam. Zweitens Geo-DNS und CDN: Wenn du bei einem Knoten ankommst, der für eine andere Region gedacht ist, ist diese Diskrepanz zu deiner IP auf Seiten der Infrastruktur sichtbar. Drittens EDNS Client Subnet: Öffentliche Resolver übermitteln das Client-Subnetz an autoritative Server, und es stimmt nicht mit dem Subnetz der Verbindung überein. Keiner dieser Wege erfordert Zugriff auf deinen Provider.

Der mobile Proxy löst Namen über den Anbieter auf. Ist das gut oder schlecht?

Es ist ideal für die Glaubwürdigkeit. Ein echter Mobilfunk-Teilnehmer löst Namen über die Resolver seines Anbieters auf, und seine Verbindungen kommen von Adressen desselben Anbieters. Wenn dein Proxy dasselbe tut, gehören DNS-Seite und Verbindungsseite zum selben Netz. Genau diesen Zustand solltest du in Tests sehen: die Resolver des Anbieters, die IP des Anbieters, eine Region.

Warum ist der HTTP-Modus des mobilen Proxys in Bezug auf DNS besser als SOCKS5?

Weil im HTTP-Modus der Hostname per Protokolldefinition an den Proxy übergeben wird – in CONNECT für HTTPS und in der URL für HTTP. Der Client kann den Namen nicht versehentlich lokal auflösen, außer in exotischen Fällen wie PAC-Skripten. In SOCKS5 ist entferntes Resolving eine Option, die der Client explizit wählen muss, und viele Clients tun das standardmäßig nicht. Wenn du dir beim Verhalten eines konkreten Browsers oder einer Bibliothek nicht sicher bist, ist der HTTP-Modus sicherer. SOCKS5 ist bequemer für Nicht-HTTP-Protokolle, erfordert aber Kontrolle.

Reicht es, einfach sicheres DNS im Browser zu deaktivieren?

Nein. Das schließt einen Kanal – das DoH des Browsers. Es bleiben lokales Resolving für SOCKS5, Prefetch, Hintergrunddienste, System-DoH im OS und IPv6. Das Deaktivieren von sicherem DNS ist ein notwendiger, aber kein ausreichender Schritt. Ausreichend ist nur die Bestätigung durch einen erweiterten Test und idealerweise die Blockierung von direktem DNS auf Systemebene.

Was tun, wenn im Test Resolver auftauchen, die weder mir noch dem Anbieter gehören?

Der Kette nach analysieren. Bestimme zuerst die Organisation per IP: Wenn es ein öffentlicher DNS-Dienst ist, suche nach aktiviertem DoH im Browser oder System. Wenn es ein unbekanntes Hosting ist, nutzt die Proxy-Infrastruktur möglicherweise eigene Resolver statt der des Anbieters – frag beim Anbieter nach. Wenn es dein Provider ist, aber nicht der Resolver aus der Baseline – vielleicht IPv6 oder ein anderer Adapter. Jeder unerwartete Resolver hat eine Erklärung, und man muss sie finden, nicht ignorieren.

Beeinflusst dns leak die Geschwindigkeit der Arbeit über einen Proxy?

Es beeinflusst sie, und oft in unerwarteter Richtung. Bei lokaler Auflösung wählt das Geo-DNS einen CDN-Knoten in der Nähe deines realen Standorts, und der Traffic geht dann über das Mobilfunknetz einer anderen Region zu diesem Knoten – die Route wird länger als optimal. Bei entfernter Auflösung wird der Knoten in der Nähe des Proxy-Ausgangs gewählt, und der Weg vom Proxy zum Server ist kürzer. Eine richtige DNS-Konfiguration verlangsamt also normalerweise nicht, sondern beschleunigt in manchen Fällen das Laden.

Wie testet man dns leak in automatisierten Szenarien ohne Browser?

Der zuverlässigste Weg ist die eigene Testdomain. Beim Start jedes Workers ruft das Skript über den Proxy eine eindeutige Subdomain auf, und dein autoritativer DNS-Server loggt, von welchem Resolver die Anfrage kam. Das Skript liest dann das Log per API und vergleicht die Resolver-Adresse mit dem erwarteten Bereich des Anbieters. Wenn es keine Übereinstimmung gibt, startet die Session nicht. Das verwandelt die Prüfung von einer manuellen in eine vertragliche: Der Worker darf nicht arbeiten, bis er die Sauberkeit von DNS bewiesen hat.

Wie verändert sich das Bild mit der Verbreitung von ECH und verschlüsseltem DNS im Jahr 2026?

Die Landschaft bewegt sich in Richtung „DNS wird wichtiger“. ECH hängt von DNS-Einträgen des Typs HTTPS ab, Browser aktivieren verschlüsseltes DNS standardmäßig, Betriebssysteme fügen System-DoH und DoQ hinzu. Für den normalen Nutzer ist das ein Plus an Privatsphäre. Für alle, die über einen Proxy arbeiten, bedeutet das mehr DNS-Traffic, mehr unabhängige DNS-Clients im System und mehr Punkte, an denen eine Anfrage am Proxy vorbeigehen kann. Antifraud-Systeme wiederum nutzen zunehmend die Konsistenz zwischen DNS-Seite und Verbindungsseite als Signal. Fazit: Disziplin im Umgang mit DNS wird von „wünschenswert“ zu „obligatorisch“.

Kann man einem Antidetect-Browser vertrauen, der Schutz vor dns leak verspricht?

Vertrauen – ja, prüfen – unbedingt. Eine Marketingaussage hebt Regressionen nach Updates, Unterschiede zwischen Engines und die Spezifik deiner Proxy-Konfiguration nicht auf. Prüfe jedes Profil nach der Erstellung und nach jedem Browser-Update. Ein erweiterter Test dauert eine Minute, die Wiederherstellung einer abgebrannten Farm Wochen.

Fazit: DNS als Fundament einer sauberen Session

Fassen wir zusammen. Der Proxy ändert die Adresse, von der die Verbindung kommt, garantiert aber nicht, dass die Namensauflösung denselben Weg geht. Die DNS-Anfrage erfolgt vor der Verbindung, und genau in dieser Lücke entsteht der dns leak. Für Nutzer mobiler Proxys ist das besonders kritisch: Der ganze Wert einer mobilen IP liegt in ihrer Ähnlichkeit mit einem echten Teilnehmer, und ein echter Teilnehmer löst Namen über seinen Anbieter auf. Die Diskrepanz zwischen DNS-Seite und Verbindungsseite verrät die Nutzung eines Proxys zuverlässiger als viele andere Anzeichen.

Wir haben analysiert, wie DNS in verschiedenen Szenarien leckt: SOCKS ohne entferntes Resolving, verschlüsseltes DNS in Browsern und Systemen, Prefetch, gemeinsamer Cache, IPv6, PAC-Skripte und vorheriges Resolving im Code. Wir haben vier Methoden gegeben, die zusammenwirken: Diagnose mit Baseline und erweitertem Test, richtige Konfiguration von Clients und Bibliotheken, Einrichtung von Browsern und Antidetects und schließlich zwangsweiser Schutz auf Firewall- und Netzwerk-Isolationsebene. Jede Methode allein schließt einen Teil des Problems. Alle zusammen machen ein Leck technisch unmöglich.

Deine nächsten Schritte

  1. Heute: Nimm die Baseline ohne Proxy auf, führe dann in jedem Arbeitsprofil und jedem Skript den erweiterten dns leak test durch. Notiere die Ergebnisse.
  2. Diese Woche: Prüfe alle Verbindungszeichenfolgen im Code auf socks5 ohne h, deaktiviere verschlüsseltes DNS und Prefetch in den Browsern, stelle die Cache-Isolation zwischen Profilen sicher.
  3. Diesen Monat: Blockiere direktes DNS auf Systemebene für Arbeitsprozesse, deaktiviere oder blockiere IPv6 auf Arbeits-Interfaces, richte eine eigene Testdomain mit Logging ein.
  4. Dauerhaft: Wiederhole die Prüfung nach jedem Update von Browser, Antidetect und Bibliotheken. Mach sie zum Ritual, wie die IP-Prüfung.

Ein guter mobiler Proxy gibt dir eine glaubwürdige Adresse und glaubwürdige Resolver des Anbieters. Deine Aufgabe ist, diesen Vorteil nicht auf dem letzten Meter zu verlieren, innerhalb deines eigenen Systems. Richte DNS einmal richtig ein, mach die Prüfung zur Gewohnheit, und eine ganze Kategorie unerklärlicher Sperrungen verschwindet einfach aus deiner Praxis. Hast du dieses Handbuch nicht genau dafür bis zum Ende gelesen?