DNS-Leak-Leitfaden: WebRTC, Header und DNS-Leaks vermeiden

Ein DNS-Leak entsteht, wenn der Zielhostname aufgelöst wird, bevor der Proxy-Tunnel steht. Die HTTP-Anfrage kann über gw.weproxy.com.tr hinausgehen, während die DNS-Abfrage noch den Büro-Resolver, den Heimrouter oder den DoH-Endpunkt des Browsers trifft. In diesem Log stehen die echte Client-IP und der abgefragte Name. WebRTC-ICE-Kandidaten und der Header Forwarded öffnen in derselben Sitzung einen zweiten und einen dritten Kanal.

Dieser Leitfaden trennt den TCP-Handshake von der Auflösungsreihenfolge, zeigt den Unterschied zwischen socks5h und lokalem DNS und erklärt, warum Browser-UDP oft außerhalb eines HTTP-Proxy-Profils bleibt. Die Beispiele nutzen cURL, Python und Node.js. Ziel ist, Exit-IP und Identitätsebene (DNS, ICE, Header) auf denselben Pfad zu legen. Eine saubere Exit-IP hilft nicht, solange ein Leak offen ist.

Ein DNS-Leak entsteht vor der Exit-IP

https://example.com zu öffnen sind zwei Aufgaben. Die Auflösung fragt, auf welche Adresse der Name zeigt. Der Transport fragt, wie TCP (und TLS) diese Adresse erreicht. Ein Proxy übernimmt meist nur die zweite Aufgabe. Bleibt die erste beim Client, liegt ein DNS-Leak vor.

Der Resolver sieht die Quell-IP der Abfrage, den exakten Namen (QNAME) und den Typ (A, AAAA, HTTPS). Die Zielseite sieht dieses Log nicht. Der Betreiber des Resolvers sieht es. Sammelstrecken, Transparenzberichte oder ein falsch konfigurierter Router machen aus der Spur ein operatives Risiko.

DNS over HTTPS schließt das nicht von selbst. DoH ist selbst eine HTTPS-Anfrage. Umgeht sie das Proxy-Profil, sieht der Resolver weiterhin die echte Client-IP und den QNAME. Läuft DoH durch den Proxy, sieht der Resolver den Proxy-Exit. Die Frage lautet nicht „ist DNS verschlüsselt?“, sondern „welche IP hat die Abfrage gesendet?“.

Praktischer Test: Wählen Sie einen Namen, den Sie kontrollieren, etwa probe-20261008.example.com. Legen Sie den Client hinter den Proxy, fragen Sie den Namen einmal ab und lesen Sie das autoritative DNS-Log. Ist die Quelle nicht die erwartete Exit-IP, ist der DNS-Leak belegt. Öffentliche „DNS-Leak-Test“-Seiten zeigen dieselbe Idee. Das eigene Log ist stärker, weil Sie sehen, welcher Resolver geantwortet hat.

TCP-Handshake und Auflösungsreihenfolge

Der TCP-Dreifach-Handshake (SYN, SYN-ACK, ACK) startet erst, wenn eine Adresse bekannt ist. Mit Proxy ist das nicht immer der Origin. Beim HTTP-Proxy öffnet der Client zuerst TCP zum Proxy und fordert dann mit CONNECT einen Tunnel an. SOCKS5 macht dasselbe über einen Steuerkanal. Der Handshake mit dem Origin läuft im Tunnel, nachdem der Tunnel steht.

Die Reihenfolge ist ungefähr:

1. Der Client löst den Proxy-Namen auf (gw.weproxy.com.tr). Diese Abfrage darf lokal bleiben. Es ist der Gateway-Name, nicht die Zielseite.
2. Der Client öffnet TCP zum Proxy und authentifiziert sich.
3. Der Client sendet entweder den Hostnamen an den Proxy oder löst ihn zuerst selbst auf.
4. Der Proxy öffnet TCP zum Origin (und löst auf, wenn Schritt 3 einen Hostnamen gesendet hat).
5. Der Client sendet ein TLS-ClientHello im Tunnel. SNI trägt den Origin-Namen. Das sind Metadaten, getrennt von DNS.

