Wycieki DNS: jak ruch omija proxy i jak zamknąć dns leak na poziomie systemu

Wprowadzenie: dlaczego proxy może być idealne, a i tak cię widzą

Wyobraź sobie sytuację. Kupiłeś dobrej jakości mobilne proxy, skonfigurowałeś przeglądarkę antydetekt, sprawdziłeś IP w trzech różnych serwisach — wszędzie adres operatora komórkowego w wybranym regionie. Uruchamiasz konto reklamowe, rozgrzewasz konta, prowadzisz scraping. A po kilku dniach dostajesz blokadę z uzasadnieniem o podejrzanej aktywności. Znane? Jedna z najbardziej niedocenianych przyczyn takich historii to dns leak, czyli wyciek zapytań DNS obok proxy.

Paradoks polega na tym, że adres IP faktycznie jest podmieniony. Strona widzi ruch z sieci komórkowej. Ale przed każdym połączeniem twój komputer cicho pyta swojego dostawcę internetu: „gdzie znajduje się serwer taki a taki?”. I to pytanie wychodzi bezpośrednio, bez udziału proxy. W rezultacie po stronie obserwatora pojawiają się dwa obrazy, które się nie zgadzają: połączenie idzie z sieci komórkowej jednego regionu, a nazwy są rozwiązywane przez resolver domowego dostawcy internetu zupełnie innego miasta. Dla systemów antyfraudowych 2026 roku taka rozbieżność to nie drobiazg, a jeden z najbardziej niezawodnych sygnałów.

Z naszych obserwacji zgłoszeń do wsparcia wynika, że znaczna część skarg w stylu „proxy nie działa, geo wykrywa się błędnie, konta lecą bez powodu” przy dokładnej analizie okazuje się nie problemem proxy w ogóle. To problem warstwy DNS po stronie klienta. Co więcej, osób, które celowo sprawdzają DNS przed rozpoczęciem pracy, wciąż jest mniejszość — większość ogranicza się do sprawdzenia IP.

W tym przewodniku omówimy temat kompleksowo. Dowiesz się, jak działa rozwiązywanie nazw i w którym momencie wychodzi obok proxy. Zrozumiesz, czym różnią się proxy HTTP i SOCKS z punktu widzenia DNS, dlaczego jedna litera w ciągu połączenia rozstrzyga wszystko i jak przeglądarki z włączonym szyfrowanym DNS tworzą nową kategorię wycieków. Podamy cztery praktyczne metody — diagnostyka, konfiguracja oprogramowania klienckiego, przeglądarki i antydetekty, poziom systemowy — każda z instrukcjami krok po kroku i listami kontrolnymi. Omówimy typowe błędy, przypadki z liczbami i odpowiemy na trudne pytania.

Ważna granica: ten artykuł dotyczy warstwy DNS. Wycieki przez WebRTC, fingerprinty przeglądarki, timingi i inne kanały deanonymizacji to osobne tematy, omówione w innych materiałach bloga. Tutaj skupimy się na jednym, ale fundamentalnym kanale, bo bez jego zrozumienia każda inna konfiguracja stoi na piasku.

Podstawy: jak działa DNS i czym jest dns leak

Książka telefoniczna internetu

Za każdym razem, gdy przeglądarka lub skrypt chce połączyć się ze stroną, potrzebuje nie domeny, a adresu IP. Domena to nazwa zrozumiała dla człowieka. Adres to współrzędne zrozumiałe dla sieci. Usługa, która tłumaczy jedno na drugie, nazywa się DNS (Domain Name System). Najprostsza analogia to książka telefoniczna: znasz imię, książka podaje numer. Tylko ta książka jest rozproszona po tysiącach serwerów i działa w milisekundach.

Jak wygląda rozwiązywanie nazwy w praktyce:

1. Aplikacja wywołuje funkcję systemową (w świecie Unix najczęściej getaddrinfo), przekazując jej nazwę domeny.
2. System operacyjny sprawdza lokalny cache i plik hosts.
3. Jeśli odpowiedzi nie ma, resolver zastępczy (stub resolver) systemu wysyła zapytanie na adres serwera DNS wpisany w ustawieniach sieciowych. Zwykle jest to serwer twojego dostawcy internetu, przydzielony przez DHCP, albo publiczny resolver, który wskazałeś ręcznie.
4. Rekurencyjny resolver dostawcy idzie po łańcuchu serwerów głównych, serwerów strefy domeny i serwerów autorytatywnych domeny, znajduje odpowiedź i zwraca ją tobie.
5. Aplikacja otrzymuje IP i dopiero teraz nawiązuje połączenie.

Zwróć uwagę na kolejność. Najpierw DNS, potem połączenie. Proxy to narzędzie, które ingeruje w połączenie. A czy ingeruje w DNS — zależy od typu proxy, protokołu i tego, jak dokładnie aplikacja z niego korzysta.

Co dokładnie nazywamy wyciekiem

DNS leak to sytuacja, w której ruch aplikacji idzie przez proxy, a zapytania o rozwiązywanie nazw — nie. Wychodzą bezpośrednio z twojego rzeczywistego interfejsu sieciowego do resolvera skonfigurowanego w systemie. Efekt: strona, z którą się łączysz, widzi IP proxy, ale twój dostawca internetu i właściciel resolvera widzą listę wszystkich domen, do których się odwoływałeś. A docelowy serwis w pewnych warunkach może porównać, skąd przyszło połączenie i skąd przyszło zapytanie DNS.

Dlaczego to ważne właśnie dla użytkowników mobilnych proxy? Bo cała wartość mobilnego IP tkwi w jego wiarygodności. Adres należy do operatora komórkowego, stoi za nim tysiące realnych abonentów, zmienia się, ma dobrą reputację. Ale realny abonent sieci komórkowej rozwiązuje nazwy przez serwery DNS tego samego operatora. Jeśli twój ruch wychodzi z sieci komórkowej, a nazwy są rozwiązywane przez kablowe proxy w innym regionie, przestajesz przypominać realnego abonenta. Zaczynasz przypominać kogoś, kto używa proxy. Właściwie tak jest — i sam o tym opowiedziałeś.

Trzy role, które widzą twój wyciek

• Twój dostawca internetu. Widzi zapytania do swojego resolvera i wie, jakie domeny odwiedzasz, nawet jeśli sama treść poszła przez proxy.
• Właściciel resolvera. Jeśli wpisałeś publiczny DNS, pełną listę twoich domen i twój rzeczywisty IP widzi jego operator.
• Docelowa strona i jej antyfraud. Bezpośrednio nie otrzymuje zapytania DNS, ale ma kanały pośrednie: geografię serwerów autorytatywnych, mechanizm EDNS Client Subnet, routing CDN i specjalne domeny testowe generowane pod konkretną sesję. O tym szczegółowo w następnej sekcji.

