Sie konfigurieren einen Proxy an einem deutschen Exit, führen Ihre Sammlung durch, und das Ziel liefert Ihnen weiterhin Inhalte für die falsche Region. Die Exit-Adresse erweist sich als deutsch, die Anfragen sind erfolgreich, und trotzdem sehen die Ergebnisse so aus, als kämen sie von dort, wo Ihr Server tatsächlich steht. Eine häufige Ursache ist, dass die Verbindung über den Proxy lief, die Namensauflösung jedoch nicht.
Dies ist ein DNS-Leak. Im Datenschutzkontext wird beschrieben, dass Ihr Resolver sieht, welche Domains Sie besuchen, und das ist real, aber für die Datensammlung gibt es eine unmittelbarere Konsequenz: DNS-Auflösung ist oft geografisch bewusst, sodass lokale Auflösung bei entferntem Exit eine Diskrepanz erzeugt, die Ihnen den falschen regionalen Endpunkt liefern und einen geo-zielgerichteten Datensatz still und leise verfälschen kann.
Was tatsächlich leakt, und warum das hier wichtig ist
Eine Anfrage an einen Hostnamen umfasst zwei Schritte: den Namen in eine Adresse umwandeln, dann eine Verbindung zu dieser Adresse herstellen. Ein Proxy fängt den zweiten Schritt ab. Ob er auch den ersten abfängt, hängt vollständig von Ihrem Client ab.
Wenn der Client lokal auflöst, geht die DNS-Anfrage von Ihrem eigenen Netzwerk zu Ihrem eigenen Resolver aus, wodurch die Domain gegenüber Ihrem ISP oder Resolver-Betreiber offengelegt wird, und liefert eine Antwort zurück, die für Ihren Standort berechnet wurde.
Genau dieser letzte Teil ist es, der die Sammlung zerstört. Große Websites stehen hinter CDNs und geo-bewusstem DNS, die je nach Herkunft der Anfrage unterschiedliche Adressen zurückgeben, sodass eine lokal aufgelöste Abfrage auf einen Edge-Knoten in der Nähe Ihres Servers zeigen kann statt in der Nähe Ihres Proxy-Exits. Sie verbinden sich dann über eine deutsche Adresse mit diesem Knoten, und die Diskrepanz kann Inhalte für die falsche Region, inkonsistente Ergebnisse zwischen Durchläufen oder ein Signal erzeugen, das dem Ziel ungewöhnlich erscheint. Wenn Ihre Arbeit von City-Level-Targeting abhängt, lohnt es sich, diesen Fehlerfall als Erstes auszuschließen, wenn die Geografie falsch erscheint, neben den Unterschieden in Geolocation-Datenbanken, die die andere häufige Ursache sind.
HTTP-Proxys leaken selten, SOCKS5 oft
Das Verhalten unterscheidet sich je nach Protokoll, und das ist der Kern des Problems.
Bei einem HTTP-Proxy verwendet eine HTTPS-Anfrage CONNECT und sendet den Hostnamen an den Proxy, der ihn remote auflöst. Einfaches HTTP sendet ebenso eine absolute URL, die den Hostnamen enthält. In beiden Fällen führt der Proxy die Auflösung konstruktionsbedingt durch, sodass gewöhnliche HTTP-Proxy-Nutzung kein DNS leakt.
Bei SOCKS5 unterstützt das Protokoll beides. Es kann einen Hostnamen akzeptieren und remote auflösen, oder eine Adresse akzeptieren, die der Client selbst aufgelöst hat. Was davon geschieht, ist eine Entscheidung des Clients, und viele Clients lösen standardmäßig lokal auf. Deshalb leakt dasselbe Gateway bei einer Konfiguration und bei einer anderen nicht, und es ist fast immer eine clientseitige Einstellung und hat nichts mit dem Proxy zu tun.
In den meisten Tools ist der Unterschied ein einziges Zeichen. socks5:// bedeutet lokale Auflösung, socks5h:// bedeutet, den Hostnamen an den Proxy zu übergeben. Das h ist die gesamte Lösung.
Behebung nach Client
curl. Verwenden Sie das Schema socks5h, oder --proxy mit diesem Schema, statt socks5:
# leakt: löst lokal auf
curl -x socks5://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://example.com
# korrekt: Hostname wird beim Proxy aufgelöst
curl -x socks5h://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://example.comPython. Mit requests und PySocks trägt das Schema dieselbe Bedeutung, und es ist leicht, es falsch zu machen, da beide Schreibweisen funktionieren:
import requests
user = "customer-USERNAME-country-de"
PROXY = f"socks5h://{user}:PASSWORD@p.shifter.io:443" # beachten Sie das h
r = requests.get("https://example.com",
proxies={"http": PROXY, "https": PROXY}, timeout=20)Am einfachsten ist es, das HTTP-Schema gegen dasselbe Gateway zu verwenden, das standardmäßig remote auflöst und die Frage vollständig vermeidet. Das ist die Konfiguration in Verwendung von Residential Proxies mit Python.
Node. Socks-Agents bieten typischerweise ein Flag für remote Auflösung; prüfen Sie, ob es aktiviert ist, statt es anzunehmen, da sich die Standardwerte zwischen Bibliotheken und Versionen unterscheiden.
Headless-Browser. Hier sind Leaks am wahrscheinlichsten, da ein Browser ein eigenes Resolver-Verhalten hat, das unabhängig von der Proxy-Einstellung ist. Chromium löst über seinen eigenen Stack auf und benötigt einen explizit eingeschränkten DNS-Pfad bei Verwendung von SOCKS; Firefox hat eine Einstellung, die steuert, ob SOCKS-Hostnamen remote aufgelöst werden, und sie ist nicht immer standardmäßig aktiviert. Wenn Sie Browser steuern, prüfen Sie es, statt es anzunehmen, und beachten Sie die browserspezifischen Leak-Kanäle unten.
Testen, ob tatsächlich ein Leak vorliegt
Nehmen Sie es nicht aufgrund der Konfiguration an. Es gibt drei Prüfebenen.
Am schnellsten vergleichen Sie, was das Ziel sieht, mit dem, was Sie erwarten: rufen Sie einen Endpunkt ab, der die von ihm beobachtete Adresse meldet, und bestätigen Sie, dass sie Ihrer Exit-Region entspricht, dann rufen Sie eine geo-sensitive Seite ab und bestätigen Sie, dass der Inhalt übereinstimmt. Wenn die Adresse stimmt, aber der Inhalt falsch ist, ist DNS ein Hauptverdächtiger.
Direkter: beobachten Sie den ausgehenden DNS-Verkehr, während eine Proxy-Anfrage läuft. Auf der Maschine, die die Anfrage stellt, wenn Sie Abfragen für den Hostnamen Ihres Ziels sehen, die über Port 53 ausgehen, findet die Auflösung lokal statt:
# terminal 1
sudo tcpdump -n -i any port 53
# terminal 2
curl -x socks5h://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://example.comWenn Abfragen für den Hostnamen des Ziels im Mitschnitt erscheinen, hat der Client lokal aufgelöst und Sie haben den Leak gefunden.
Drittens, verwenden Sie für Browser-Automatisierung eine der öffentlichen DNS-Leak-Testseiten, die melden, welche Resolver für Sie geantwortet haben, und prüfen Sie, ob diese in der Region Ihres Exits oder in Ihrer eigenen liegen.
Die anderen Leak-Kanäle, die man kennen sollte
DNS ist der häufigste, aber der Vollständigkeit halber erzeugen drei weitere dieselbe Art von Fehler.
IPv6. Wenn der Proxy nur IPv4 verarbeitet und Ihr System für ein Dual-Stack-Ziel IPv6 bevorzugt, kann dieser Verkehr den Proxy vollständig umgehen. Das Deaktivieren von IPv6 auf der Maschine, die die Sammlung durchführt, oder das Erzwingen von IPv4 im Client, beseitigt eine ganze Kategorie verwirrender Ergebnisse.
WebRTC. In echten Browsern kann WebRTC lokale und öffentliche Adressen über einen separaten Mechanismus offenlegen, der Proxy-Einstellungen ignoriert. Wenn Sie einen Browser für etwas Identitätssensibles steuern, deaktivieren Sie es.
System- und Bibliotheks-Standardwerte. Manche Laufzeitumgebungen cachen DNS-Ergebnisse aggressiv oder konsultieren den OS-Resolver unabhängig von der Proxy-Konfiguration, und ein Eintrag in der hosts-Datei oder ein lokaler zwischenspeichernder Resolver überschreibt alles, was Sie konfiguriert haben.
Wenn Identitätskonsistenz für Ihre Arbeit wichtig ist, ist DNS eine Ebene unter mehreren, und die breitere Menge an Signalen, die übereinstimmen müssen, wird behandelt in TLS- und HTTP/2-Fingerprinting und Blocks vermeiden.
Eine kurze Checkliste
Bevorzugen Sie das HTTP-Schema gegen das Gateway, sofern Sie SOCKS5 nicht speziell benötigen, da es standardmäßig remote auflöst. Wenn Sie SOCKS5 verwenden, verwenden Sie überall socks5h und durchsuchen Sie Ihre Codebasis nach nacktem socks5://, um Nachzügler zu erwischen. Verifizieren Sie mit einem Paketmitschnitt auf Port 53, statt der Konfiguration zu vertrauen. Erzwingen Sie IPv4, wenn Ihr Proxy-Pfad nur IPv4 ist. Deaktivieren Sie WebRTC in automatisierten Browsern. Führen Sie dann eine geo-sensitive Anfrage erneut aus und bestätigen Sie, dass der Inhalt der Exit-Region entspricht und nicht Ihrer eigenen.
Fazit
Ein DNS-Leak bedeutet, dass Ihr Verkehr durch den Proxy lief, während die Namensauflösung dies nicht tat, was die von Ihnen abgefragten Domains Ihrem eigenen Resolver offenlegt und, wichtiger für die Sammlung, sie von Ihrem Standort statt von Ihrem Exit aus auflöst. HTTP-Proxying löst standardmäßig remote auf und leakt selten; SOCKS5 leakt, wann immer der Client lokal auflöst, weshalb socks5h gegenüber socks5 die mit Abstand häufigste Lösung ist. Headless-Browser benötigen besondere Aufmerksamkeit, da sie unabhängig von Ihrer Proxy-Einstellung auflösen. Testen Sie mit einem Paketmitschnitt statt der Konfiguration zu vertrauen, und schließen Sie dabei auch IPv6 und WebRTC aus. Wenn ein geo-zielgerichteter Job Inhalte für die falsche Region liefert und die Exit-Adresse korrekt erscheint, ist dies das Erste, was Sie prüfen sollten.
Das Gateway spricht sowohl HTTP(S) als auch SOCKS5 über denselben Endpunkt, sodass das Umschalten der Schemata zum Testen nichts kostet: siehe Gateway und Authentifizierung. Das Produkt sind Residential Proxies mit Land- und Stadt-Targeting und Preisgestaltung pro GB.