Löst Schritt 3 lokal auf, ist der DNS-Leak vor dem Origin-Handshake fertig. TLS „durch den Proxy“ zu sehen löscht diese Logzeile nicht.

HTTP CONNECT lässt den Hostnamen beim Proxy

Ein HTTP-Proxy trägt HTTPS mit der Methode CONNECT. Der Client sendet CONNECT example.com:443 HTTP/1.1. Der Hostname geht an den Proxy. Ein gesunder Client macht daraus nicht vorher einen A-Record. Der Proxy öffnet TCP zum Origin, antwortet mit 200 Connection Established, und der Client beendet TLS im Tunnel.

In diesem Modell darf die DNS-Abfrage des Ziels den Client-Resolver nicht treffen. Tut sie es doch, hat die Bibliothek getaddrinfo vor CONNECT aufgerufen. Manche älteren HTTP-Clients behaupten, ein Proxy sei konfiguriert, und lösen trotzdem lokal auf. Prüfen Sie das Log. Verlassen Sie sich nicht auf das Protokoll-Etikett.

Bei klarem HTTP sendet der Client eine absolute URL: GET http://example.com/path. Die Auflösung liegt wieder beim Proxy. Der Alltag ist fast immer der TLS-CONNECT-Pfad.

Das WeProxy-Gateway erwartet Benutzername und Passwort auf gw.weproxy.com.tr:8989. Enthält das Passwort @, : oder /, muss es in der URL prozentkodiert werden. Sonst hält der Client den Benutzernamen für den Host, und CONNECT startet nicht. Das ist ein Verbindungsfehler, kein Leak, und Teams verwechseln beides.

SOCKS5, lokales DNS und socks5h

SOCKS5 prüft die Anwendungsbytes nicht. RFC 1928 trägt das Ziel als IPv4 (ATYP 0x01), Domainname (ATYP 0x03) oder IPv6 (ATYP 0x04). Ein Domainname bedeutet: Der Proxy löst auf. Eine IPv4-Adresse bedeutet: Der Client hat schon aufgelöst.

socks5h ist kein eigenes Protokoll. Es ist das Schema, mit dem curl und viele Bibliotheken sagen: „Schick den Hostnamen an den Proxy.“ Bei curl löst --socks5 lokal auf. --socks5-hostname und socks5h:// nutzen ATYP 0x03. Dasselbe Passwort, derselbe Port, ein anderer DNS-Pfad.

Verwechseln Sie das nicht mit UDP. Klassisches DNS ist UDP/53, aber entferntes DNS über SOCKS5 braucht kein UDP ASSOCIATE. Der Client erzeugt die Abfrage nicht. Er sendet den Hostnamen auf dem Steuerkanal, und der Proxy nutzt seinen eigenen Resolver. UDP ASSOCIATE ist für Spiele, Sprache und manche STUN-Pfade. Die Schichten trennen der UDP-Proxy-Leitfaden und der Vergleich HTTP und SOCKS5.

Statische Residential-Pakete in der Türkei bieten HTTP und einfaches SOCKS5. UDP ASSOCIATE liegt auf diesen Paketen nicht. Das blockiert entferntes DNS über socks5h nicht. SOCKS5 ohne UDP kann einen Hostnamen weiter als ATYP 0x03 tragen. Aufgaben, die UDP brauchen, folgen der Standortmatrix. Einen DNS-Leak-Test an ein UDP-Abzeichen zu hängen erzeugt ein falsches Negativ.

Warum ein WebRTC-Leak den Proxy umgeht

WebRTC sammelt Kandidaten-IPs für Medien. RTCPeerConnection baut einen Host-Kandidaten aus lokalen Schnittstellen, einen Server-Reflexive-Kandidaten über STUN und einen Relay-Kandidaten über TURN. Host- und Server-Reflexive-Kandidaten sind UDP-Sockets, die nicht durch den HTTP-Proxy der Seite laufen. Ein Profil „gesamter Browserverkehr“ tunnelt oft nur TCP 80/443.

Der Seiten-Exit kann residential aussehen, während die ICE-Zeile weiter die Heim- oder Büro-IP zeigt. Der Peer oder das eigene Skript der Seite kann diesen Kandidaten lesen. Die Kandidatentypen stehen in RTCPeerConnection auf MDN. Das ist das Design der API, kein Zufallsfehler.

