DNS über Proxy: socks5 vs socks5h, Remote-Resolution und Lecks

Stellen Sie sich folgendes Szenario vor: Sie haben einen Proxy in der gewünschten Region verbunden, die IP-Adresse überprüft – alles stimmt, Stadt und Land passen. Aber die Zielwebseite zeigt Ihnen hartnäckig den falschen Inhalt an, und das Anti-Fraud-System stuft Ihre Sitzung als verdächtig ein. Kommt Ihnen das bekannt vor? Höchstwahrscheinlich sind Sie auf eines der heimtückischsten Phänomene bei der Arbeit mit Proxys gestoßen: DNS-Leck oder den falschen Weg der Domainnamen-Auflösung.

Dieser Artikel ist eine umfassende Anleitung dazu, wie genau die Umwandlung eines Domainnamens in eine IP-Adresse abläuft, wenn der Datenverkehr über einen Proxy läuft. Wir erläutern, worin sich die Schemata socks5 und socks5h grundlegend unterscheiden, wer in welchem Schritt die DNS-Anfrage sendet, warum die Website manchmal eine völlig andere Region sieht als erwartet, und wie Sie die Remote-Resolution in gängigen Clients und Bibliotheken einrichten. Das Thema ist speziell, aber enorm wichtig. An der Namensauflösung scheitern tausende scheinbar korrekt konfigurierte Proxy-Einstellungen.

Einleitung: Warum der Proxy verbunden ist, die Seite aber eine andere Region sieht

Beginnen wir mit dem Symptom, das die meisten Leser zu diesem Thema führt. Sie haben einen Proxy konfiguriert. Die IP-Adresse wird korrekt ersetzt – das lässt sich leicht auf jedem IP-Ermittlungsdienst überprüfen. Und dennoch läuft etwas schief: Die Website liefert die Lokalisierung eines anderen Landes, das CDN leitet Sie zu einem unerwarteten Knoten, und manchmal blockiert das Sicherheitssystem der Zielressource die Anfrage ohne ersichtlichen Grund.

Die Ursache ist fast immer dieselbe. Ihr HTTP- oder Anwendungsdatenverkehr geht zwar durch den Proxy, aber die DNS-Anfrage – genau die Anfrage, die einen Namen wie example.com in eine konkrete IP-Adresse umwandelt – geht am Proxy vorbei, direkt von Ihrem Rechner aus. Und diese Anfrage verrät Sie vollständig.

Warum passiert das? Weil die Namensauflösung und die Datenübertragung zwei verschiedene Phasen sind, die unterschiedliche Wege nehmen können. Viele Clients lösen den Namen standardmäßig lokal auf und senden dann die fertige Verbindung per IP durch den Proxy. Aus Netzwerksicht ist das logisch. Aus Sicht der Privatsphäre und Geolokalisierung ist es eine Katastrophe.

Am Ende dieses Artikels werden Sie verstehen:

• wer genau die Namensauflösung durchführt – das Betriebssystem, die Anwendungsbibliothek, der Browser oder der Proxy-Server selbst;
• wie sich das Schema socks5 von socks5h auf Protokollebene unterscheidet und warum ein Buchstabe alles verändert;
• wie die CONNECT-Methode bei HTTP-Proxys das Auflösungsproblem fast automatisch löst;
• über welche Kanäle DNS selbst bei scheinbar korrekter Konfiguration leckt;
• wie Sie die Remote-Resolution in curl, Python, Node.js, Go, Chrome, Firefox, Selenium und Playwright aktivieren;
• wie Sie den tatsächlichen Pfad der Auflösung mit Tools wie dig, nslookup und tcpdump überprüfen.

Einigen wir uns gleich auf die Grenzen. Wir diskutieren nicht, welcher öffentliche DNS-Server besser ist, und empfehlen keine bestimmten Anbieter. Unser Thema ist ausschließlich der Weg der Auflösung bei der Arbeit über einen Proxy. Nicht mehr und nicht weniger.

Grundlagen: Was ist Namensauflösung und wer führt sie durch?

Um Lecks zu verstehen, müssen wir zunächst die Mechanik der Auflösung genau verinnerlichen. Gehen wir Schritt für Schritt vor.

Was ist Domainnamensauflösung?

Computer kommunizieren über IP-Adressen, Menschen über Namen. Auflösung (vom Englischen resolve – auflösen) ist der Prozess, bei dem ein menschenlesbarer Name wie shop.example.com in eine maschinenlesbare IP-Adresse wie 93.184.216.34 umgewandelt wird. Ohne diesen Schritt ist keine Verbindung möglich: Der Browser weiß nicht, mit welchem Server er sich verbinden soll, bis er die IP erhält.

Die Auflösung ist eine separate Netzwerktransaktion. Üblicherweise verwendet sie das DNS-Protokoll über UDP oder TCP auf Port 53. Der Client sendet eine Anfrage an den Resolver, der Resolver gibt eine Antwort zurück. Der entscheidende Punkt: Wer genau sendet diese Anfrage und auf welchem Weg? – das ist die zentrale Frage unseres gesamten Themas.

Vier mögliche Ausführende der Auflösung

Wenn eine Anwendung eine Verbindung zu example.com herstellen möchte, kann die Auflösung von einem von vier Beteiligten durchgeführt werden. Schauen wir uns jeden an.

1. Das Betriebssystem

Die meisten Anwendungen lösen Namen nicht selbst auf. Sie rufen eine Systemfunktion auf – in der C-Welt ist das getaddrinfo. Das Betriebssystem hat einen eigenen Resolver (Stub-Resolver), der weiß, an welchen DNS-Server er sich wenden muss, einen lokalen Cache führt und die Hosts-Datei berücksichtigt. Das ist der häufigste Weg. Und der gefährlichste im Hinblick auf Lecks: Der System-Resolver geht standardmäßig direkt ins Netz und ignoriert Ihren Proxy.

2. Die Anwendungsbibliothek

Einige Programme und Bibliotheken haben eine eigene Auflösungslogik, die die Aufgabe entweder an das Betriebssystem delegieren, sie selbst durchführen oder – und das ist das Wichtigste – den Namen an den Proxy-Server übergeben, damit die Auflösung auf der entfernten Seite erfolgt. Genau diesen Mechanismus implementieren die Schemata socks5h und Proxy-Hosting.

3. Der Browser

Moderne Browser sind eine eigene Welt. Sie haben ihre eigene Auflösungspolitik, einen eigenen DNS-Cache, Mechanismen wie DoH (DNS over HTTPS), Preloading von Verbindungen und WebRTC. Der Browser kann den Namen völlig unabhängig von den Systemeinstellungen auflösen, was eine ganze Klasse von Lecks hervorbringt.

4. Der Proxy-Server selbst

Das ideale Szenario für die Privatsphäre. Der Client löst den Namen überhaupt nicht auf. Er übergibt dem Proxy-Server eine Zeichenkette mit dem Hostnamen, und der Proxy führt die Auflösung dann selbst auf seiner Seite durch und verbindet sich mit der gewünschten IP. Aus Sicht der Zielseite kommt die DNS-Anfrage aus dem Netzwerk des Proxys, nicht aus Ihrem.