Głębokie zanurzenie: anatomia wycieku DNS przy pracy przez proxy

Proxy HTTP: dlaczego zwykle nie cieknie, ale bywają wyjątki

Pracując przez proxy HTTP, przeglądarka wysyła mu żądanie, w którym domena jest podana tekstem. Dla nieszyfrowanego HTTP to pełny URL w pierwszej linii żądania. Dla HTTPS przeglądarka wysyła komendę CONNECT z nazwą hosta i portem, a proxy sam rozwiązuje tę nazwę i ustanawia tunel. W obu przypadkach klient nie musi znać IP docelowego serwera. Rozwiązywanie robi proxy, po swojej stronie, swoimi resolverami. W przypadku mobilnego proxy — po stronie modemu lub telefonu, przez serwery DNS operatora. Tak właśnie powinno być.

Skąd więc biorą się wycieki z proxy HTTP? Ich źródła są pośrednie:

• Skrypty PAC. Plik autokonfiguracji proxy może zawierać funkcję dnsResolve, która rozwiązuje domenę lokalnie, by zdecydować, czy wysłać żądanie przez proxy. Sama decyzja jest podejmowana już po lokalnym zapytaniu DNS.
• Wstępne rozwiązywanie nazw. Niektóre aplikacje sprawdzają dostępność hosta przed połączeniem: pingują, rozwiązują, a potem idą przez proxy. Aplikacje Java z InetAddress, niektóre scrapery, wtyczki sprawdzające linki.
• Usługi w tle przeglądarki. Wstępne ładowanie stron, DNS-prefetch, sprawdzanie bezpiecznego przeglądania i aktualizacji mogą działać według własnych reguł i nie zawsze respektują ustawienia proxy.

SOCKS: jedna litera między czystą sesją a wyciekiem

Tu zaczyna się najciekawsze. Protokół SOCKS4 w oryginalnej wersji potrafi przekazać proxy tylko adres IP celu. To znaczy, że klient musi rozwiązać nazwę sam, przed połączeniem. Wyciek jest wbudowany w protokół. Rozszerzenie SOCKS4a dodało możliwość przekazywania nazwy hosta. SOCKS5 obsługuje trzy typy adresu celu: IPv4, IPv6 i nazwę domenową.

Wydawałoby się, że SOCKS5 rozwiązuje problem. Ale obsługa nazwy domenowej w protokole nie oznacza, że klient z niej skorzysta. Wiele bibliotek i programów domyślnie rozwiązuje nazwę lokalnie i wysyła proxy gotowy IP. Protokół na to pozwala — wyciek po prostu następuje o krok wcześniej.

Stąd słynna litera h. W curl i bibliotekach, które trzymają się jego konwencji, schemat socks5:// oznacza lokalne rozwiązywanie nazw, a socks5h:// — przekazanie nazwy hosta serwerowi proxy do zdalnego rozwiązywania. Jedna litera. Różnica między czystą sesją, w której wszystko, łącznie z DNS, wychodzi z sieci komórkowej operatora, a sesją, w której każda nazwa najpierw wycieka do twojego dostawcy.

Dlaczego serwer proxy lepiej rozwiązuje sam

Jest tu nieoczywisty moment, który wielu pomija. Nie chodzi tylko o prywatność. Gdy nazwę rozwiązuje zdalna strona mobilnego proxy, odpowiedź DNS jest formowana z uwzględnieniem lokalizacji operatora. Duże serwisy używają CDN i geo-DNS: na tę samą domenę różnym klientom zwracane są różne IP, najbliższe im. Jeśli rozwiązuje twój domowy dostawca, otrzymasz adres węzła CDN blisko twojej rzeczywistej lokalizacji. A potem połączysz się z tym węzłem przez mobilne proxy z innego regionu. Dla serwisu wygląda to dziwnie: klient z sieci komórkowej regionu A z jakiegoś powodu trafił na węzeł przeznaczony dla regionu B. To właśnie pośredni kanał wykrywania dns leak, który nie wymaga żadnego dostępu do twoich zapytań DNS.

EDNS Client Subnet: jak resolver rozdaje twoją podsieć

Mechanizm EDNS Client Subnet (ECS) został wymyślony po to, by publiczne resolvery mogły przekazywać serwerom autorytatywnym część adresu klienta — zwykle pierwsze 24 bity dla IPv4. Dzięki temu CDN rozumie, skąd jest realny użytkownik, i zwraca najbliższy węzeł. To wygodne dla szybkości. Ale z punktu widzenia wycieków oznacza to, że przy lokalnym rozwiązywaniu przez publiczny DNS z obsługą ECS serwer autorytatywny docelowej domeny otrzymuje podsieć twojego rzeczywistego połączenia. Nie pełny adres, ale wystarczająco, by zrozumieć dostawcę i miasto. A połączenie potem przychodzi z mobilnego IP. Dwie podsieci, dwóch operatorów, jeden użytkownik.

Szyfrowany DNS: nowa kategoria wycieków

Od lat 2020. przeglądarki i systemy operacyjne masowo przeszły na DNS over HTTPS (DoH) i DNS over TLS (DoT), a do 2026 roku doszedł też DNS over QUIC. Idea szczytna: dostawca nie widzi już twoich zapytań. Ale dla pracy przez proxy powstał efekt uboczny. Przeglądarka z włączonym „bezpiecznym DNS” zwraca się do wybranego serwera DoH własnym klientem, a ten ruch bynajmniej nie zawsze idzie zgodnie z ustawieniami proxy. Czyli nazwy są rozwiązywane nie u operatora komórkowego, a u dużego publicznego resolvera, i to z twojego rzeczywistego IP. Szyfrowanie ratuje przed dostawcą, ale nie przed rozbieżnością między stroną DNS a stroną połączenia.

Dodatkową warstwę złożoności dodaje Encrypted Client Hello (ECH). Do jego działania przeglądarka odpytuje o specjalne rekordy HTTPS w DNS. Im więcej stron używa ECH, tym więcej zapytań DNS robi przeglądarka — i tym więcej powodów do wycieku, jeśli DNS nie idzie właściwą drogą.

IPv6 i Happy Eyeballs

Nowoczesne systemy odpytują jednocześnie rekordy A (IPv4) i AAAA (IPv6) i próbują połączyć się z tym, co odpowie szybciej — algorytm Happy Eyeballs. Jeśli twoja rzeczywista sieć obsługuje IPv6, a proxy działa tylko przez IPv4, część aplikacji potrafi wyjść bezpośrednio po IPv6, omijając proxy w całości. Ściśle mówiąc, to nie dns leak, a wyciek połączenia, ale wyzwalaczem jest właśnie odpowiedź DNS z rekordem AAAA. Dlatego w kontekście higieny DNS trzeba o IPv6 pamiętać.