Führen Sie das einmal in dem Profil aus, das Sie ausliefern. Ist typ host oder typ srflx nicht Ihr Proxy-Exit, ist der WebRTC-Leak offen.

const pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }],
})
pc.createDataChannel('leak-check')
pc.onicecandidate = (event) => {
  if (event.candidate) console.log(event.candidate.candidate)
}
const offer = await pc.createOffer()
await pc.setLocalDescription(offer)

Die Abhilfe ist eine Richtlinie, kein Slogan. Setzen Sie Chromium WebRtcIPHandlingPolicy auf disable_non_proxied_udp, damit UDP, das nicht über den Proxy läuft, keine Kandidaten mehr erzeugt. Eine Enterprise-Richtlinie oder der Schalter --force-webrtc-ip-handling-policy=disable_non_proxied_udp tut dasselbe. Wiederholen Sie den Dump. Die Liste soll leer sein oder nur Relay enthalten. Ein „eingeschalteter“ Schalter ist kein Beweis, solange die ICE-Zeilen gleich bleiben.

Anti-Detect-Browser können die Richtlinie ins Profil legen. Dumpen Sie ICE trotzdem einmal pro Profil. Beim Klonen fällt der Schalter manchmal weg.

Header-Leaks und der IPv6-Seitenpfad

DNS und WebRTC legen den Client auf der Netzwerkebene offen. Ein Header-Leak heißt: Der Proxy oder der Client schreibt die Client-IP in die Anfrage, die den Origin erreicht. Ein sauberer Forward-Proxy hängt die Client-Adresse nicht an. Verwechseln Sie einen Reverse-Proxy (nginx, CDN) nicht mit einem Forward-Proxy. X-Forwarded-For an einem Reverse-Proxy ist dessen eigene Architektur. Wenn Ihr Exit-Proxy diesen Wert an den Origin weiterreicht, ist das ein eigener Fehler.

Forwarded und X-Forwarded-For

Zu prüfen: X-Forwarded-For, Forwarded (RFC 7239), X-Real-IP, Via, Client-IP. Senden Sie eine Anfrage durch den Proxy an einen Echo-Endpunkt. Zeigt die Rückgabe Ihre Büro-IP, eine interne Adresse aus dem Browserprofil oder eine Via-Kette, die der Proxy gesetzt hat, notieren Sie das.

curl -sS -x "http://USER:[email protected]:8989" \
  "https://httpbin.org/headers"

USER und PASSWORD sind die Zugangsdaten aus dem Panel. Fehlen diese Header, zeigt diese Anfrage keinen Header-Leak. Sind sie da, trennen Sie „unser Code hat das gesetzt“ (Axios-Interceptor, Browser-Erweiterung) von „eine Zwischenstelle hat das gesetzt“. Bibliotheken setzen manchmal X-Forwarded-For: 10.x, um hilfreich zu sein. Origins behandeln den Wert als echt.

Happy Eyeballs und IPv6

Hat der Client einen funktionierenden IPv6-Pfad und das Proxy-Profil nur IPv4, kann Happy Eyeballs (RFC 8305) AAAA gegen A laufen lassen. IPv6, das direkt zum ISP geht, betritt den Proxy nie. Symptom: Ein IPv4-Echo zeigt den Proxy, ein IPv6-Echo Ihren Heim-Präfix.

Vergleichen Sie beide Zustände mit dem IPv6-Checker, Profil an und Profil aus. Braucht die Aufgabe kein IPv6, schalten Sie IPv6 für dieses Profil ab. Das ist die enge Korrektur. Braucht die Aufgabe IPv6, muss auch der Exit IPv6 sein. Sonst ist Verkehr, den Sie für proxied halten, nur zur Hälfte proxied. IPv6-Proxy-Exits decken den zweiten Fall. Sie schließen allein keinen IPv4-Leak.

Leak-Kanäle im Vergleich

Verwechseln Sie SNI nicht mit einem DNS-Leak. SNI trägt den Origin-Namen in TLS, und der Origin erwartet diesen Namen. Das Problem ist ein Resolver, den der Origin nie sieht und der denselben Namen neben Ihrer echten IP protokolliert.