Schlüsselanalogie

Stellen Sie sich vor, Sie schicken einen Kurier (Proxy) mit einem Paket in eine andere Stadt. Es gibt zwei Möglichkeiten. Erstens: Sie ermitteln selbst die genaue Adresse des Empfängers über ein Nachschlagewerk bei sich zu Hause, schreiben die Koordinaten auf das Paket und geben dem Kurier nur die Koordinaten. Das Nachschlagewerk in Ihrer Stadt könnte eine andere Adresse liefern als das in der Zielstadt – und Sie merken es nicht. Zweitens: Sie geben dem Kurier nur den Namen des Empfängers, und er findet die Adresse vor Ort mit dem örtlichen Nachschlagewerk. Die zweite Methode ist die Remote-Resolution. Sie stellt sicher, dass die Adresse vom richtigen Netzwerkpunkt aus ermittelt wird.

socks5 vs. socks5h: Wo wird die Entscheidung über die Auflösung getroffen?

Jetzt kommen wir zum Kern des Themas. Der Unterschied zwischen socks5 und socks5h ist keine Kosmetik und kein Synonym. Es sind grundlegend verschiedene Wege der Auflösung, obwohl das SOCKS5-Protokoll unter der Haube dasselbe ist.

Was sagt das SOCKS5-Protokoll?

Das SOCKS5-Protokoll selbst ist flexibel. Im Befehl zum Verbindungsaufbau gibt der Client den Typ der Zieladresse an. Es gibt drei Möglichkeiten:

• IPv4-Adresse – der Client übergibt eine fertige IP;
• IPv6-Adresse – dasselbe für IPv6;
• Domainname – der Client übergibt eine Zeichenkette mit dem Namen, und dann muss der Proxy-Server die Auflösung durchführen.

Das Protokoll selbst beherrscht also sowohl die lokale als auch die entfernte Auflösung. Es kommt nur darauf an, welchen Adresstyp der Client sendet. Und hier kommt die Namenskonvention der Schemata ins Spiel.

Schema socks5: Lokale Auflösung

Wenn ein Client das Schema socks5 (ohne den Buchstaben h) verwendet, bedeutet das nach allgemeiner Konvention: löse den Namen lokal auf. Der Client fragt zuerst seinen Resolver (normalerweise den System-Resolver) nach der IP von example.com, erhält die Adresse und übergibt dem Proxy-Server dann die fertige IPv4- oder IPv6-Adresse.

Was sieht die Zielseite? Sie sieht eine Verbindung vom Proxy – das ist korrekt. Aber die DNS-Anfrage kam aus Ihrem Netzwerk, von Ihrer Seite, über Ihren lokalen Resolver. Wenn Ihr Resolver geografisch oder logisch an Ihre Region gebunden ist, kann die Zielinfrastruktur über CDN und DNS-Geolokalisierung genau Ihre Region bestimmen, nicht die des Proxys. Daher das Symptom aus der Einleitung.

Schema socks5h: Entfernte Auflösung

Der Buchstabe h in socks5h steht für Hostname – den Namen des Hosts. Dieses Schema sagt dem Client: löse nicht selbst auf, übergib den Namen an den Proxy-Server. Der Client sendet einen Befehl mit dem Adresstyp Domainname, und der Proxy-Server führt die Auflösung auf seiner Seite durch.

Was sieht die Zielseite jetzt? Die DNS-Anfrage kommt von dem Resolver, den der Proxy verwendet, also aus dem Netzwerk des Proxys. Die DNS-Geolokalisierung zeigt auf die Region des Proxys. Ihr lokaler Resolver ist überhaupt nicht beteiligt und weiß nichts darüber, wohin Sie gehen. Dies ist der korrekte, saubere Weg für die meisten Aufgaben.

Vergleichstabelle der Mechanik

Fassen wir die Unterschiede kompakt zusammen:

• socks5: Auflösung durch Client (OS/Bibliothek). Proxy erhält IP. DNS-Anfrage verlässt Ihr Netzwerk. Geografische Diskrepanz und Leck möglich.
• socks5h: Auflösung durch Proxy. Proxy erhält Namen. DNS-Anfrage verlässt das Netzwerk des Proxys. Region konsistent, kein Leck.

Merken Sie sich die einfache Regel: Wenn Privatsphäre und korrekte Geolokalisierung wichtig sind – immer socks5h. Ein Buchstabe spart stundenlanges Debuggen.

Warum gerade diese Konvention?

Ein historischer Hintergrund hilft beim Verständnis. Ursprünglich lösten SOCKS-Clients selbst auf, weil frühe Versionen des Protokolls (SOCKS4) keine Namen übertragen konnten. SOCKS5 fügte die Unterstützung für Domainnamen hinzu, aber die Werkzeug-Ökosphäre führte das Suffix h ein, um das Verhalten explizit zu unterscheiden. So entstand das Paar socks5 / socks5h, das heute von curl, Python und vielen HTTP-Clients verstanden wird. Es ist ein De-facto-Standard der Benennung, nicht Teil einer RFC.

HTTP- und HTTPS-Proxy: Warum die CONNECT-Methode auf dem Proxy auflöst

SOCKS ist nicht der einzige Proxy-Typ. Ein großer Teil der Arbeitsaufgaben verwendet HTTP-Proxys. Und hier ist die Auflösungsmechanik anders, in vielen Fällen sogar besser.

Normale HTTP-Anfrage über einen Proxy

Wenn Sie auf eine HTTP-Ressource (ohne Verschlüsselung) über einen HTTP-Proxy zugreifen, sendet der Client dem Proxy eine vollständige Anfrage mit einer absoluten URL. Die Anfragezeile enthält den Hostnamen. Der Proxy sieht den Namen, löst ihn selbst auf und verbindet sich mit dem Server. Bei normalem HTTP-Proxy-Betrieb erfolgt die Auflösung also natürlicherweise auf der Proxysseite. Der Client muss die IP nicht kennen.

Die CONNECT-Methode für HTTPS

Bei HTTPS wird es interessanter. Den verschlüsselten Datenverkehr kann der Proxy nicht lesen – und soll er auch nicht. Daher wird für HTTPS die spezielle Methode CONNECT verwendet. Der Client sendet dem Proxy einen Befehl wie CONNECT example.com:443. Beachten Sie – hier wird der Hostname übergeben, nicht die IP.

Was passiert als Nächstes? Der Proxy-Server erhält den Namen, löst ihn auf seiner Seite auf, öffnet einen TCP-Tunnel zur Ziel-IP und wird zu einer transparenten Röhre. In dieser Röhre findet dann der vollständige TLS-Handshake zwischen Ihrem Client und dem Zielserver statt – der Proxy entschlüsselt ihn nicht.

Wichtige Erkenntnis: Bei korrekter Implementierung eines HTTP-Proxys mit der CONNECT-Methode ist die Auflösung standardmäßig entfernt. Der Name geht zum Proxy, der Proxy löst selbst auf. Das ist einer der Gründe, warum sich HTTP-Proxys für HTTPS-Datenverkehr oft korrekter aus der Box verhalten als ein falsch konfigurierter SOCKS-Proxy.