Cache i hosts: wyciek z przeszłości

System operacyjny cachuje odpowiedzi DNS. Jeśli pracowałeś bez proxy, a potem je włączyłeś, część nazw leży już w cache z adresami otrzymanymi przez domowy resolver. Nowych zapytań nie będzie, ale połączenia pójdą do „domowych” węzłów CDN. Podobnie plik hosts: wpisy w nim zastępują rozwiązywanie nazw całkowicie, a proxy o tym nie wie.

Metoda 1. Diagnostyka: jak samodzielnie sprawdzić dns leak

Zanim coś skonfigurujesz, musisz zobaczyć problem. Dobra wiadomość: sprawdzenie wycieku DNS to procedura na pięć minut, którą można i trzeba zamienić w rytuał przed każdą sesją roboczą.

Jak działają testy online

Każdy serwis sprawdzania dns leak działa tak samo. Strona generuje kilka unikalnych subdomen w stylu losowy-ciąg.domena-testowa i zmusza twoją przeglądarkę do ich rozwiązania, zwykle przez ładowanie niewidocznych obrazków lub skryptów. Ponieważ subdomeny są unikalne, na pewno nie ma ich w żadnym cache. Zapytanie na pewno dotrze do serwera autorytatywnego domeny testowej, który należy do serwisu. On zapisuje, z jakiego IP przyszło zapytanie — to adres rekurencyjnego resolvera, którego używasz. Potem strona pokazuje ci dwie kolumny: adres, z którego przyszło połączenie HTTP, i adresy resolverów. Jeśli połączenie jest z operatora komórkowego, a resolver należy do domowego dostawcy lub publicznego serwisu DNS — wyciek jest.

Warto rozumieć: dokładnie tak samo może postąpić każda strona. Mechanizm nie wymaga specjalnych uprawnień. Systemy antyfraudowe dużych platform stosują podobne techniki jako część oceny ryzyka sesji. To nie teoria spiskowa, a standardowa inżynieria.

Procedura sprawdzania krok po kroku

1. Ustal linię bazową. Wyłącz proxy, otwórz test dns leak, zapisz, jakie resolvery się pokazują. To twój „domowy” odcisk. Powinieneś rozpoznawać go na pierwszy rzut oka.
2. Wyczyść cache DNS. W Windows komenda ipconfig /flushdns, w macOS restart usługi mDNSResponder, w Linux zależy od resolvera (np. resolvectl flush-caches dla systemd-resolved). Zrestartuj przeglądarkę — ma własny cache.
3. Włącz proxy w sposób, w jaki będziesz pracować naprawdę: przez profil antydetekt, rozszerzenie, ustawienia systemowe lub kod.
4. Uruchom rozszerzony test, który robi nie jedno, a dziesiątki sprawdzeń. Wyciek bywa częściowy: dziewięć zapytań z dziesięciu idzie przez proxy, a dziesiąte — bezpośrednio. Pojedynczy test to przegapi.
5. Porównaj. Wszystkie resolvery powinny należeć do operatora komórkowego, przez którego działa proxy, albo do infrastruktury serwisu proxy. Ani jednego adresu z linii bazowej. Ani jednego publicznego resolvera, którego nie wybrałeś świadomie.
6. Sprawdź IPv6 osobno. Jeśli test pokazuje jakikolwiek adres IPv6 nienależący do proxy — wyciek.
7. Powtórz po dziesięciu minutach pracy. Niektóre procesy w tle startują z opóźnieniem.

Sprawdzanie bez zewnętrznych serwisów: własna domena testowa

Dla tych, którzy pracują z farmami kont lub scrapingiem na skalę przemysłową, rozsądnie jest mieć własne narzędzie. Schemat taki: rejestrujesz niedrogą domenę i stawiasz dla niej autorytatywny serwer DNS na swoim VPS z włączonym logowaniem zapytań. Dalej w dowolnym projekcie, przy starcie dowolnej sesji, odwołujesz się do unikalnej subdomeny w stylu identyfikator-sesji.twoja-domena. W logu serwera DNS pojawia się wpis: jaka subdomena została zapytana i z jakiego IP resolvera. Porównujesz z identyfikatorem sesji i natychmiast widzisz, która dokładnie sesja, który profil, który worker wyciekł. To zamienia jednorazowe sprawdzenie w stały monitoring.

Sprawdzanie niskopoziomowe: patrzymy na sieć

Najuczciwszy sposób — zobaczyć, co naprawdę wychodzi z interfejsu sieciowego. Uruchom analizator ruchu (Wireshark lub tcpdump) na fizycznym interfejsie maszyny i filtruj port 53 UDP i TCP oraz port 853 dla DoT. Potem pracuj przez proxy pięć minut. W idealnym świecie filtr pozostanie pusty: wszystkie nazwy są rozwiązywane po stronie proxy, lokalnych pakietów DNS nie ma w ogóle. Jeśli pakiety są, od razu widzisz, jakie domeny i dokąd wychodzą. Dla DoH filtr jest trudniejszy, bo to zwykły HTTPS na port 443, ale podpowiedzią są połączenia do znanych adresów publicznych dostawców DoH, które pojawiają się nie przez proxy.

Lista kontrolna diagnostyki

• Linia bazowa bez proxy zapisana.
• Cache systemu i przeglądarki wyczyszczony przed testem.
• Rozszerzony test na dziesiątki zapytań wykonany.
• Wszystkie resolvery odpowiadają stronie proxy.
• Adresy IPv6 obcej sieci nie występują.
• Ponowny test po 10 minutach pracy zaliczony.
• Dla krytycznych projektów: analizator ruchu na porcie 53 pokazuje zero pakietów.

Metoda 2. Prawidłowa konfiguracja oprogramowania klienckiego i kodu

Znalazłeś wyciek. Teraz trzeba zrozumieć, gdzie dokładnie aplikacja podejmuje decyzję o lokalnym rozwiązaniu nazwy, i przełączyć ją na zdalne rozwiązywanie. Omówmy najczęstsze środowiska z praktyki arbitrażowców i deweloperów.

Zasada: nazwa hosta musi dotrzeć do proxy

Reguła jest jedna i uniwersalna. Proxy powinno otrzymać od ciebie nazwę domenową, a nie IP. Dla proxy HTTP dzieje się to naturalnie. Dla SOCKS5 trzeba wyraźnie wybrać tryb zdalnego DNS. Dla SOCKS4 bez rozszerzenia a jest to niemożliwe w zasadzie — takie proxy do czystej pracy się nie nadają. Mobilne proxy nowoczesnych serwisów obsługują i HTTP, i SOCKS5 ze zdalnym rozwiązywaniem, więc ograniczenie jest tu tylko po stronie klienta.

curl i wiersz poleceń