Tests mit cURL, Python und Node.js

Die Zugangsdaten unten sind Platzhalter. Notieren Sie zuerst die Adresse ohne Proxy mit dem My-IP-Werkzeug. Wiederholen Sie mit Proxy oder rufen Sie api.ipify.org auf. Stimmen beide Adressen überein, steht der Tunnel nicht. Starten Sie den DNS-Test nicht.

cURL

# HTTP-Proxy: CONNECT trägt den Hostnamen
curl -sS -x "http://USER:[email protected]:8989" https://api.ipify.org
echo

# SOCKS5, lokales DNS — Leak-Risiko
curl -sS --socks5 "USER:[email protected]:8989" https://api.ipify.org
echo

# SOCKS5, entferntes DNS
curl -sS --socks5-hostname "USER:[email protected]:8989" https://api.ipify.org
echo

Der zweite und der dritte Befehl können dieselbe Exit-IP drucken. Der DNS-Unterschied erscheint nicht auf einem IP-Echo. Er erscheint im autoritativen Log eines Namens, den Sie kontrollieren. Schreibt der dritte Befehl die Exit-IP und der zweite die Client-IP, ist die Diagnose fertig.

Python

requests schreibt den Hostnamen in CONNECT, wenn HTTPS einen HTTP-Proxy nutzt. SOCKS5 braucht requests[socks] (PySocks). socks5:// löst auf vielen Installationen lokal auf. Entferntes DNS braucht das Schema socks5h://.

import requests

proxies = {
    "http": "socks5h://USER:[email protected]:8989",
    "https": "socks5h://USER:[email protected]:8989",
}
response = requests.get("https://api.ipify.org", proxies=proxies, timeout=30)
print(response.text)

Reicht ein HTTP-Proxy, nutzen Sie das Schema http:// und lassen PySocks weg. Die Python-Proxy-Integration zeigt dasselbe Gateway-Format. Mit trust_env=True überschreibt HTTP_PROXY das Dict im Code. Setzen Sie im Test Session.trust_env = False, sonst debuggen Sie „die Datei sagt socks5h, der Prozess nutzt HTTP“.

Node.js

Das eingebaute fetch von Node übernimmt den System-Proxy nicht. Für einen HTTP-Proxy setzt ProxyAgent aus undici den Hostnamen auf CONNECT. Für SOCKS5 mit entferntem DNS nutzen Sie socks5h:// mit socks-proxy-agent, damit der Agent ATYP 0x03 sendet. Ein Wrapper, der dns.lookup aufruft und dann zur IP verbindet, holt den Leak zurück.

import { ProxyAgent, fetch } from 'undici'

const proxy = new ProxyAgent('http://USER:[email protected]:8989')
const response = await fetch('https://api.ipify.org', { dispatcher: proxy })
console.log(await response.text())

Die Node.js-Proxy-Integration nutzt dieselbe Gateway-Form. Ein über global-agent oder NODE_OPTIONS eingespritzter Agent kann den ProxyAgent in der Datei verdecken. Führen Sie den Test in einem sauberen Prozess aus.

Rate-Limits, Sticky-Sitzung und Pool

Ist der Leak zu, trifft dieselbe Exit-IP weiter das Rate-Limit des Ziels. 429 und Retry-After (HTTP-Semantik steht in RFC 9110) erscheinen, wenn zu viel Parallelität auf einer Adresse sitzt. Eine Sticky-Sitzung hält Cookies und Local Storage stabil. Sie häuft den Zähler auch auf dieser IP. Ein Pool, der pro Anfrage rotiert, verteilt den Zähler und bricht die Sitzungskontinuität.

Mischen Sie die beiden Probleme nicht. Rotation schließt einen DNS-Leak nicht. Jeder neue Exit lässt Ihre echte IP weiter im Resolver-Log. Zuerst DNS und WebRTC, dann die Pool-Politik.

import time
import requests