Hinweis zur Client-Optimierung

Es gibt eine wichtige Nuance. Manche Clients optimieren die Verbindung, indem sie den Namen trotzdem lokal auflösen, bevor sie CONNECT senden, und dann in CONNECT bereits die IP-Adresse statt des Namens übergeben. Formal ist das zulässig, aber es zerstört den gesamten Vorteil der entfernten Auflösung. Daher sollten Sie auch bei HTTP-Proxys nicht blind auf das Verhalten vertrauen – Sie müssen es überprüfen. Auf die Methoden der Überprüfung gehen wir in einem eigenen Abschnitt ein.

HTTPS-Proxy als separater Begriff

Verwechseln Sie nicht zwei Bedeutungen. Manchmal bedeutet HTTPS-Proxy einen Proxy, der HTTPS-Datenverkehr proxyt (über CONNECT). Und manchmal bedeutet es einen Proxy, zu dem die Verbindung selbst per TLS verschlüsselt ist (d.h. der Kanal Client-Proxy ist geschützt). Das sind verschiedene Dinge. Aus Sicht der Auflösung ist das Erste wichtiger: wie der Zielname übergeben wird. Die Verschlüsselung des Kanals zum Proxy beeinflusst den Pfad der Auflösung nicht direkt, schützt aber den Übertragungsvorgang des Namens vor Beobachtern zwischen Ihnen und dem Proxy.

DNS-Lecks: Mechanismus und typische Szenarien

Kommen wir zum spannendsten Teil – der Anatomie von Lecks. Ein DNS-Leck ist eine Situation, in der die DNS-Anfrage am Proxy vorbei geht und so Ihren echten Resolver, Ihre Region oder die Tatsache, dass Sie eine bestimmte Domain aufgerufen haben, preisgibt. Gehen wir die Szenarien einzeln durch, denn jedes erfordert eine eigene Behandlung.

Szenario 1: System-Resolver umgeht den Proxy

Der häufigste Fall. Sie haben eine Anwendung auf socks5 (ohne h) eingestellt, oder der Client beherrscht keine entfernte Auflösung. Die Anwendung ruft den systemeigenen getaddrinfo auf, das Betriebssystem sendet die DNS-Anfrage direkt an seinen Resolver und umgeht den Proxy. Die Daten gehen später durch den Proxy, aber der Name ist bereits durchgesickert.

Erkennung: Auf dem Proxy kommen Verbindungen per IP an, nicht per Name. Im Netzwerkdump Ihres Rechners sind ausgehende Pakete auf Port 53 zu sehen, die nicht im Proxy-Tunnel verpackt sind.

Behandlung: Wechseln Sie zu socks5h, aktivieren Sie die entfernte Auflösung im Client oder isolieren Sie die Anwendung so, dass sie keinen direkten Netzzugang für DNS hat.

Szenario 2: WebRTC im Browser

WebRTC ist eine Echtzeit-Technologie für Audio, Video und Datenaustausch direkt zwischen Browsern. Für den Verbindungsaufbau verwendet WebRTC den ICE-Mechanismus, der Kandidaten sammelt – unter anderem löst er Hosts von STUN-Servern auf und kann Anfragen initiieren, die am konfigurierten Proxy vorbei gehen. Historisch bekannt dafür, dass WebRTC sogar bei funktionierendem Proxy Ihre echten Adressen preisgab. Obwohl moderne Browser die Politik deutlich verschärft haben, bleibt ein Risiko, wenn die Konfiguration nicht sorgfältig ist.

Behandlung: Kontrollieren Sie die WebRTC-Politik im Browser, deaktivieren oder beschränken Sie die Verarbeitung von ICE-Kandidaten, verwenden Sie Browser-Einstellungen, die den gesamten Datenverkehr einschließlich WebRTC zwingen, über den Proxy zu laufen.

Szenario 3: Eingebautes DoH im Browser

Moderne Browser können DNS over HTTPS – Auflösung über eine verschlüsselte HTTPS-Anfrage an ihren eigenen DoH-Anbieter. Das Problem ist, dass diese Anfrage am Proxy vorbei gehen kann, direkt von Ihrem Rechner, wenn der Browser so eingestellt ist, dass er über sein eigenes DoH auflöst und diesen Datenverkehr nicht in den Proxy einschließt. Das führt zu einem Paradoxon: Der Name wird verschlüsselt und privat gegenüber dem Anbieter aufgelöst, aber gleichzeitig am Proxy vorbei geschickt, was für Geolokalisierungsaufgaben noch schlimmer ist. Diesen Mechanismus werden wir im Abschnitt über DoH detailliert besprechen.

Szenario 4: Paralleler IPv6-Pfad

Das tückischste Szenario. Ihr Proxy arbeitet über IPv4, Sie haben die entfernte Auflösung eingerichtet. Aber Ihr Rechner hat ein funktionierendes IPv6, und der Client versucht gemäß dem Happy Eyeballs-Algorithmus (gleichzeitige Versuche über IPv4 und IPv6), AAAA-Einträge aufzulösen und sich direkt über IPv6 zu verbinden, am Proxy vorbei. Ein Teil des Datenverkehrs und DNS gehen daneben. Die Region driftet auseinander, die Verbindung geht teilweise falsch.

Behandlung: Deaktivieren Sie IPv6 für die proxy-verwendende Anwendung oder stellen Sie sicher, dass der Proxy IPv6 unterstützt und der gesamte Datenverkehr einschließlich AAAA-Auflösung darüber läuft. Für viele Aufgaben ist es einfacher, den Client nur auf IPv4 zu beschränken.

Szenario 5: Cache und Preloading

Browser und Betriebssystem cachen DNS aggressiv und bauen Verbindungen vorab auf (preconnect, prefetch). Wenn der Cache vor dem Einrichten des Proxys gefüllt war, kann die Anwendung alte Einträge oder bereits bestehende Verbindungen nutzen, die die neue Konfiguration umgehen. Eine Kleinigkeit, die beim Debuggen zur Verzweiflung führen kann.

Behandlung: Leeren Sie den DNS-Cache des Betriebssystems und des Browsers, starten Sie neu, deaktivieren Sie während der Diagnose aggressives Preloading.

Allgemeines Muster von Lecks

Haben Sie das gemeinsame Muster bemerkt? Alle Lecks laufen auf eines hinaus: Es gibt einen Kanal, über den der Name oder die Verbindung nicht durch den Proxy geht. Die Aufgabe des Ingenieurs ist es, alle diese Kanäle zu finden und zu schließen. Ein Leck ist immer eine unverschlossene Tür, keine Mystik.

Praxis nach Tools: So aktivieren Sie die Remote-Resolution

Kommen wir zur Sache. Wir gehen die konkreten Clients durch und zeigen, wie Sie die Remote-Resolution aktivieren und die lokale Auflösung verhindern. Dies ist der praktischste Abschnitt – halten Sie ihn griffbereit.