Dla SOCKS5 zawsze używaj schematu z literą h. Przykład poprawnego wywołania:

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

Bez litery h curl rozwiąże nazwę lokalnie. Dotyczy to też wszystkich narzędzi zbudowanych na libcurl. Dla proxy HTTP schemat http:// w parametrze -x wystarcza: nazwa pójdzie w żądaniu CONNECT.

Python: requests, httpx, aiohttp

W bibliotece requests z zainstalowanym pakietem obsługi SOCKS obowiązuje analogiczna reguła: socks5:// oznacza lokalne rozwiązywanie, socks5h:// — zdalne. To najczęstszy błąd w scraperach: deweloper kopiuje przykład z dokumentacji, gdzie stoi socks5, i latami goni ruch z dns leak, nawet nie podejrzewając. W httpx i aiohttp obsługa SOCKS jest realizowana przez zewnętrzne transporty, a tryb zdalnego rozwiązywania trzeba sprawdzić w dokumentacji konkretnego transportu — gdzieś to parametr rdns, gdzieś też schemat z h. Sprawdzaj nie po dokumentacji, a po fakcie: uruchom skrypt przeciw własnej domenie testowej i zobacz w logu, skąd przyszło zapytanie.

Osobna pułapka — niskopoziomowe biblioteki socket, które monkipatchują standardowy moduł socket, by opakować cały ruch w SOCKS. Mają flagę zdalnego rozwiązywania, ale domyślnie bywa wyłączona. Plus każde wywołanie socket.gethostbyname w twoim kodzie lub zależnościach przejdzie obok i rozwiąże nazwę przez systemowy resolver.

Node.js i przeglądarki headless

W ekosystemie Node.js agenty SOCKS zwykle przekazują nazwę hosta proxy, ale zależy to od konkretnego pakietu i jego wersji. Dla Puppeteer i Playwright proxy ustawia się na poziomie uruchomienia przeglądarki, a zachowanie jest dziedziczone po silniku Chromium — o jego osobliwościach z SOCKS5 powiemy w następnej sekcji. Jeśli pracujesz w trybie HTTP mobilnego proxy, kwestia znika: Chromium wyśle CONNECT z nazwą hosta.

Go, Java i inne języki

W Go standardowy pakiet golang.org/x/net/proxy dla SOCKS5 przekazuje nazwę hosta zdalnie, ale tylko jeśli używasz jego Dialer bezpośrednio, a nie rozwiązujesz wcześniej. W Java systemowe właściwości dla proxy SOCKS działają, ale wiele klientów HTTP tworzy obiekt InetSocketAddress z wcześniejszym rozwiązaniem, co właśnie powoduje wyciek. Rozwiązanie — tworzyć nierozwiązany adres (metody typu createUnresolved) i upewnić się, że klient obsługuje przekazywanie nazwy. Uniwersalna rada dla dowolnego języka: znajdź w kodzie i w zależnościach wszystkie miejsca, gdzie domena zamienia się w IP, i upewnij się, że dzieje się to po nawiązaniu połączenia z proxy, a nie przed.

Audyt projektu krok po kroku

1. Znajdź w kodzie wszystkie ciągi połączenia z proxy. Sprawdź schematy: socks5 bez h — czerwona flaga.
2. Znajdź wszystkie jawne wywołania rozwiązywania nazw: gethostbyname, getaddrinfo, dns.lookup, InetAddress.getByName. Każde — potencjalny wyciek.
3. Sprawdź zależności: biblioteki sprawdzania dostępności, health-check, retry z wcześniejszym pingiem.
4. Uruchom projekt przeciw własnej domenie testowej z unikalną subdomeną na każdy worker. Log serwera DNS pokaże, kto wycieka.
5. Dodaj autotest: sesja nie jest uznawana za ważną, dopóki sprawdzenie DNS nie potwierdzi, że resolver należy do strony proxy.
6. Zapisz wynik w dokumentacji projektu: która biblioteka, która wersja, który tryb.

Lista kontrolna dla dewelopera

• Wszystkie połączenia SOCKS5 używają zdalnego rozwiązywania.
• Nie ma wcześniejszego rozwiązywania przed połączeniem.
• Biblioteki sprawdzone nie po dokumentacji, a po logu domeny testowej.
• Automatyczne sprawdzenie DNS wbudowane w start sesji.
• Dla trybu HTTP proxy sprawdzone, że używany jest CONNECT, a nie podmiana na IP.

Metoda 3. Przeglądarki i przeglądarki antydetekt bez wycieków DNS

Wielka część odbiorców mobilnych proxy pracuje nie w kodzie, a w przeglądarce: konta reklamowe, social media, marketplace'y, multiaccounting. Tu są własne reguły i różnią się między silnikami.

Firefox i jego następcy

Firefox historycznie daje najbardziej przejrzystą kontrolę. Kluczowy parametr w about:config — network.proxy.socks_remote_dns. Przy wartości true nazwy są przekazywane proxy SOCKS do zdalnego rozwiązywania. Przy false — rozwiązywane lokalnie. W wielu starych buildach i profilach jest wyłączony. Drugi parametr — network.trr.mode, który steruje szyfrowanym DNS: wartość 5 całkowicie go wyłącza, co dla pracy przez proxy jest preferowane, bo inaczej przeglądarka może zwracać się do serwera DoH własnym klientem. Trzeci blok — wstępne ładowanie: network.dns.disablePrefetch na true i network.predictor.enabled na false wyłączają spekulatywne rozwiązywanie nazw dla linków na stronie, które inaczej może iść obok proxy przed rzeczywistym przejściem. Przeglądarki antydetekt na silniku Firefox zwykle ustawiają te parametry poprawnie, ale warto sprawdzać po każdym update.

Chrome, Chromium i antydetekty na ich podstawie

Z Chromium historia jest trudniejsza. Pracując przez proxy HTTP, wysyła CONNECT z nazwą — wycieku nie ma. A przy użyciu proxy SOCKS5 przez flagę startową silnik w niektórych konfiguracjach rozwiązuje nazwy lokalnie, i standardowego ustawienia „zdalny DNS” w interfejsie nie ma. Znany trik inżynieryjny — flaga --host-resolver-rules z regułą, która mapuje wszystkie nazwy w stan „nie znaleziono”, wykluczając sam adres proxy. W rezultacie lokalny resolver nie może rozwiązać niczego, a przeglądarka musi przekazać nazwy proxy. Wygląda jak obejście, ale działa niezawodnie. Drugi ważny punkt — ustawienie bezpiecznego DNS w sekcji prywatności: przy włączonym stanie Chromium używa DoH do wybranego dostawcy, a ten ruch nie zawsze idzie przez proxy. Dla pracy przez mobilne proxy trzeba go wyłączyć albo upewnić się w testach, że jest prawidłowo tunelowany. Trzeci — wstępne ładowanie stron: w ustawieniach wydajności jest opcja wstępnego ładowania, która inicjuje zapytania DNS dla linków, w które jeszcze nie kliknąłeś.