def get_with_backoff(url, proxies, attempts=5):
    delay = 1.0
    response = None
    for _ in range(attempts):
        response = requests.get(url, proxies=proxies, timeout=30)
        if response.status_code != 429:
            return response
        retry_after = response.headers.get("Retry-After", "")
        time.sleep(float(retry_after) if retry_after.isdigit() else delay)
        delay = min(delay * 2, 30)
    return response

Backoff ist kein Weg, eine Sperre zu „schlagen“. Antwortet das Ziel mit einer Kontosperre oder einem leeren Body statt 429, vergrößert ein größerer Pool den Fehler. Senken Sie die Parallelität, achten Sie auf Retry-After und wählen Sie die Geografie nur, wenn die Aufgabe diesen Exit wirklich braucht.

Für Schritte mit höherem Vertrauen passt ein rotierender Residential-IP-Pool. Muss dieselbe Identität stundenlang bleiben, hält statische Residential-Proxy-Infrastruktur einen Exit fest. Aufgaben mit schwacher Abwehr und enger Latenz passen zu Datacenter-Proxy-Optionen. Das Produkt kommt nach dem Leak-Test. Zuerst der Kanal, dann das Produkt.

Für Arbeit mit Ziel Türkei hält ein Türkei-Exit die Geo-Schicht der Seite und Ihr DNS-Log auf demselben Land. Die Zuordnung steht auf den Türkei-Proxy-Standorten. Ein Türkei-Exit auf eine Seite in einem anderen Land ist kein Protokollfehler. Es ist eine Unstimmigkeit, die Sie nicht brauchen, wenn die Aufgabe sie nicht verlangt.

DSGVO, KVKK und robots.txt

Eine IP-Adresse ist ein personenbezogenes Datum, wenn sie eine Person bestimmbar macht. In der EU steht diese Definition in der Verordnung 2016/679 auf EUR-Lex. In der Türkei ist Gesetz 6698 (KVKK) auf mevzuat.gov.tr veröffentlicht. Dieser Leitfaden ist keine Rechtsberatung. Ein DNS-Log und ein WebRTC-Kandidat können Ihre echte IP an einen fremden Resolver oder an ein Seitenskript tragen. Enthalten die Daten, die Sie sammeln, IPs anderer Personen, brauchen Zweck und Speicherdauer eine eigene Prüfung.

robots.txt ist keine Zugriffskontrollliste. RFC 9309 definiert sie als freiwillige Crawling-Präferenz. Eine URL durch einen Proxy öffnen zu können hebt ein Disallow nicht auf. Die Bedingungen des Ziels, Datenschutz nach DSGVO oder KVKK und die Nutzungsrichtlinie von WeProxy gelten zusammen. Automatisierung bleibt auf Flächen, die öffentlich und erlaubt sind.

Checkliste am WeProxy-Exit

1. Notieren Sie die IP ohne Proxy mit My IP.
2. Wiederholen Sie über HTTP-CONNECT oder socks5h. Machen Sie nicht weiter, wenn sich die Adresse nicht geändert hat.
3. Lesen Sie das autoritative DNS-Log eines Namens, den Sie kontrollieren. Eine Quelle, die nicht der Exit ist, bedeutet lokale Auflösung.
4. Dumpen Sie ICE im Browser. Ist srflx Ihre Heim-IP, setzen Sie die WebRTC-Richtlinie und dumpen Sie erneut.
5. Suchen Sie auf einem Echo-Endpunkt nach X-Forwarded-For und Forwarded.
6. Ist IPv6 an, wiederholen Sie die IPv6-Prüfung im Proxy-Profil.
7. Bei 429 korrigieren Sie zuerst Parallelität und Retry-After. Schließen Sie einen DNS-Leak nicht durch einen größeren Pool.
8. Entfernen Sie danach Zugangsdaten aus der Shell-History und aus CI-Logs. Ein Passwort in der URL macht aus dem Leak-Test einen eigenen Vorfall.

Ist der DNS-Leak zu, passt der WebRTC-Kandidat zum Proxy und trägt die Anfrage an den Origin die Client-IP nicht, ist die Exit-IP die einzige Identitätsebene. Sticky oder Rotation, Residential oder Datacenter sind danach sinnvolle Fragen. Das Produkt in umgekehrter Reihenfolge zu wechseln ändert nicht, was der Resolver protokolliert hat.