curl: socks5 vs. socks5-hostname

curl ist das Referenzwerkzeug, um den Unterschied zu verstehen. Es bietet eine explizite Auswahl.

• --socks5 host:port – lokale Auflösung. curl ermittelt selbst die IP, geht dann über den Proxy.
• --socks5-hostname host:port – Remote-Resolution. curl übergibt den Namen an den Proxy-Server.

Über die Option --proxy können Sie das Schema ebenfalls steuern: socks5://... ergibt lokale Auflösung, socks5h://... ergibt Remote-Resolution. Beispiel für einen korrekten Aufruf mit Remote-Resolution: curl --proxy socks5h://user:pass@proxyhost:1080 https://example.com. Bei HTTP-Proxys löst das Schema http://... mit der CONNECT-Methode standardmäßig auf dem Proxy auf, aber auch hier sollte das tatsächliche Verhalten überprüft werden.

Python: requests und httpx

Im Python-Ökosystem ist das Schema socks5h der Goldstandard für Remote-Resolution.

Für requests wird ein SOCKS-Unterstützungspaket benötigt. Der Proxy wird als Dictionary angegeben: Verwenden Sie das Schema socks5h://user:pass@host:port für https und http. Das Schema socks5:// ohne h bedeutet lokale Auflösung – genau das ist oft die Ursache für Lecks bei Einsteigern. Ein Buchstabe entscheidet.

Für httpx ist die Logik ähnlich: Übergeben Sie den Proxy mit dem Schema socks5h:// für Remote-Resolution. httpx ist streng bei Schemata und dokumentiert das Verhalten gut, aber das Prinzip ist dasselbe – der Buchstabe h schaltet die Auflösung auf die Proxysseite um.

Wichtige Beobachtung: Auch wenn Sie socks5h angeben, prüfen Sie, ob nicht der System-Proxy aus Umgebungsvariablen (HTTP_PROXY, ALL_PROXY) mit einem anderen Schema greift. Umgebungsvariablen können Ihre Absichten überschreiben.

Node.js

In Node.js gibt es keine direkte SOCKS-Unterstützung im Standard-http. Es werden SOCKS-Agenten verwendet, die die Verbindung über den Proxy herstellen. Der Schlüsselparameter dieser Agenten ist eine Option, die festlegt, ob der Name lokal aufgelöst wird. In gängigen SOCKS-Agenten gibt es ein Flag, das normalerweise lookup oder eine Option für DNS heißt: Wenn der Wert die lokale Lookup-Funktion deaktiviert, wird der Name an den Proxy übergeben. Stellen Sie sicher, dass der Agent so konfiguriert ist, dass er den Hostnamen übergibt und nicht vorab über dns.lookup auflöst.

Praktischer Tipp: Achten Sie in Node besonders darauf, ob irgendwo im Code dns.resolve oder dns.lookup vor dem Verbindungsaufbau aufgerufen wird. Eine solche vorzeitige Auflösung macht den entfernten Pfad zunichte.

Go

In Go bietet die Standardbibliothek ein Paket für die Arbeit mit Proxys. Über golang.org/x/net/proxy können Sie einen SOCKS5-Dialer erstellen. Standardmäßig hängt das Verhalten davon ab, ob Sie im Dial einen Namen oder eine bereits aufgelöste Adresse übergeben. Der Schlüssel liegt darin, den Dialer so zu verwenden, dass der Domainname und nicht das Ergebnis von net.LookupHost hineingeht. Wenn Sie selbst eine Auflösung durchführen und die IP übergeben, handelt es sich um eine lokale Auflösung mit allen Konsequenzen. Der richtige Ansatz: Übergeben Sie dem Dialer die Zeichenkette host:port mit dem Namen und lösen Sie nicht vorher auf.

Chrome: Startflags

Chrome wird über Befehlszeilenflags und Richtlinien gesteuert. Für die Angabe eines Proxys wird das Flag proxy-server verwendet. Entscheidend ist, dass Chrome bei der Arbeit über SOCKS5 standardmäßig lokal auflösen kann. Es gibt ein Flag, das dafür zuständig ist, dass die Auflösung für proxy-verwendende Verbindungen auf der Proxysseite erfolgt – sein Name hängt mit host-resolver-rules und einer Einstellung zusammen, die alle Hosts zwingt, über den Proxy zu gehen. Wichtig ist auch die Kontrolle des eingebauten DoH: Wenn Secure DNS im Browser aktiviert und auf einen eigenen Anbieter eingestellt ist, kann es Ihr Schema umgehen. Für die Diagnose wird Secure DNS vorübergehend deaktiviert und die WebRTC-Politik verschärft.

Firefox: Einstellungen in about:config

Firefox ist historisch bequemer für die Kontrolle der Auflösung. Die Schlüsseleinstellung ist network.proxy.socks_remote_dns. Setzen Sie sie auf true, und Firefox sendet die Hostnamen an den SOCKS-Proxy zur entfernten Auflösung anstatt lokal. Dies ist eine der wichtigsten Einstellungen im gesamten Artikel. Kontrollieren Sie zusätzlich:

• network.trr.mode – der Modus für DoH (TRR, Trusted Recursive Resolver). Ein Wert, der die erzwungene DoH-Nutzung deaktiviert, ist wichtig, wenn die Auflösung nur über den Proxy erfolgen soll.
• media.peerconnection.enabled – Steuerung von WebRTC, um Lecks über ICE auszuschließen.
• Einstellungen zum Deaktivieren von IPv6 oder Preloading, falls ein paralleler Pfad beobachtet wird.

Selenium

Selenium steuert einen echten Browser, daher erbt es die Auflösungslogik von Chrome oder Firefox. Für Chrome übergeben Sie dieselben Flags über die Startoptionen (Argumente proxy-server und die mit der Auflösung verbundenen). Für Firefox erstellen Sie ein Profil mit aktiviertem network.proxy.socks_remote_dns über das Profilkonfigurationsobjekt. Das Erfolgsgeheimnis: Verlassen Sie sich nicht auf die Standardwerte des Treibers – geben Sie die Remote-Resolution explizit im Profil oder in den Flags an und überprüfen Sie anschließend den tatsächlichen Pfad.

Playwright