Co powinien umieć antydetekt

Dobry antydetekt bierze na siebie całą tę rutynę. Ale jakość implementacji mocno się różni. Oto co sprawdzać przy wyborze i po każdym update:

• Tryb zdalnego DNS dla SOCKS5 włączony domyślnie dla każdego profilu, a nie globalnie.
• Izolacja DNS między profilami. Cache rozwiązanych nazw nie powinien być wspólny: inaczej profil na mobilnym proxy jednego regionu otrzyma IP zcache'owane przez profil na proxy innego regionu.
• Wyłączony lub tunelowany szyfrowany DNS. Zapytaj wsparcie wprost: jak zachowuje się wbudowany DoH przy pracy przez proxy.
• Wyłączony prefetch. Spekulatywne rozwiązywanie nie powinno żyć w profilu, który udaje zwykłego mobilnego użytkownika.
• Wbudowane sprawdzenie dns leak przy starcie profilu lub przynajmniej wygodne przejście do testu.
• Zachowanie przy zerwaniu proxy. Co robi przeglądarka, jeśli proxy jest niedostępne: blokuje połączenia czy wychodzi bezpośrednio? Drugie — katastrofa nie tylko dla DNS.

Rozszerzenia proxy: cienki lód

Rozszerzenia przeglądarki, które przełączają proxy, działają przez API przeglądarki. Potrafią ustawić proxy dla połączeń, ale kontrola nad DNS jest ograniczona możliwościami silnika. Rozszerzenie nie może zmusić Chromium do używania zdalnego DNS dla SOCKS5, jeśli sam silnik tego nie robi w danej konfiguracji. Plus rozszerzenie nie steruje usługami w tle przeglądarki. Dlatego rozszerzenia to akceptowalny wariant dla trybu HTTP mobilnego proxy i szybkich sprawdzeń, ale nie dla poważnej pracy z wrażliwymi kontami.

Konfiguracja profilu krok po kroku

1. Utwórz profil i wskaż mobilne proxy. Preferuj tryb HTTP, jeśli antydetekt nie gwarantuje zdalnego DNS dla SOCKS5.
2. Wyłącz szyfrowany DNS w ustawieniach silnika lub profilu.
3. Wyłącz wstępne ładowanie stron i DNS-prefetch.
4. Jeśli to silnik Firefox-podobny — sprawdź socks_remote_dns ręcznie.
5. Uruchom profil, wyczyść cache i przejdź rozszerzony test dns leak.
6. Odwiedź kilka stron z aktywną analityką i powtórz test: czy pojawiły się nowe resolvery.
7. Zapisz wynik jako wzorzec dla tego profilu.

Metoda 4. Poziom systemowy i infrastruktura: zamykamy wycieki siłą

Wszystkie poprzednie metody działają na zasadzie zaufania: konfigurujemy aplikację i mamy nadzieję, że zachowa się poprawnie. Podejście inżynieryjne jest inne: uczynić wyciek technicznie niemożliwym. Nawet jeśli aplikacja spróbuje wysłać zapytanie DNS bezpośrednio, nie powinno ono wyjść.

Zasada „wszystko zabronione, co nie przez proxy”

Na maszynie roboczej lub serwerze farmy konfiguruje się zaporę sieciową, która blokuje ruch wychodzący na port 53 (UDP i TCP) i port 853 dla wszystkich procesów oprócz wyraźnie dozwolonych. W Windows to reguły połączeń wychodzących w zaporze, w Linux — nftables lub iptables, w macOS — pf. Sens: jeśli przeglądarka lub skrypt spróbuje rozwiązać nazwę lokalnie, dostanie błąd, a nie cichy wyciek. Błąd jest od razu widoczny — zobaczysz go i naprawisz konfigurację aplikacji. Cichy wyciek może żyć miesiącami.

Subtelnostka z DoH: idzie na port 443, którego całkowicie blokować nie można. Rozwiązanie — blokować nie port, a adresy znanych publicznych resolverów DoH dla procesów, które powinny chodzić tylko przez proxy. Wymaga to utrzymywania listy, ale lista zmienia się rzadko.

Izolacja przez kontenery i przestrzenie nazw sieci

Dla deweloperów i właścicieli farm na Linux najpotężniejsze narzędzie — przestrzenie nazw sieci (network namespaces) i kontenery. Idea: każdy worker, każdy profil przeglądarki lub grupa profili żyje we własnej przestrzeni nazw sieci, w której nie ma w ogóle trasy domyślnej do internetu. Jedyna droga na zewnątrz — adres proxy. Cokolwiek aplikacja by próbowała zrobić — rozwiązać nazwę, wyjść po IPv6, otworzyć bezpośrednie połączenie — fizycznie nie ma trasy. To najpewniejszy sposób zagwarantowania braku dns leak na skalę. W Dockerze osiąga się to przez niestandardową sieć bez zewnętrznej bramy plus jawne zezwolenie dostępu tylko do adresu proxy. Dodatkowo w konfiguracji resolvera kontenera można wskazać z góry niedostępny adres, by każda próba lokalnego rozwiązywania padała natychmiast, a nie wisiała na timeoutcie.

IPv6 na poziomie systemowym

Jeśli twoje mobilne proxy działa przez IPv4, a maszyna ma połączenie IPv6, najprostsze i najpewniejsze rozwiązanie — wyłączyć IPv6 na interfejsie, z którego pracują profile proxy, albo zabronić ruchu wychodzącego IPv6 zaporą. Tak, to brutalne. Ale wyklucza całą klasę problemów, w których rekord AAAA w odpowiedzi DNS prowadzi połączenie bezpośrednio.

Systemowy resolver i jego osobliwości

Nowoczesne systemy operacyjne mają wielowarstwowe resolvery. W Windows 11 jest obsługa DoH na poziomie systemu, i jeśli jest włączona dla twojego adaptera, wszystkie lokalne rozwiązywania pójdą do wybranego serwera DoH. Dla maszyny roboczej z proxy trzeba to sobie uświadomić: włączony systemowy DoH zmienia obraz wycieku, ale go nie eliminuje. Android używa funkcji Private DNS — analogiczna historia dla tych, którzy pracują z proxy na urządzeniach mobilnych lub emulatorach. W Linux z systemd-resolved warto sprawdzić, jakie serwery DNS są przypisane do każdego interfejsu, bo resolver potrafi routować zapytania według sufiksów domen między interfejsami, i to tworzy nieoczekiwane ścieżki.

Monitoring jako proces

Na poziomie infrastruktury sprawdzanie dns leak zamienia się z jednorazowego w ciągłe. Co warto wdrożyć:

• Logowanie zablokowanych prób DNS przez zaporę. Każdy wpis w logu — aplikacja, która próbuje rozwiązywać lokalnie. To twoja lista do naprawy.
• Własna domena testowa z unikalnymi subdomenami na sesję i automatyczny alert przy pojawieniu się obcego resolvera.
• Okresowy zrzut ruchu sieciowego na porcie 53 z fizycznego interfejsu — raz dziennie, automatycznie, z alertem przy niezerowym liczniku.
• Sprawdzenie po każdym update przeglądarki, antydetektu, bibliotek. Update'y to główne źródło regresji: deweloperzy zmieniają domyślne wartości, włączają nowe funkcje wstępnego ładowania, dodają szyfrowany DNS.

Lista kontrolna poziomu systemowego

• Ruch wychodzący na porty 53 i 853 zablokowany dla procesów roboczych.
• Znane publiczne adresy DoH zablokowane dla tych samych procesów.
• IPv6 wyłączony lub zablokowany na interfejsach roboczych.
• Krytyczne workery izolowane w przestrzeniach nazw sieci bez bezpośredniej trasy.
• Logi zapory dotyczące DNS zbierane i przeglądane.
• Domena testowa i alertowanie skonfigurowane.

Typowe błędy: czego nie należy robić

Błąd 1. Sprawdzać tylko IP

Najbardziej masowy. Człowiek widzi adres operatora komórkowego na stronie sprawdzania IP i uważa zadanie za rozwiązane. Ale sprawdzenie IP odpowiada tylko na pytanie „skąd przyszło połączenie”, a nie „skąd przyszły zapytania DNS”. To różne pytania z różnymi odpowiedziami.

Błąd 2. Wpisać publiczny DNS i się uspokoić

Logika zrozumiała: skoro dostawca widzi moje zapytania, wskażę publiczny resolver. Ale dla pracy przez proxy to nie rozwiązanie, a zamiana jednego wycieku na inny. Zapytania i tak wychodzą z twojego rzeczywistego IP, tyle że do innego obserwatora. A do tego publiczne resolvery aktywnie używają ECS i przekazują twoją podsieć serwerom autorytatywnym. Rozbieżność między stroną DNS a stroną połączenia pozostaje.

Błąd 3. Używać SOCKS5 bez zdalnego DNS

Schemat socks5 zamiast socks5h w kodzie, wyłączony socks_remote_dns w przeglądarce, antydetekt z domyślnym lokalnym rozwiązywaniem. Tysiące projektów żyją z tym błędem latami.

Błąd 4. Uważać szyfrowany DNS za rozwiązanie problemu

DoH chroni treść zapytań przed dostawcą. Ale przy pracy przez proxy tworzy osobny kanał, który nie idzie przez proxy. Szyfrowanie nie równa się prawidłowy routing.

Błąd 5. Ignorować wstępne ładowanie i usługi w tle

Przeglądarka rozwiązuje nazwy linków, których jeszcze nie otworzyłeś. Antywirus sprawdza URL. Aktualizator szuka serwera aktualizacji. Wszystko to zapytania DNS, które mogą iść obok. Sprawdzenie pojedynczym testem takich rzeczy nie łapie.

Błąd 6. Wspólny cache DNS między profilami

Jeśli dwa profile na proxy różnych regionów dzielą cache, drugi profil połączy się z węzłem CDN wybranym dla pierwszego regionu. Izolacja profili powinna obejmować DNS.

Błąd 7. Nie testować po aktualizacjach

Nowa wersja przeglądarki włączyła bezpieczny DNS domyślnie. Zaktualizowana biblioteka zmieniła zachowanie SOCKS. Update antydetektu zresetował ustawienia silnika. Wszystko to realne scenariusze, które wychodzą tylko przy ponownym sprawdzeniu.

Błąd 8. Zezwalać na bezpośrednie wyjście przy niedostępności proxy

Ustawienia typu „jeśli proxy nie odpowiada, idź bezpośrednio” zamieniają każdą awarię w pełną deanonymizację sesji, począwszy od DNS. Prawidłowe zachowanie — blokada połączeń do przywrócenia proxy.

Błąd 9. Ręczne rozwiązywanie „dla szybkości”

Niektóre scrapery rozwiązują domenę raz i dalej chodzą po IP, by oszczędzić na DNS. Oprócz wycieku samego zapytania, otrzymują IP wybrany przez geo-DNS dla ich rzeczywistego regionu, a potem gonią ruch przez mobilne proxy do „obcego” węzła CDN. Oszczędność milisekund obraca się w niekonsystentny profil.

Narzędzia i zasoby

Testy wycieków online

Serwisy sprawdzania dns leak dzielą się na podstawowe i rozszerzone. Podstawowe robią jedno-dwa zapytania i nadają się do szybkiego rozeznania. Rozszerzone generują dziesiątki unikalnych subdomen i wykrywają częściowe wycieki. Do pracy wybieraj te, które pokazują nie tylko IP resolvera, ale i jego przynależność: organizację, system autonomiczny, kraj. Dobry test pokazuje też osobno IPv4 i IPv6 i potrafi sprawdzić zachowanie przy powtarzalnych zapytaniach.

Analizatory ruchu

Wireshark — graficzny analizator z filtrami typu dns lub udp.port == 53. tcpdump — konsolowy odpowiednik dla serwerów i maszyn Linux. Oba pozwalają zobaczyć prawdę: co naprawdę opuszcza interfejs sieciowy. Dla DoH dodatkowo patrz na połączenia TLS do adresów publicznych resolverów.

Własny autorytatywny DNS

Dla monitoringu na skalę: dowolny lekki serwer DNS z logowaniem zapytań (CoreDNS, Unbound w trybie autorytatywnym, BIND, kompaktowe serwery w Go lub Pythonie) plus własna domena. Koszty minimalne, a wynik — stały nadzór nad wszystkimi workerami i profilami.

Narzędzia wiersza poleceń

dig i nslookup pokazują, do jakiego resolvera zwraca się system i co odpowiada. resolvectl w Linux z systemd-resolved pokazuje konfigurację DNS po interfejsach. curl z flagą szczegółowego wyjścia pokazuje, czy przekazuje nazwę proxy, czy rozwiązuje sam. W Windows ipconfig /displaydns pokaże zawartość cache, a Get-DnsClientServerAddress w PowerShell — przypisane serwery po adapterach.

Zapory sieciowe

Wbudowana zapora Windows z regułami po programach, nftables i iptables w Linux, pf w macOS. Dla wygody zarządzania regułami po aplikacjach istnieją graficzne nakładki. Kluczowe wymaganie — możliwość blokowania portów dla konkretnych procesów i prowadzenia logu blokad.

Konteneryzacja

Docker i Podman z niestandardowymi sieciami, przestrzenie nazw sieci Linux przez ip netns, a dla farm przeglądarek — orkiestratory profili obsługujące izolację sieci na poziomie profilu. Zamieniają regułę „tylko przez proxy” z ustawienia w gwarancję architektoniczną.

Możliwości po stronie serwisu proxy

Zwracaj uwagę na to, co oferuje sam dostawca mobilnych proxy: obsługę SOCKS5 ze zdalnym rozwiązywaniem nazw, tryb HTTP z prawidłową obsługą CONNECT, stabilność DNS po stronie operatora, brak podmiany odpowiedzi DNS po stronie infrastruktury. Warto dopytać wsparcie, przez jakie resolvery rozwiązywane są nazwy przy zdalnym rozwiązywaniu — prawidłowa odpowiedź: przez resolvery operatora komórkowego, do którego sieci podłączony jest modem.

Case studies i wyniki

Case 1. Farma kont reklamowych i niewidzialna przyczyna banów

Zespół arbitrażowców prowadził około 120 kont reklamowych na mobilnych proxy przez popularny antydetekt. Średni czas życia konta do blokady utrzymywał się na poziomie 9–12 dni przy z pozoru bezbłędnej konfiguracji: mobilne IP właściwego regionu, staranne fingerprinty, rozgrzewanie. Audyt wykazał, że po kolejnym update antydetektu w silniku włączony został szyfrowany DNS, i wszystkie profile rozwiązywały nazwy przez ten sam publiczny resolver DoH z rzeczywistego IP biura. 120 „niezależnych” użytkowników z różnych miast rozwiązywało nazwy z jednego punktu. Po wyłączeniu DoH, włączeniu zdalnego DNS i zablokowaniu portu 53 zaporą średni czas życia kont wzrósł do 30+ dni, a udział wczesnych blokad w pierwszym tygodniu spadł około trzykrotnie. Koszt naprawy — dwie godziny pracy jednego specjalisty.

Case 2. Scraper marketplace'u i zagadkowe ceny geo

Deweloper zbierał ceny z dużego marketplace'u po regionach przez mobilne proxy różnych miast. Dane nie zgadzały się z tym, co widzieli realni użytkownicy w tych regionach: część cen i dostępności odpowiadała zupełnie innemu miastu. Przyczyna okazała się w ciągu połączenia: biblioteka requests ze schematem socks5 bez h. Nazwy były rozwiązywane lokalnie w mieście dewelopera, geo-DNS marketplace'u zwracał węzeł jego regionu, i dalej zapytania przez mobilne proxy innego miasta trafiały na „obcy” węzeł, który oddawał wydanie regionalne według własnej logiki. Zamiana jednej litery w konfiguracji i dodanie automatycznego sprawdzenia DNS przy starcie każdego workera przywróciły poprawność danych. Efekt uboczny: spadł udział zapytań, na które marketplace odpowiadał captchą — sesje stały się bardziej konsystentne.

Case 3. Testowanie reklam pod regionalne grupy odbiorców

Agencja marketingowa sprawdzała, jak wyświetlają się reklamy i landing page'e użytkownikom różnych regionów, pracując przez mobilne proxy i przeglądarkę Chromium z połączeniem SOCKS5. Część sprawdzeń pokazywała treści nie z tego regionu. W logach własnej domeny testowej agencji resolvery należały do dostawcy biura. Przejście na tryb HTTP tych samych mobilnych proxy, w którym Chromium przekazuje nazwy przez CONNECT, plus wyłączenie wstępnego ładowania stron usunęło rozbieżność. Dodatkowy bonus — stabilne wyniki sprawdzeń bez powtórnych przebiegów zaoszczędziły zespołowi około 15 procent czasu na regularnych audytach.

Case 4. Multiaccounting w social media i wspólny cache

Operator dziesiątek kont w social media zauważył, że konta pracujące tego samego dnia zaczęły być blokowane grupowo. Analiza wykazała dwa czynniki na warstwie DNS: antydetekt używał wspólnego cache DNS między profilami, a część profili była na SOCKS5 bez zdalnego rozwiązywania. W efekcie profile na proxy różnych regionów łączyły się z tymi samymi węzłami CDN, a część z nich jeszcze rozwiązywała nazwy z jednego rzeczywistego IP. Po włączeniu izolacji cache po profilach i przełożeniu wszystkich połączeń na zdalny DNS grupowe blokady ustały; w kolejnych dwóch miesiącach straty kont wróciły do poziomu charakterystycznego dla starannej pracy ręcznej.

Wspólny wniosek z case studies

We wszystkich czterech historiach proxy były sprawne. Problem żył po stronie klienta i kosztował tygodnie pracy, budżety i konta. Naprawa za każdym razem zajmowała godziny. Takie proporcje — charakterystyczna cecha właśnie dns leak: problem jest niewidoczny bez specjalnego sprawdzenia, ale naprawia się prosto, jeśli wiesz, gdzie patrzeć.

FAQ: trudne pytania o wycieki DNS

Jeśli strona nie otrzymuje moich zapytań DNS, jak w ogóle dowiaduje się o wycieku?

Trzema pośrednimi drogami. Pierwsza — unikalne subdomeny testowe: strona może zmusić twoją przeglądarkę do rozwiązania domeny, którą sama kontroluje, i zobaczyć, z jakiego resolvera przyszło zapytanie. Druga — geo-DNS i CDN: jeśli przychodzisz na węzeł przeznaczony dla innego regionu, ta rozbieżność z twoim IP jest widoczna po stronie infrastruktury. Trzecia — EDNS Client Subnet: publiczne resolvery przekazują podsieć klienta serwerom autorytatywnym, i nie zgadza się ona z podsiecią połączenia. Żadna z tych dróg nie wymaga dostępu do twojego dostawcy.

Mobilne proxy rozwiązuje nazwy przez operatora. To dobrze czy źle?

To idealne dla wiarygodności. Realny abonent sieci komórkowej rozwiązuje nazwy przez resolvery operatora, i jego połączenia przychodzą z adresów tego samego operatora. Kiedy twoje proxy robi to samo, strona DNS i strona połączenia należą do jednej sieci. Właśnie ten stan powinieneś widzieć w testach: resolvery operatora, IP operatora, jeden region.

Czym tryb HTTP mobilnego proxy jest lepszy od SOCKS5 z punktu widzenia DNS?

Tym, że w trybie HTTP nazwa hosta jest przekazywana proxy z definicji protokołu — w CONNECT dla HTTPS i w URL dla HTTP. Klient nie może przypadkowo rozwiązać nazwy lokalnie, poza egzotycznymi przypadkami w rodzaju skryptów PAC. W SOCKS5 zdalne rozwiązywanie to opcja, którą klient musi wybrać jawnie, i wiele klientów tego domyślnie nie robi. Jeśli nie jesteś pewien zachowania konkretnej przeglądarki lub biblioteki, tryb HTTP jest bezpieczniejszy. SOCKS5 jest wygodniejszy dla protokołów nie-HTTP, ale wymaga kontroli.