Playwright bietet den Parameter proxy beim Start eines Kontexts oder Browsers. Sie geben server mit einem Schema an (z. B. socks5://host:port) und die Zugangsdaten. Hier gibt es eine Feinheit: Das Auflösungsverhalten hängt von der Engine (Chromium, Firefox, WebKit) und davon ab, wie das Proxying implementiert ist. Um eine Remote-Resolution in der Chromium-Engine zu gewährleisten, kombinieren Sie die Proxy-Einstellung mit entsprechenden Startargumenten, in der Firefox-Engine mit der Profileinstellung socks_remote_dns. Schließen Sie die Konfiguration immer mit einer Überprüfung auf Lecks ab.

Übersichtstabelle: Client, wie man Remote-Resolution aktiviert, wie man prüft

Hier ist die wichtigste Praxistabelle des Artikels:

• curl – aktivieren: --socks5-hostname oder Schema socks5h:// in --proxy verwenden – prüfen: curl mit verbose und Beobachtung, ob der Name übergeben wird; Traffic-Dump auf fehlende direkte Anfragen auf Port 53.
• Python requests – aktivieren: Schema socks5h:// im proxies-Dictionary – prüfen: Anfrage an einen Dienst, der die Quelle der Auflösung anzeigt; Kontrolle der Umgebungsvariablen.
• Python httpx – aktivieren: Proxy mit Schema socks5h:// – prüfen: Lecktest, Analyse, welcher Resolver sichtbar ist.
• Node.js – aktivieren: SOCKS-Agent mit hostname-Übergabe, ohne vorheriges dns.lookup – prüfen: Fehlen von dns.resolve-Aufrufen vor der Verbindung; Dump auf Port 53.
• Go – aktivieren: SOCKS5-Dialer, Übergabe von host:port mit Namen, ohne vorheriges net.LookupHost – prüfen: Protokollierung dessen, was in den Dialer geht; tcpdump.
• Chrome – aktivieren: proxy-server mit SOCKS5, host-resolver-rules auf Proxy, Secure DNS für Diagnose deaktivieren – prüfen: Online-Lecktest, Vergleich von IP-Region und DNS-Region.
• Firefox – aktivieren: network.proxy.socks_remote_dns auf true, Kontrolle von network.trr.mode – prüfen: about:networking, Online-Lecktest.
• Selenium – aktivieren: dieselben Chrome-Flags oder Firefox-Profil mit socks_remote_dns – prüfen: Ausführung eines Lecktests im gesteuerten Browser.
• Playwright – aktivieren: Proxy-Parameter plus Engine-Argumente für Remote-Resolution – prüfen: Aufruf eines Lecktests in der automatisierten Sitzung.

DoH und DoT: Wie sie mit dem Proxy interagieren

DNS over HTTPS (DoH) und DNS over TLS (DoT) verschlüsseln DNS-Anfragen. Sie sind an sich hervorragend, um den Inhalt der Anfrage vor dem Beobachter zu schützen. Aber im Kontext eines Proxys erzeugen sie subtile Effekte, die Sie verstehen müssen.

Was sind DoH und DoT in Kürze?

DoT wickelt DNS in TLS auf einem dedizierten Port ein. DoH versteckt die DNS-Anfrage in normalem HTTPS-Datenverkehr, sodass sie nicht von normalem Websurfen zu unterscheiden ist. Beide Protokolle verschlüsseln die Anfrage. Aber – und das ist entscheidend – die Verschlüsselung der Anfrage ist nicht gleichbedeutend mit der Routenführung über den Proxy. Das sind verschiedene Dimensionen.

Der Hauptkonflikt: Browser-DoH am Proxy vorbei

Hier ist die wichtigste Erkenntnis des Abschnitts. Wenn der Browser sein eigenes DoH aktiviert und so eingestellt ist, dass er über seinen eigenen Anbieter auflöst, baut er eine HTTPS-Verbindung zum DoH-Endpunkt auf. Frage: Läuft diese Verbindung über Ihren Proxy? Oft nicht. Der Browser kann den DoH-Kanal direkt öffnen, weil die Auflösung als Dienstoperation betrachtet wird, getrennt von der Benutzernavigation.

Das Ergebnis ist paradox. Einerseits ist die DNS-Anfrage verschlüsselt und der Anbieter sieht nicht, welche Domain Sie anfragen. Andererseits geht diese Anfrage von Ihrem echten Rechner aus, in Ihrem Netzwerk, am Proxy vorbei. Für Geolokalisierung ist das ein Fehlschlag: Die Zielinfrastruktur sieht die Auflösung aus Ihrer Region, nicht aus der des Proxys. Ihre schön eingerichtete socks5h-Konfiguration wird umgangen, weil der Browser für die Auflösung gar nicht über SOCKS gegangen ist – er hat seinen eigenen DoH-Weg genommen.

Wann browserbasiertes DoH Ihr Schema vollständig zerstört

Konkretisieren wir Situationen, in denen DoH den Proxy umgeht:

• Der Browser ist auf erzwungenes DoH über seinen eigenen Anbieter eingestellt, und der Proxy ist nur für den normalen Datenverkehr konfiguriert, nicht für die Dienstauflösung;
• Das Betriebssystem oder die Anwendung hat DoH auf Betriebssystemebene aktiviert, und es wird nicht in den Tunnel eingeschlossen;
• Der DoH-Endpunkt ist zwischengespeichert und die Verbindung zu ihm wurde vor dem Anwenden der Proxy-Einstellungen hergestellt.

Praktische Schlussfolgerung: Für Aufgaben, bei denen die Konsistenz der Region wichtig ist, müssen Sie das browser- und systemeigene DoH entweder deaktivieren oder explizit durch denselben Proxy leiten. Das ideale Bild ist, dass die gesamte Auflösung, ob verschlüsselt oder nicht, über den Proxy-Server (Remote-Resolution) und nicht an ihm vorbei erfolgt.

DoT und der Proxy

DoT arbeitet auf einem dedizierten Port und ist leichter durch Netzwerkrichtlinien zu kontrollieren, kann aber ebenfalls am Proxy vorbei gehen, wenn es nicht explizit eingeschlossen wird. Für unsere Zwecke gilt dasselbe Prinzip: Kontrollieren Sie, dass die Auflösung über den Proxy und nicht über einen unabhängigen Kanal erfolgt.

Goldene Regel für DoH im Proxy-Kontext

Merken Sie sich: Die Verschlüsselung der Auflösung und ihre Routenführung über den Proxy sind unabhängige Eigenschaften. Sie können eine verschlüsselte Auflösung haben, die dennoch Ihre Region vollständig preisgibt, weil sie am Proxy vorbei geht. Für Konsistenz sollten Sie immer die Remote-Resolution auf dem Proxy anstreben und die Frage der Verschlüsselung separat und bewusst entscheiden.

Wie man prüft: dig, nslookup, tcpdump und Online-Tests

Einrichten ist die eine Hälfte. Ein Ingenieur muss überprüfen, ob die Auflösung tatsächlich wie geplant erfolgt. Gehen wir die Diagnosewerkzeuge von einfach bis ernsthaft durch.

dig und nslookup über den Proxy

dig und nslookup sind klassische Werkzeuge für die manuelle Auflösung. Die Besonderheit ist, dass normales DNS über UDP läuft, während SOCKS-Proxys nativ TCP proxyt. Daher erfordert die Überprüfung der Auflösung über einen Proxy, dass die DNS-Anfrage über TCP läuft und das Tool durch einen SOCKS-Wrapper geleitet wird. In der Praxis ist es bequemer, Werkzeuge durch Programme zu wrappen, die TCP-Datenverkehr in SOCKS einwickeln. Der Sinn der Überprüfung: Sicherstellen, dass Ihr lokaler Rechner bei Remote-Resolution keine DNS-Anfragen selbst sendet, sondern nur das über den Proxy-Kanal ankommende Ergebnis sieht.

nslookup ist nützlich für eine schnelle Prüfung, welcher Resolver antwortet und welche IP zurückgegeben wird. Vergleichen Sie die lokal erhaltene IP mit der IP, zu der die Verbindung tatsächlich über den Proxy hergestellt wird. Eine Abweichung ist ein Indikator dafür, dass die Auflösung unterschiedliche Wege nimmt.

tcpdump auf Port 53 – der ehrlichste Test

Dies ist meine Lieblingsmethode, weil sie nicht lügt. Starten Sie auf Ihrem Rechner einen Traffic-Capture mit Filter auf Port 53 (und auf Port 443 für DoH-Verdacht). Führen Sie dann eine proxy-verwendende Anfrage aus. Die Logik ist einfach:

• Wenn Sie bei Remote-Resolution ausgehende DNS-Pakete auf Port 53 direkt von Ihrem Rechner sehen – haben Sie ein Leck, die Auflösung erfolgt lokal;
• Wenn Port 53 schweigt und der gesamte Traffic in den Proxy-Tunnel geht – funktioniert die Remote-Resolution korrekt;
• Wenn Port 53 schweigt, aber verdächtige HTTPS-Verbindungen zu bekannten DoH-Endpunkten am Proxy vorbei gehen – haben Sie ein Leck über DoH.

tcpdump zeigt die physische Netzwerkrealtität, nicht die Deklarationen der Konfigurationen. Deshalb ist es bei der finalen Verifikation unverzichtbar.

Online-Lecktest: So lesen Sie das Ergebnis richtig

Es gibt Webdienste, die anzeigen, welcher Resolver Ihre DNS-Anfrage durchgeführt hat und aus welcher Region er stammt. Der Schlüssel zum korrekten Lesen des Ergebnisses ist, zwei Parameter nicht zu verwechseln:

• Ihre sichtbare IP – das ist die IP, von der die HTTP-Verbindung kommt, also die IP des Proxys;
• Der DNS-Resolver – das ist die Adresse und Region dessen, der die Auflösung tatsächlich durchgeführt hat.

Das korrekte Bild bei Remote-Resolution: Sowohl die sichtbare IP als auch der Resolver zeigen auf die Region des Proxys. Ein alarmierendes Zeichen: Die sichtbare IP ist die Region des Proxys, aber der Resolver ist Ihre echte Region. Das ist ein klassisches Leck durch lokale Auflösung. Eine weitere Variante eines Lecks: Der Resolver gehört einem großen DoH-Anbieter, aber die Verbindung zu ihm ging am Proxy vorbei – dann kann die Region des Resolvers neutral sein, aber der Weg selbst geht trotzdem nicht durch den Proxy, was bereits mit tcpdump sichtbar ist.

Checkliste zur Verifikation der Auflösung

Gehen Sie die Punkte nacheinander durch:

1. Leeren Sie den DNS-Cache des Betriebssystems und des Browsers, starten Sie die Anwendung neu.
2. Stellen Sie sicher, dass das Schema socks5h ist oder die Remote-Resolution im Client aktiviert ist.
3. Überprüfen Sie die Umgebungsvariablen des Proxys auf widersprüchliche Schemata.
4. Starten Sie tcpdump mit Filter auf Port 53 und 443.
5. Führen Sie eine proxy-verwendende Anfrage an eine Testressource durch.
6. Stellen Sie sicher, dass keine direkten DNS-Pakete auf Port 53 vorhanden sind.
7. Überprüfen Sie das Fehlen unabhängiger HTTPS-Verbindungen zu DoH-Endpunkten.
8. Öffnen Sie einen Online-Lecktest und vergleichen Sie die IP-Region mit der Resolver-Region.
9. Überprüfen Sie den IPv6-Pfad: Gibt es parallele AAAA-Anfragen und -Verbindungen?
10. Dokumentieren Sie die Referenzkonfiguration in der Teamdokumentation.

Typische Fehler, die fast alle machen

In jahrelanger Arbeit mit Proxys hat sich eine Sammlung von Fallstricken angesammelt. Gehen wir die häufigsten durch, damit Sie nicht hineintappen.

Fehler 1: socks5 und socks5h verwechseln

Der absolute Spitzenreiter. Jemand schreibt socks5:// und ist überzeugt, dass die Auflösung entfernt erfolgt. Dabei ist sie lokal. Ein fehlender Buchstabe h – und schon driftet die gesamte Region ab. Geben Sie immer explizit socks5h an, wenn Sie Remote-Resolution benötigen, und überprüfen Sie es mit einem Dump.

Fehler 2: Proxy eingerichtet, aber DoH vergessen

Ein Klassiker für Browser. Der Proxy ist gesetzt, aber das eingebaute Secure DNS / DoH ist aktiv und geht am Proxy vorbei. Der Benutzer sieht die korrekte IP und beruhigt sich, während die Auflösung leckt. Synchronisieren Sie immer die DoH-Politik mit dem Proxy.

Fehler 3: IPv6 ignorieren

Proxy auf IPv4, aber der Rechner lebt im Dual-Stack. Happy Eyeballs tut sein Werk, und ein Teil der Verbindungen geht direkt über IPv6. Entweder deaktivieren Sie IPv6 für die Anwendung oder stellen Sie sicher, dass der Proxy IPv6 vollständig bedient.

Fehler 4: Vorherige lokale Auflösung im Code

Ein häufiges Problem in Node.js und Go. Der Entwickler ruft in bester Absicht eine Auflösung vorher auf (zur Überprüfung, zur Protokollierung) und übergibt dem Proxy dann die IP. Remote-Resolution ist tot. Lösen Sie den Namen erst gar nicht vor der Übergabe an den Proxy-Dialer auf.

Fehler 5: Umgebungsvariablen vertrauen

HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY – stille Saboteure. Sie überschreiben die Einstellungen im Code oder geraten mit dem Schema in Konflikt. Überprüfen Sie die Umgebung vor dem Start und bereinigen Sie Überflüssiges.

Fehler 6: Der Konfiguration glauben statt zu prüfen

Eine korrekte Zeile geschrieben und weitergemacht. Aber die Konfiguration ist eine Absicht, keine Tatsache. Das tatsächliche Verhalten wird nur durch einen Traffic-Dump und einen Lecktest überprüft. Schließen Sie die Einrichtung nie ohne Verifikation ab.

Fehler 7: Vergessener DNS-Cache

Sie ändern die Konfiguration, aber das Ergebnis bleibt gleich – weil alte Einträge und Verbindungen zwischengespeichert sind. Leeren Sie immer den Cache und starten Sie vor der Überprüfung neu.

Fehler 8: Proxy-Typen in einer Pipeline mischen

An einer Stelle HTTP-Proxy mit CONNECT, an einer anderen SOCKS mit lokaler Auflösung. Das Auflösungsverhalten unterscheidet sich, und ein Teil der Anfragen leckt. Vereinheitlichen Sie den Ansatz über die gesamte Pipeline.

Fehler 9: Den Anwendungscache nicht berücksichtigen

Einige Anwendungen führen einen eigenen DNS-Cache und einen Verbindungspool, die einen Konfigurationswechsel überdauern. Ein Neustart des Prozesses ist manchmal zwingend erforderlich.

Fehler 10: WebRTC in der Automatisierung ignorieren

Bei der Browser-Automation wird WebRTC oft vergessen. Ein gesteuerter Browser initiiert munter ICE und legt Pfade am Proxy vorbei offen. Kontrollieren Sie immer die WebRTC-Politik in automatisierten Sitzungen.

Werkzeuge und Ressourcen für die Arbeit mit der Auflösung über einen Proxy

Sammeln wir das Arsenal, das Sie griffbereit halten sollten. Unterteilt nach Zweck.

Diagnosewerkzeuge

• tcpdump – Netzwerk-Traffic-Capture, der oberste Richter über die Pfade der Auflösung.
• Wireshark – grafische Paketanalyse, praktisch für komplexe Fälle mit DoH und IPv6.
• dig und nslookup – manuelle Auflösung, schnelle Überprüfung der Resolver-Antworten.
• Online-DNS-Lecktests – zeigen den Resolver und seine Region, geben ein schnelles Urteil.
• about:networking in Firefox – eingebaute Diagnose der Verbindungen und des DNS des Browsers.

Werkzeuge und Bibliotheken zur Konfiguration

• curl – Referenz für das Verhalten von socks5 und socks5-hostname, ideal zum Debuggen.
• SOCKS-Wrapper für TCP-Traffic – ermöglichen es, eine beliebige Anwendung für Tests der Auflösung in SOCKS zu verpacken.
• SOCKS-Bibliotheken für Sprachen – SOCKS-Unterstützungspakete in Python, SOCKS-Agenten in Node.js, Proxy-Paket in Go.
• Browser-Automatisierungstools – Selenium und Playwright mit expliziter Proxy- und Auflösungskonfiguration.

Wissensressourcen

• offizielle curl-Dokumentation zu Proxy-Optionen – die beste Primärquelle zur Semantik von socks5 vs. socks5h;
• Dokumentation der Python-HTTP-Clients zur Arbeit mit Proxys und Schemata;
• about:config-Nachschlagewerke für Firefox zu Netzwerk- und Auflösungsparametern;
• Dokumentation Ihres gewählten Proxy-Anbieters, insbesondere des Dienstes MobileProxy.space, in dem unterstützte Schemata und Empfehlungen zur Remote-Resolution für mobile Proxys beschrieben sind.

Mini-Entscheidungsrahmen für die Methodenauswahl

Um nicht den Überblick zu verlieren, halten Sie sich an diese einfache Entscheidungslogik:

1. Benötigen Sie HTTPS-Datenverkehr und Remote-Resolution? HTTP-Proxy mit CONNECT oder SOCKS5 mit Schema socks5h.
2. Arbeiten Sie aus einer Bibliothek oder CLI? Geben Sie explizit socks5h oder das Flag für Remote-Resolution an.
3. Arbeiten Sie aus einem Browser? Aktivieren Sie Remote-Resolution, deaktivieren Sie DoH oder leiten Sie es über den Proxy, schränken Sie WebRTC und IPv6 ein.
4. Schließen Sie die Konfiguration immer mit einem Traffic-Dump und einem Online-Test ab.

Fälle und Ergebnisse: Wie es in der Praxis aussieht

Theorie ohne Praxis ist tot. Besprechen wir verallgemeinerte Fälle, die typische Situationen widerspiegeln. Die Zahlen sind beispielhaft, aber die Proportionen und die Logik stammen aus echter Ingenieurspraxis.

Fall 1: Regionale Diskrepanz bei einem Datenanalysten

Ein Team sammelte Daten über ein Python-Skript mit einem Proxy in der gewünschten Region. Die Ergebnisse kamen in etwa vierzig Prozent der Fälle mit der Lokalisierung eines anderen Landes. Die Diagnose ergab das Schema socks5:// im proxies-Dictionary – lokale Auflösung. Der Austausch gegen socks5h:// beseitigte die Diskrepanz vollständig. tcpdump bestätigte: Die direkten Anfragen auf Port 53 verschwanden. Lektion: Ein Buchstabe löste ein Problem, für das zuvor zwei Tage aufgewendet wurden.

Fall 2: Leck durch browserbasiertes DoH in der Automatisierung

Bei der Automatisierung von Chromium über Playwright war die IP-Region korrekt, aber die Zielressource bestimmte hartnäckig eine andere Region. Ein Online-Lecktest zeigte einen Resolver, der nicht mit der Proxy-Region übereinstimmte. Wireshark deckte unabhängige HTTPS-Verbindungen zu einem DoH-Endpunkt auf, die den Proxy umgingen. Lösung: Deaktivierung von Secure DNS in der Startkonfiguration und erzwungene Remote-Resolution. Nach der Korrektur stimmte die Region des Resolvers mit der IP-Region überein, Fehlalarme des Anti-Frauds sanken drastisch.

Fall 3: Paralleles IPv6 in einem Mikroservice

Ein Go-Dienst arbeitete über SOCKS5, aber ein Teil der Anfragen ging zeitweise direkt. Ursache: Dual-Stack und Versuche über IPv6 am Proxy vorbei. Die Beschränkung des Clients auf nur IPv4 und die korrekte Übergabe des Namens im Dialer beseitigten das Leck. tcpdump zeigte keine direkten AAAA-Anfragen mehr. Die Regionsstabilität stieg auf nahezu hundert Prozent.

Fall 4: Umgebungsvariablen als Saboteure

Ein Skript verhielt sich auf zwei Rechnern bei identischem Code unterschiedlich. Auf dem einen funktionierte die Remote-Resolution, auf dem anderen nicht. Die Lösung: Auf dem problematischen Rechner war die Variable ALL_PROXY mit einem Schema ohne h gesetzt, das die Einstellungen überschrieb. Nach der Bereinigung der Umgebung war das Verhalten konsistent. Lektion: Die Umgebung ist Teil der Konfiguration und muss ebenso streng kontrolliert werden wie der Code.

Allgemeine Schlussfolgerung aus den Fällen

Beachten Sie das Muster. In allen Fällen war das Symptom ähnlich – falsche Region oder ausgelöste Schutzmechanismen –, aber die Ursachen waren unterschiedlich: Schema, DoH, IPv6, Umgebung. Deshalb ist die Diagnose nach Checkliste wichtiger als Intuition. Ein systematischer Ansatz findet die Wurzel schneller als Rätselraten.

FAQ: Häufig gestellte Fragen

Was ist der Unterschied zwischen socks5 und socks5h in einfachen Worten?

socks5 löst den Domainnamen auf Ihrer Seite auf und sendet dem Proxy die fertige IP. socks5h sendet dem Proxy den Namen selbst, und die Auflösung führt der Proxy durch. Für Privatsphäre und korrekte Geolokalisierung wird fast immer socks5h benötigt. Der Buchstabe h steht für hostname – der Hostname wird entfernt übergeben.

Wenn ich einen HTTP-Proxy verwende, muss ich mir dann Gedanken um die Auflösung machen?

Bei HTTPS über die CONNECT-Methode geht der Name normalerweise zum Proxy, und er löst selbst auf – das ist gut. Aber manche Clients lösen vorher lokal auf und übergeben in CONNECT bereits die IP. Daher sollten Sie auch bei HTTP-Proxys das tatsächliche Verhalten mit einem Traffic-Dump überprüfen.

Warum ist die IP korrekt, aber die Website sieht eine andere Region?

Mit hoher Wahrscheinlichkeit geht Ihre DNS-Anfrage am Proxy vorbei – über den lokalen Resolver oder browserbasiertes DoH. Die Zielinfrastruktur bestimmt über DNS-Geolokalisierung und CDN die Region Ihres Resolvers, nicht die des Proxys. Behandlung: Remote-Resolution und Kontrolle von DoH.

Wie hängt WebRTC mit der Auflösung und Lecks zusammen?

WebRTC sammelt für den Verbindungsaufbau Netzwerkkandidaten und kann Anfragen initiieren, die am Proxy vorbei gehen. Das kann Pfade und Adressen offenlegen. Bei der Arbeit über einen Proxy, insbesondere in der Browser-Automation, muss die WebRTC-Politik kontrolliert oder eingeschränkt werden.

Stört DoH meine Proxy-Konfiguration?

Es kann stören. Die Verschlüsselung der Auflösung und ihre Routenführung über den Proxy sind verschiedene Dinge. Browser- oder systemeigenes DoH kann direkt am Proxy vorbei gehen und Ihre Region preisgeben. Für Konsistenz deaktivieren Sie solches DoH oder leiten Sie die Auflösung über den Proxy.

Wie kann ich schnell prüfen, ob ein Leck vorliegt?

Zwei Schritte. Erstens: Starten Sie tcpdump mit Filter auf Port 53 und führen Sie eine proxy-verwendende Anfrage aus: Direkte DNS-Pakete bedeuten ein Leck. Zweitens: Öffnen Sie einen Online-Lecktest und vergleichen Sie die Region der sichtbaren IP mit der Region des Resolvers. Stimmen sie überein – gut, weichen sie ab – Leck.

Was mache ich mit IPv6, wenn der Proxy nur IPv4 hat?

Entweder deaktivieren Sie IPv6 für die proxy-verwendende Anwendung oder stellen Sie sicher, dass der Proxy IPv6 bedient und der gesamte Datenverkehr einschließlich AAAA-Auflösung darüber läuft. Andernfalls schickt der Happy Eyeballs-Algorithmus einen Teil der Verbindungen direkt am Proxy vorbei.

Warum verhält sich derselbe Code auf zwei Rechnern unterschiedlich?

Häufige Ursache sind Umgebungsvariablen für Proxys (HTTP_PROXY, ALL_PROXY und ähnliche). Sie überschreiben die Einstellungen im Code oder geben ein anderes Schema vor. Überprüfen und bereinigen Sie die Umgebung, um konsistentes Verhalten zu erreichen.

Reicht es aus, socks5h anzugeben, um Lecks sicher zu vermeiden?

Für die Anwendung selbst ist das ein großer Schritt nach vorne, aber keine Garantie für das gesamte System. Es bleiben Kanäle wie browserbasiertes DoH, WebRTC und IPv6. Vollständiger Schutz bedeutet Remote-Resolution plus Kontrolle aller Umgehungskanäle plus zwingende Überprüfung mit einem Dump.

Kann ich die Auflösung über den Proxy in der Befehlszeile zum Testen durchführen?

Ja. curl mit der Option --socks5-hostname oder dem Schema socks5h ist der einfachste Weg, Remote-Resolution zu testen. Für Werkzeuge wie dig ist es praktisch, TCP-Datenverkehr in SOCKS zu wrappen, wobei zu beachten ist, dass klassisches DNS über UDP nativ nicht über SOCKS proxyt wird.

Fazit: Zusammenfassung und nächste Schritte

Wir haben den Weg vom Symptom zum tiefen Verständnis zurückgelegt. Fassen wir das Wichtigste in einem kompakten Sinnrahmen zusammen, der bei Ihnen bleibt.

Die Auflösung eines Domainnamens ist eine separate Netzwerktransaktion, die einen anderen Weg nehmen kann als Ihr Hauptdatenverkehr. Genau diese Unabhängigkeit verursacht die meisten Probleme. Vier Beteiligte können die Auflösung durchführen: das Betriebssystem, die Anwendungsbibliothek, der Browser und der Proxy selbst. Ihr Ziel ist es fast immer, die Auflösung an den Proxy-Server zu delegieren, damit der Name vom richtigen Netzwerkpunkt aus bestimmt wird.

Der Unterschied zwischen socks5 und socks5h ist grundlegend. socks5 – lokale Auflösung, socks5h – entfernte Auflösung. Ein Buchstabe verändert alles: Region, Privatsphäre, Konsistenz. HTTP-Proxys mit der CONNECT-Methode übergeben den Namen von Natur aus an den Proxy, aber auch hier sollten Sie nicht blind vertrauen – prüfen Sie.

Lecks laufen auf ein Prinzip hinaus: Es gibt einen Kanal, über den der Name nicht durch den Proxy geht. System-Resolver, WebRTC, browserbasiertes DoH, paralleles IPv6, Cache – das sind die Hauptverdächtigen. Und denken Sie an die wichtigste Erkenntnis: Die Verschlüsselung der Auflösung ist nicht gleichbedeutend mit ihrer Routenführung über den Proxy. Sie können eine verschlüsselte DoH-Auflösung haben, die dennoch Ihre Region vollständig preisgibt.

Was sollten Sie jetzt tun? Hier ist Ihr Aktionsplan:

1. Gehen Sie Ihre aktuellen Konfigurationen durch und ersetzen Sie socks5 durch socks5h, wo Remote-Resolution benötigt wird.
2. Überprüfen Sie die Browser: Aktivieren Sie Remote-Resolution, klären Sie die DoH- und WebRTC-Politik.
3. Stellen Sie sicher, dass IPv6 keinen parallelen Weg am Proxy vorbei erzeugt.
4. Bereinigen Sie die Umgebungsvariablen des Proxys von widersprüchlichen Werten.
5. Führen Sie eine Verifikation mit tcpdump und einem Online-Test gemäß der Checkliste aus dem Artikel durch.
6. Dokumentieren Sie die Referenzkonfiguration im Team, damit das Rad nicht neu erfunden wird.

Das Thema der Auflösung über Proxy scheint speziell, aber genau daran scheitern die teuersten und ärgerlichsten Konfigurationen. Jetzt haben Sie eine Landkarte: Sie verstehen, wer auflöst, wo die Entscheidung getroffen wird, wie Lecks entstehen und wie Sie sie schließen. Heben Sie diesen Artikel in Ihren Lesezeichen und kehren Sie zur Tabelle und den Checklisten zurück, wann immer der Proxy verbunden ist, die Website aber stur die falsche Region sieht. Jetzt wissen Sie, wo Sie suchen müssen.