Czy wystarczy po prostu wyłączyć bezpieczny DNS w przeglądarce?

Nie. To zamyka jeden kanał — DoH przeglądarki. Zostają lokalne rozwiązywanie dla SOCKS5, wstępne ładowanie, usługi w tle, systemowy DoH w systemie i IPv6. Wyłączenie bezpiecznego DNS to krok konieczny, ale niewystarczający. Wystarczające jest tylko potwierdzenie rozszerzonym testem i, w idealnym przypadku, blokada bezpośredniego DNS na poziomie systemu.

Co robić, jeśli w teście pojawiają się resolvery, które nie należą ani do mnie, ani do operatora?

Rozgryźć po łańcuchu. Najpierw ustal organizację po IP: jeśli to publiczny serwis DNS, szukaj włączonego DoH w przeglądarce lub systemie. Jeśli to nieznany hosting, być może infrastruktura proxy używa własnych resolverów zamiast operatorskich — dopytać dostawcę. Jeśli to twój dostawca, ale nie ten resolver, który widziałeś w linii bazowej, — być może IPv6 lub inny adapter. Każdy nieoczekiwany resolver ma wyjaśnienie, i trzeba je znaleźć, a nie ignorować.

Czy dns leak wpływa na szybkość pracy przez proxy?

Wpływa, i często w nieoczekiwaną stronę. Przy lokalnym rozwiązywaniu geo-DNS wybiera węzeł CDN blisko twojej rzeczywistej lokalizacji, a ruch potem idzie przez sieć komórkową innego regionu do tego węzła — trasa jest dłuższa niż optymalna. Przy zdalnym rozwiązywaniu węzeł jest wybierany blisko wyjścia proxy, i droga od proxy do serwera jest krótsza. Więc prawidłowa konfiguracja DNS zwykle nie spowalnia, a w niektórych przypadkach przyspiesza ładowanie.

Jak testować dns leak w scenariuszach zautomatyzowanych bez przeglądarki?

Najpewniejsza droga — własna domena testowa. Przy starcie każdego workera skrypt odwołuje się przez proxy do unikalnej subdomeny, a twój autorytatywny serwer DNS loguje, z jakiego resolvera przyszło zapytanie. Skrypt potem czyta log przez API i porównuje adres resolvera z oczekiwanym zakresem operatora. Jeśli nie ma zgodności, sesja się nie uruchamia. To zamienia sprawdzenie z ręcznego w kontraktowe: worker nie ma prawa pracować, dopóki nie udowodnił czystości DNS.

Jak zmienia się obraz wraz z rozprzestrzenianiem ECH i szyfrowanego DNS w 2026 roku?

Krajobraz zmierza w stronę „DNS staje się ważniejszy”. ECH zależy od rekordów DNS typu HTTPS, przeglądarki włączają szyfrowany DNS domyślnie, systemy operacyjne dodają systemowy DoH i DoQ. Dla zwykłego użytkownika to plus dla prywatności. Dla tych, którzy pracują przez proxy, oznacza to więcej ruchu DNS, więcej niezależnych klientów DNS wewnątrz systemu i więcej punktów, gdzie zapytanie może wyjść obok proxy. Systemy antyfraudowe z kolei coraz aktywniej używają konsystencji między stroną DNS a stroną połączenia jako sygnału. Wniosek: dyscyplina w pracy z DNS z „wskazanej” zamienia się w „obowiązkową”.

Czy można zaufać przeglądarce antydetekt, która deklaruje ochronę przed dns leak?

Zaufać — tak, sprawdzać — obowiązkowo. Deklaracja w marketingu nie znosi regresji po aktualizacjach, różnic między silnikami i specyfiki twojej konfiguracji proxy. Sprawdzaj każdy profil po utworzeniu i po każdym update przeglądarki. Jeden rozszerzony test zajmuje minutę, a odtworzenie spalonej farmy — tygodnie.

Zakończenie: DNS jako fundament czystej sesji

Podsumujmy. Proxy zmienia adres, z którego przychodzi połączenie, ale nie gwarantuje, że rozwiązywanie nazw idzie tą samą drogą. Zapytanie DNS wykonuje się wcześniej niż połączenie, i właśnie w tej szczelinie rodzi się dns leak. Dla użytkowników mobilnych proxy jest to szczególnie krytyczne: cała wartość mobilnego IP tkwi w jego podobieństwie do realnego abonenta, a realny abonent rozwiązuje nazwy przez swojego operatora. Rozbieżność między stroną DNS a stroną połączenia zdradza użycie proxy pewniej niż wiele innych oznak.

Omówiliśmy, jak cieknie DNS w różnych scenariuszach: SOCKS bez zdalnego rozwiązywania, szyfrowany DNS w przeglądarkach i systemach, wstępne ładowanie, wspólny cache, IPv6, skrypty PAC i wcześniejsze rozwiązywanie w kodzie. Podaliśmy cztery metody, które działają razem: diagnostyka z linią bazową i rozszerzonym testem, prawidłowa konfiguracja klientów i bibliotek, konfiguracja przeglądarek i antydetektów, i wreszcie wymuszona ochrona na poziomie zapory i izolacji sieci. Każda metoda sama w sobie zamyka część problemu. Wszystkie razem — czynią wyciek technicznie niemożliwym.

Twoje następne kroki

1. Dziś: zdejmij linię bazową bez proxy, potem przejdź rozszerzony test dns leak w każdym profilu roboczym i każdym skrypcie. Zapisz wyniki.
2. W tym tygodniu: sprawdź wszystkie ciągi połączenia w kodzie na socks5 bez h, wyłącz szyfrowany DNS i wstępne ładowanie w przeglądarkach, upewnij się co do izolacji cache między profilami.
3. W tym miesiącu: zablokuj bezpośredni DNS na poziomie systemu dla procesów roboczych, wyłącz lub zablokuj IPv6 na interfejsach roboczych, postaw własną domenę testową z logowaniem.
4. Stale: powtarzaj sprawdzenie po każdym update przeglądarki, antydetektu i bibliotek. Zamień je w rytuał, jak sprawdzanie IP.

Dobre mobilne proxy daje ci wiarygodny adres i wiarygodne resolvery operatora. Twoim zadaniem jest nie roztrwonić tej przewagi na ostatnim metrze, wewnątrz własnego systemu. Skonfiguruj DNS raz prawidłowo, uczyń sprawdzanie nawykiem, a cała kategoria niewyjaśnionych blokad po prostu zniknie z twojej praktyki. Czy nie po to czytałeś ten przewodnik do końca?