Spis treści

Wyobraź sobie taką sytuację. Podłączyłeś proxy w odpowiednim regionie, sprawdziłeś adres IP – wszystko się zgadza, miasto i kraj są zgodne. Ale docelowa strona uparcie pokazuje Ci nie tę treść, a system antyfraudowy oznacza sesję jako podejrzaną. Brzmi znajomo? Najprawdopodobniej zetknąłeś się z jednym z najpodstępniejszych zjawisk podczas pracy z proxy – wyciekiem DNS lub nieprawidłową ścieżką rozwiązywania nazw domen.

Ten artykuł to wyczerpujący przewodnik po tym, jak dokładnie działa przekształcanie nazwy domeny na adres IP, gdy ruch przechodzi przez proxy. Wyjaśnimy, czym zasadniczo różnią się schematy socks5 i socks5h, kto i na którym etapie wysyła zapytanie DNS, dlaczego strona czasami widzi zupełnie inny region, niż oczekiwałeś, oraz jak skonfigurować zdalny resolver w popularnych klientach i bibliotekach. Temat wąski, ale cholernie ważny. To właśnie na rozwiązywaniu nazw rozbijają się tysiące, pozornie poprawnie skonfigurowanych konfiguracji.

Wprowadzenie: dlaczego proxy jest podłączone, a strona widzi inny region

Zacznijmy od objawu, który sprowadza większość czytelników do tego tematu. Skonfigurowałeś proxy. Adres IP został prawidłowo podmieniony – łatwo to sprawdzić na dowolnej usłudze wykrywania IP. A jednak coś jest nie tak: strona wyświetla lokalizację z innego kraju, CDN kieruje Cię do nieoczekiwanego węzła, a czasem system bezpieczeństwa docelowego zasobu blokuje zapytanie bez widocznej przyczyny.

Przyczyna prawie zawsze jest ta sama. Twój ruch HTTP lub aplikacyjny rzeczywiście przechodzi przez proxy, ale zapytanie DNS – to zapytanie, które zamienia nazwę, np. example.com, na konkretny adres IP – omija proxy i wysyłane jest bezpośrednio z Twojego komputera. To zapytanie zdradza Cię bez reszty.

Dlaczego tak się dzieje? Ponieważ rozwiązywanie nazwy i przesyłanie danych to dwa różne etapy, które mogą iść różnymi trasami. Wiele klientów domyślnie rozwiązuje nazwę lokalnie, a przez proxy wysyła już gotowe połączenie na adres IP. Z punktu widzenia sieci jest logiczne. Z punktu widzenia prywatności i geolokalizacji – katastrofa.

Pod koniec tego materiału będziesz wiedzieć:

  • kto dokładnie wykonuje rozwiązywanie nazwy – system operacyjny, biblioteka aplikacji, przeglądarka czy sam serwer proxy;
  • czym różni się schemat socks5 od socks5h na poziomie protokołu i dlaczego jedna litera zmienia wszystko;
  • jak metoda CONNECT w proxy HTTP rozwiązuje problem resolvera prawie automatycznie;
  • jakimi kanałami wycieka DNS nawet przy pozornie poprawnej konfiguracji;
  • jak włączyć zdalny resolver w curl, Python, Node.js, Go, Chrome, Firefox, Selenium i Playwright;
  • jak sprawdzić faktyczną ścieżkę resolvera za pomocą narzędzi takich jak dig, nslookup i tcpdump.

Od razu ustalmy granice. Nie omawiamy, który publiczny serwer DNS jest lepszy, ani nie doradzamy konkretnych dostawców. Naszym przedmiotem jest wyłącznie ścieżka resolvera podczas pracy przez proxy. Ni mniej, ni więcej.

Podstawy: czym jest rozwiązywanie nazw i kto je wykonuje

Aby zrozumieć wycieki, najpierw trzeba mocno opanować mechanikę resolvera. Rozłożymy ją na części.

Czym jest rozwiązywanie nazwy domeny

Komputery komunikują się za pomocą adresów IP, a ludzie – za pomocą nazw. Resolver (z ang. resolve – rozwiązać) to proces przekształcania czytelnej dla człowieka nazwy, np. shop.example.com, na adres IP maszyny, np. 93.184.216.34. Bez tego kroku żadne połączenie nie jest możliwe: przeglądarka nie wie, z którym serwerem się połączyć, dopóki nie otrzyma adresu IP.

Resolver to osobna transakcja sieciowa. Zazwyczaj używa protokołu DNS przez UDP lub TCP na porcie 53. Klient wysyła zapytanie do resolvera, resolver zwraca odpowiedź. Kluczowy moment: kto dokładnie wysyła to zapytanie i którą trasą – to jest centralne pytanie całego naszego tematu.

Czterech możliwych wykonawców resolvera

Gdy aplikacja chce połączyć się z example.com, resolver może wykonać jeden z czterech uczestników. Omówimy każdego.

1. System operacyjny

Większość aplikacji nie rozwiązuje nazw samodzielnie. Korzystają z funkcji systemowej – w świecie C jest to getaddrinfo. System operacyjny ma własny resolver (stub resolver), który wie, do którego serwera DNS się zwrócić, prowadzi lokalną pamięć podręczną i uwzględnia plik hosts. To najczęstsza ścieżka. I najniebezpieczniejsza z punktu widzenia wycieków: systemowy resolver domyślnie chodzi bezpośrednio do sieci, ignorując Twoje proxy.

2. Biblioteka aplikacji

Niektóre programy i biblioteki mają własną logikę resolvera, która może albo przekazać zadanie systemowi operacyjnemu, albo wykonać je samodzielnie, albo – i to jest najważniejsze – przekazać nazwę serwerowi proxy, aby resolver nastąpił po stronie zdalnej. To właśnie ten mechanizm realizują schematy socks5h i proxy-host.

3. Przeglądarka

Nowoczesne przeglądarki to odrębny wszechświat. Mają własną politykę resolvera, własną pamięć podręczną DNS, mechanizmy takie jak DoH (DNS over HTTPS), wstępne ładowanie połączeń i WebRTC. Przeglądarka może rozwiązywać nazwę całkowicie niezależnie od ustawień systemowych, co rodzi całą klasę wycieków.

4. Sam serwer proxy

Idealny scenariusz dla prywatności. Klient w ogóle nie rozwiązuje nazwy. Przekazuje serwerowi proxy ciąg znaków z nazwą hosta, a proxy już sam, po swojej stronie, wykonuje resolver i łączy się z odpowiednim adresem IP. Z punktu widzenia docelowej strony zapytanie DNS pochodzi z sieci proxy, a nie z Twojej.

Kluczowa analogia

Wyobraź sobie, że wysyłasz kuriera (proxy) z paczką do innego miasta. Są dwa sposoby. Pierwszy: samodzielnie znajdujesz dokładny adres odbiorcy w książce telefonicznej u siebie w domu, zapisujesz współrzędne na paczce i przekazujesz kurierowi tylko współrzędne. Książka telefoniczna w Twoim mieście może podać inny adres niż ta w mieście docelowym – a Ty tego nie zauważysz. Drugi sposób: przekazujesz kurierowi tylko nazwę odbiorcy, a on znajduje adres już na miejscu, w lokalnej książce telefonicznej. Drugi sposób to zdalny resolver. Gwarantuje on, że adres zostanie ustalony z właściwego punktu sieci.

socks5 vs socks5h: gdzie zapada decyzja o resolverze

Teraz dochodzimy do sedna tematu. Różnica między socks5 a socks5h to nie kosmetyka ani synonim. To fundamentalnie różne ścieżki resolvera, choć protokół SOCKS5 pod maską jest ten sam.

Co mówi protokół SOCKS5

Sam protokół SOCKS5 jest elastyczny. W komendzie nawiązania połączenia klient określa typ adresu docelowego. Możliwe są trzy opcje:

  • adres IPv4 – klient przekazuje gotowy adres IP;
  • adres IPv6 – to samo, ale dla IPv6;
  • nazwa domeny – klient przekazuje ciąg znaków z nazwą, a wtedy resolver musi wykonać serwer proxy.

Oznacza to, że sam protokół obsługuje zarówno lokalny, jak i zdalny resolver. Pytanie tylko, jaki typ adresu wyśle klient. I tutaj wchodzi w grę konwencja nazewnictwa schematów.

Schemat socks5: resolver lokalny

Gdy klient używa schematu socks5 (bez litery h), zgodnie z przyjętą konwencją oznacza to: rozwiązuj nazwę lokalnie. Klient najpierw pyta swojego resolvera (zazwyczaj systemowego) o adres IP example.com, otrzymuje go, a następnie przekazuje serwerowi proxy gotowy adres IPv4 lub IPv6.

Co widzi docelowa strona? Widzi połączenie od proxy – to prawda. Ale zapytanie DNS wyszło z Twojej sieci, z Twojej strony, przez Twój lokalny resolver. Jeśli Twój resolver jest geograficznie lub logicznie związany z Twoim regionem, docelowa infrastruktura przez CDN i geolokalizację DNS może określić właśnie Twój region, a nie region proxy. Stąd objaw ze wstępu.

Schemat socks5h: resolver zdalny

Litera h w socks5h oznacza hostname – nazwę hosta. Ten schemat mówi klientowi: nie rozwiązuj sam, przekaż nazwę serwerowi proxy. Klient wysyła komendę z typem adresu – nazwą domeny, a serwer proxy wykonuje resolver po swojej stronie.

Co teraz widzi docelowa strona? Zapytanie DNS pochodzi od resolvera, którego używa proxy, czyli z sieci proxy. Geolokalizacja DNS wskazuje na region proxy. Twój lokalny resolver w ogóle nie jest zaangażowany i nic nie wie o tym, gdzie się wybierasz. To prawidłowa, czysta ścieżka dla większości zadań.

Tabela porównawcza mechaniki

Zbierzemy różnice w zwartej formie:

  • socks5: resolver wykonuje klient (OS/biblioteka). Proxy otrzymuje adres IP. Zapytanie DNS wychodzi z Twojej sieci. Możliwa geograficzna desynchronizacja i wyciek.
  • socks5h: resolver wykonuje proxy. Proxy otrzymuje nazwę. Zapytanie DNS wychodzi z sieci proxy. Region jest spójny, wycieku brak.

Zapamiętaj prostą zasadę: jeśli zależy Ci na prywatności i poprawności geolokalizacji – zawsze socks5h. Jedna litera oszczędza godziny debugowania.

Dlaczego przyjęto taką konwencję

Historyczna ciekawostka pomaga w zrozumieniu. Początkowo klienci SOCKS rozwiązywali nazwy sami, ponieważ wczesne wersje protokołu (SOCKS4) nie umiały przesyłać nazw. SOCKS5 dodał obsługę nazw domen, ale ekosystem narzędzi wprowadził przyrostek h, aby wyraźnie odróżnić zachowanie. W ten sposób narodziła się para socks5 / socks5h, którą dziś rozumieją curl, Python i wiele klientów HTTP. To de facto standard nazewnictwa, a nie część RFC.

Proxy HTTP i HTTPS: dlaczego metoda CONNECT rozwiązuje nazwę na proxy

SOCKS to nie jedyny typ proxy. Ogromna część zadań roboczych korzysta z proxy HTTP. I tutaj mechanika resolvera jest inna, a w wielu przypadkach lepsza.

Zwykłe żądanie HTTP przez proxy

Gdy odwiedzasz zasób HTTP (bez szyfrowania) przez proxy HTTP, klient wysyła do proxy pełne żądanie z absolutnym adresem URL. Linia żądania zawiera nazwę hosta. Proxy widzi nazwę, sam ją rozwiązuje i łączy się z serwerem. Oznacza to, że przy zwykłym proxy HTTP resolver naturalnie odbywa się po stronie proxy. Klient nie musi znać adresu IP.

Metoda CONNECT dla HTTPS

Z HTTPS sprawa jest ciekawsza. Zaszyfrowanego ruchu proxy nie może odczytać – i nie powinno. Dlatego dla HTTPS używa się specjalnej metody CONNECT. Klient wysyła do proxy komendę w stylu CONNECT example.com:443. Zwróć uwagę – tutaj przekazywana jest nazwa hosta, a nie adres IP.

Co dzieje się dalej? Serwer proxy otrzymuje nazwę, rozwiązuje ją po swojej stronie, otwiera tunel TCP do docelowego adresu IP i staje się przezroczystą rurą. Wewnątrz tej rury odbywa się już pełne uzgadnianie TLS między Twoim klientem a serwerem docelowym – proxy go nie odszyfrowuje.

Kluczowy wniosek: przy prawidłowej implementacji proxy HTTP z metodą CONNECT, resolver domyślnie jest zdalny. Nazwa trafia na proxy, proxy rozwiązuje ją samodzielnie. To jeden z powodów, dla których proxy HTTP dla ruchu HTTPS często działa poprawniej od razu po wyjęciu z pudełka niż nieprawidłowo skonfigurowane SOCKS.

Zastrzeżenie dotyczące optymalizacji klienta

Jest ważny niuans. Niektórzy klienci, dążąc do optymalizacji połączenia, i tak rozwiązują nazwę lokalnie przed wysłaniem CONNECT, a następnie przekazują w CONNECT już adres IP zamiast nazwy. Formalnie jest to dozwolone, ale zabija całą korzyść ze zdalnego resolvera. Dlatego nawet z proxy HTTP nie można ślepo ufać zachowaniu – trzeba je sprawdzać. O metodach sprawdzania porozmawiamy w osobnym rozdziale.

Proxy HTTPS jako osobny termin

Nie myl dwóch znaczeń. Czasami proxy HTTPS oznacza proxy, które proxyuje ruch HTTPS (przez CONNECT). A czasami – proxy, z którym połączenie samo jest szyfrowane przez TLS (czyli kanał klient-proxy jest zabezpieczony). To różne rzeczy. Z punktu widzenia resolvera ważniejsze jest pierwsze: jak przekazywana jest nazwa docelowa. Szyfrowanie kanału do proxy nie wpływa bezpośrednio na ścieżkę resolvera, choć chroni sam fakt przekazania nazwy przed obserwatorem między Tobą a proxy.

Wycieki DNS: mechanika powstawania i typowe scenariusze

Teraz najciekawsze – anatomia wycieków. Wyciek DNS to sytuacja, w której zapytanie DNS omija proxy, ujawniając Twój prawdziwy resolver, region lub sam fakt odwiedzenia konkretnej domeny. Przeanalizujemy scenariusze po kolei, ponieważ każdy wymaga innego leczenia.

Scenariusz 1: systemowy resolver omija proxy

Najczęstszy przypadek. Skonfigurowałeś aplikację na socks5 (bez h) albo klient w ogóle nie obsługuje zdalnego resolvera. Aplikacja wywołuje systemowy getaddrinfo, system operacyjny wysyła zapytanie DNS do swojego resolvera bezpośrednio przez sieć, z pominięciem proxy. Dane później idą przez proxy, ale nazwa już wyciekła.

Jak rozpoznać: na proxy przychodzą połączenia na adres IP, a nie na nazwę. W zrzucie sieciowym Twojej maszyny widać wychodzące pakiety na port 53, które nie są owinięte w tunel proxy.

Leczenie: przejść na socks5h, włączyć zdalny resolver w kliencie albo odizolować aplikację tak, aby nie miała bezpośredniego dostępu do sieci dla DNS.

Scenariusz 2: WebRTC w przeglądarce

WebRTC to technologia czasu rzeczywistego do audio, wideo i przesyłania danych bezpośrednio między przeglądarkami. Do nawiązania połączenia WebRTC używa mechanizmu ICE, który zbiera kandydatów – między innymi rozwiązuje hosty serwerów STUN i może inicjować zapytania omijające skonfigurowane proxy. Historycznie WebRTC był znany z tego, że ujawniał prawdziwe adresy nawet przy działającym proxy. Chociaż nowoczesne przeglądarki znacznie zaostrzyły politykę, ryzyko pozostaje przy nieostrożnej konfiguracji.

Leczenie: kontrola polityki WebRTC w przeglądarce, wyłączenie lub ograniczenie przetwarzania kandydatów ICE, korzystanie z ustawień przeglądarki, które zmuszają cały ruch, w tym WebRTC, do przechodzenia przez proxy.

Scenariusz 3: wbudowany DoH w przeglądarce

Nowoczesne przeglądarki obsługują DNS over HTTPS – resolver przez zaszyfrowane żądanie HTTPS do swojego dostawcy DoH. Problem polega na tym, że to żądanie może iść z pominięciem Twojego schematu SOCKS, bezpośrednio z maszyny, jeśli przeglądarka jest skonfigurowana do resolvera przez własny DoH i jednocześnie nie owija tego ruchu w proxy. Powstaje paradoks: nazwa jest rozwiązywana szyfrowanie i prywatnie od dostawcy, ale omija Twoje proxy, co dla zadań geolokalizacyjnych jest najgorsze z możliwych. Ten mechanizm szczegółowo omówimy w rozdziale o DoH.

Scenariusz 4: równoległa ścieżka IPv6

Najbardziej podstępny scenariusz. Twoje proxy działa na IPv4, skonfigurowałeś zdalny resolver. Ale maszyna ma działające IPv6, a klient, zgodnie z algorytmem Happy Eyeballs (jednoczesne próby na IPv4 i IPv6), próbuje rozwiązać rekordy AAAA i łączyć się przez IPv6 bezpośrednio, omijając proxy. Część ruchu i DNS wycieka. Region się rozjeżdża, połączenie częściowo idzie nie tam, gdzie trzeba.

Leczenie: wyłączyć IPv6 dla aplikacji korzystającej z proxy albo upewnić się, że proxy obsługuje IPv6 i cały ruch, w tym AAAA-resolver, idzie przez nie. Dla wielu zadań łatwiej jest wymusić na kliencie tylko IPv4.

Scenariusz 5: pamięć podręczna i wstępne ładowanie

Przeglądarki i systemy operacyjne agresywnie buforują DNS i z wyprzedzeniem nawiązują połączenia (preconnect, prefetch). Jeśli przed skonfigurowaniem proxy pamięć podręczna się zapełniła, aplikacja może używać starych wpisów lub wcześniej nawiązanych połączeń z pominięciem nowej konfiguracji. Drobnostka, ale podczas debugowania potrafi doprowadzić do szału.

Leczenie: wyczyszczenie pamięci podręcznej DNS systemu operacyjnego i przeglądarki, restart, wyłączenie agresywnego wstępnego ładowania na czas diagnostyki.

Ogólna prawidłowość wycieków

Zauważyłeś wspólny wzorzec? Wszystkie wycieki sprowadzają się do jednego: istnieje kanał, którym nazwa lub połączenie wychodzi nie przez proxy. Zadaniem inżyniera jest znalezienie i zamknięcie wszystkich takich kanałów. Wyciek to zawsze niedomknięte drzwi, a nie mistycyzm.

Praktyka narzędziowa: jak włączyć zdalny resolver

Przechodzimy do konkretów. Omówimy poszczególnych klientów i pokażemy, jak włączyć zdalny resolver i nie dopuścić do lokalnego. To najbardziej praktyczny rozdział – miej go pod ręką.

curl: socks5 vs socks5-hostname

curl – wzorcowe narzędzie do zrozumienia różnicy. Daje wyraźny wybór.

  • --socks5 host:port – resolver lokalny. curl sam określa adres IP, potem idzie przez proxy.
  • --socks5-hostname host:port – resolver zdalny. curl przekazuje nazwę serwerowi proxy.

Za pomocą opcji --proxy również można sterować schematem: socks5://... daje resolver lokalny, a socks5h://... – zdalny. Przykład poprawnego wywołania dla zdalnego resolvera: curl --proxy socks5h://user:pass@proxyhost:1080 https://example.com. Dla proxy HTTP schemat http://... z metodą CONNECT domyślnie rozwiązuje na proxy, ale i tutaj warto sprawdzić rzeczywiste zachowanie.

Python: requests i httpx

W ekosystemie Pythona schemat socks5h to złoty standard zdalnego resolvera.

Dla requests potrzebny jest pakiet obsługi SOCKS. Proxy podaje się w słowniku: wskazuj schemat socks5h://user:pass@host:port dla https i http. Schemat socks5:// bez h oznacza resolver lokalny – to właśnie on najczęściej jest przyczyną wycieków u nowicjuszy. Jedna litera decyduje.

Dla httpx logika jest analogiczna: przekaż proxy ze schematem socks5h:// dla zdalnego resolvera. httpx jest restrykcyjny co do schematów i dobrze dokumentuje zachowanie, ale zasada jest ta sama – litera h przełącza resolver na stronę proxy.

Ważna uwaga: nawet jeśli wskażesz socks5h, sprawdź, czy nie zadziałało systemowe proxy ze zmiennych środowiskowych (HTTP_PROXY, ALL_PROXY) z innym schematem. Zmienne środowiskowe mogą nadpisać Twoje intencje.

Node.js

W Node.js bezpośrednia obsługa SOCKS w standardowym http nie istnieje. Używa się agentów SOCKS, które tworzą połączenie przez proxy. Kluczowym parametrem takich agentów jest opcja określająca, czy rozwiązywać nazwę lokalnie. W popularnych agentach SOCKS istnieje flaga, zwykle nazwana coś w stylu lookup lub opcja odpowiedzialna za DNS: przy wartości wyłączającej lokalny lookup, nazwa jest przekazywana do proxy. Upewnij się, że agent jest skonfigurowany do przekazywania nazwy hosta, a nie wcześniejszego resolvera przez dns.lookup.

Praktyczna rada: w Node szczególnie uważnie sprawdzaj, czy gdzieś w kodzie przed nawiązaniem połączenia nie jest wywoływane dns.resolve lub dns.lookup. Taki przedwczesny resolver unieważnia zdalną ścieżkę.

Go

W Go standardowa biblioteka dostarcza pakiet do pracy z proxy. Przez golang.org/x/net/proxy można utworzyć dialer SOCKS5. Domyślnie zachowanie zależy od tego, czy przekazujesz do dialer nazwę, czy już rozwiązany adres. Klucz – używać dialera tak, aby trafiała do niego właśnie nazwa domeny, a nie wynik net.LookupHost. Jeśli sam wywołasz resolver i przekażesz adres IP – to resolver lokalny ze wszystkimi konsekwencjami. Prawidłowe podejście: przekaż dialerowi ciąg host:port z nazwą i nie rozwiązuj wcześniej.

Chrome: flagi uruchomieniowe

Chrome steruje się flagami wiersza poleceń i polityką. Do wskazania proxy używa się flagi proxy-server. Krytyczne jest to, że podczas pracy przez SOCKS5 Chrome domyślnie może rozwiązywać lokalnie. Istnieje flaga odpowiedzialna za to, aby resolver dla połączeń proxy był wykonywany po stronie proxy – jej nazwa wiąże się z host-resolver-rules i ustawieniem zmuszającym wszystkie hosty do przechodzenia przez proxy. Ważna jest także kontrola wbudowanego DoH: jeśli Secure DNS w przeglądarce jest aktywny i skonfigurowany na własnego dostawcę, może ominąć Twój schemat. Dla czystości eksperymentu Secure DNS na czas diagnostyki zwykle się wyłącza, a politykę WebRTC zaostrza.

Firefox: ustawienia about:config

Firefox historycznie jest wygodniejszy do kontroli resolvera. Kluczowe ustawienie – network.proxy.socks_remote_dns. Ustaw je na true, a Firefox będzie wysyłał nazwy hostów na proxy SOCKS w celu zdalnego resolvera zamiast lokalnego. To jedno z najważniejszych ustawień w całym materiale. Dodatkowo kontroluj:

  • network.trr.mode – tryb DoH (TRR, Trusted Recursive Resolver). Wartość wyłączająca wymuszony DoH jest ważna, jeśli chcesz, aby resolver szedł tylko przez proxy.
  • media.peerconnection.enabled – zarządzanie WebRTC, aby wykluczyć wyciek przez ICE.
  • ustawienia wyłączające IPv6 lub wstępne ładowanie, jeśli obserwujesz równoległą ścieżkę.

Selenium

Selenium steruje prawdziwą przeglądarką, więc logika resolvera jest dziedziczona z Chrome lub Firefox. Dla Chrome przekazujesz te same flagi przez opcje uruchomieniowe (argumenty proxy-server i związane z resolverem). Dla Firefox ustawiasz profil z włączonym network.proxy.socks_remote_dns poprzez obiekt ustawień profilu. Sekret sukcesu: nie polegaj na domyślnych ustawieniach sterownika – jawnie wpisz ustawienie zdalnego resolvera w profilu lub flagach, a następnie koniecznie sprawdź faktyczną ścieżkę.

Playwright

Playwright udostępnia parametr proxy podczas uruchamiania kontekstu lub przeglądarki. Wiadomo server ze schematem (np. socks5://host:port) i dane uwierzytelniające. Jest tu subtelność: zachowanie resolvera zależy od silnika (Chromium, Firefox, WebKit) i od tego, jak zaimplementowano proxy. Dla gwarancji zdalnego resolvera w silniku Chromium połącz ustawienie proxy z odpowiednimi argumentami uruchomieniowymi, a w silniku Firefox – z ustawieniem profilu socks_remote_dns. Zawsze kończ konfigurację sprawdzeniem wycieku.

Tabela podsumowująca: klient, jak włączyć zdalny resolver, jak sprawdzić

Oto główna praktyczna tabela materiału:

  • curl – włączyć: użyj --socks5-hostname lub schemat socks5h:// w --proxy – sprawdzić: curl z verbose i obserwacja, czy przekazywana jest nazwa; zrzut ruchu pod kątem braku bezpośrednich zapytań na port 53.
  • Python requests – włączyć: schemat socks5h:// w słowniku proxies – sprawdzić: zapytanie do usługi pokazującej źródło resolvera; kontrola zmiennych środowiskowych.
  • Python httpx – włączyć: proxy ze schematem socks5h:// – sprawdzić: test wycieku, analiza, który resolver jest widoczny.
  • Node.js – włączyć: agent SOCKS z przekazaniem nazwy hosta, bez wcześniejszego dns.lookup – sprawdzić: brak wywołań dns.resolve przed połączeniem; zrzut na port 53.
  • Go – włączyć: dialer SOCKS5, przekazanie host:port z nazwą, bez net.LookupHost wcześniej – sprawdzić: logowanie tego, co trafia do dialera; tcpdump.
  • Chrome – włączyć: proxy-server z SOCKS5, host-resolver-rules na proxy, wyłączyć Secure DNS na czas diagnostyki – sprawdzić: test wycieku online, porównanie regionu IP i regionu DNS.
  • Firefox – włączyć: network.proxy.socks_remote_dns na true, kontrola network.trr.mode – sprawdzić: about:networking, test wycieku online.
  • Selenium – włączyć: te same flagi Chrome lub profil Firefox z socks_remote_dns – sprawdzić: uruchomienie testu wycieku wewnątrz sterowanej przeglądarki.
  • Playwright – włączyć: parametr proxy plus argumenty silnika dla zdalnego resolvera – sprawdzić: przejście na test wycieku w zautomatyzowanej sesji.

DoH i DoT: jak współdziałają z proxy

DNS over HTTPS (DoH) i DNS over TLS (DoT) to szyfrowanie zapytań DNS. Same w sobie są doskonałe do ochrony treści zapytania przed obserwatorem. Ale w kontekście proxy rodzą subtelne skutki, które trzeba zrozumieć.

Czym są DoH i DoT w skrócie

DoT owija DNS w TLS na dedykowanym porcie. DoH ukrywa zapytanie DNS wewnątrz zwykłego ruchu HTTPS, przez co staje się nieodróżnialne od przeglądania stron. Oba protokoły szyfrują zapytanie. Ale – i to jest krytyczne – szyfrowanie zapytania nie równa się routowaniu przez proxy. To różne wymiary.

Kluczowy konflikt: DoH w przeglądarce omija proxy

Oto główna myśl tego rozdziału. Gdy przeglądarka włącza własny DoH i jest skonfigurowana do resolvera przez swojego dostawcę, nawiązuje połączenie HTTPS z punktem końcowym DoH. Pytanie: czy to połączenie przechodzi przez Twoje proxy? Często – nie. Przeglądarka może otworzyć kanał DoH bezpośrednio, ponieważ resolver jest postrzegany jako operacja pomocnicza, oddzielna od nawigacji użytkownika.

Wynik jest paradoksalny. Z jednej strony zapytanie DNS jest zaszyfrowane i dostawca nie widzi, jaką domenę odwiedzasz. Z drugiej – to zapytanie wychodzi z Twojej prawdziwej maszyny, z Twojej sieci, z pominięciem proxy. Dla geolokalizacji to porażka: docelowa infrastruktura widzi resolver z Twojego regionu, a nie z regionu proxy. Twoja pięknie skonfigurowana schemat socks5h jest omijana, ponieważ przeglądarka w ogóle nie poszła przez SOCKS dla resolvera – poszła własną ścieżką DoH.

Kiedy DoH w przeglądarce całkowicie psuje Twój schemat

Uściślijmy sytuacje, w których DoH omija proxy:

  • przeglądarka jest skonfigurowana na wymuszony DoH przez swojego dostawcę, a proxy jest ustawione tylko dla zwykłego ruchu, nie dla pomocniczego resolvera;
  • system operacyjny lub aplikacja ma włączony DoH na poziomie systemu i nie jest owinięty w tunel;
  • punkt końcowy DoH został zbuforowany, a połączenie z nim zostało nawiązane przed zastosowaniem ustawień proxy.

Praktyczny wniosek: w zadaniach, w których ważna jest spójność regionu, podczas pracy przez proxy przeglądarkowy i systemowy DoH należy albo wyłączyć, albo jawnie skierować przez to samo proxy. Idealny obraz – cały resolver, czy jest szyfrowany, czy nie, idzie przez serwer proxy (zdalny resolver), a nie z pominięciem go.

DoT a proxy

DoT działa na dedykowanym porcie i łatwiej poddaje się polityce sieci, ale również może omijać proxy, jeśli nie jest jawnie owinięty. Dla naszych zadań zasada jest ta sama: kontroluj, aby resolver szedł przez proxy, a nie niezależnym kanałem.

Złota zasada DoH w kontekście proxy

Zapamiętaj: szyfrowanie resolvera a jego routowanie przez proxy to niezależne właściwości. Można mieć zaszyfrowany resolver, który jednocześnie całkowicie ujawnia Twój region, ponieważ omija proxy. Dla spójności zawsze dąż do zdalnego resolvera na proxy, a kwestię szyfrowania rozwiązuj osobno i świadomie.

Jak sprawdzić: dig, nslookup, tcpdump i testy online

Skonfigurować to połowa sukcesu. Inżynier musi sprawdzić, że resolver faktycznie poszedł tam, gdzie zamierzał. Omówimy narzędzia diagnostyczne od prostych do zaawansowanych.

dig i nslookup przez proxy

dig i nslookup to klasyczne narzędzia do ręcznego resolvera. Subtelność polega na tym, że zwykły DNS działa przez UDP, a proxy SOCKS natywnie proxyuje TCP. Dlatego sprawdzenie resolvera przez proxy wymaga, aby zapytanie DNS szło przez TCP i aby narzędzie było skierowane przez owijkę SOCKS. W praktyce do obserwacji zachowania wygodniej jest owijać narzędzia przez programy, które zawijają ruch TCP w SOCKS. Sens sprawdzenia: upewnić się, że przy zdalnym resolverze Twoja lokalna maszyna nie wysyła zapytań DNS sama, a widzi tylko wynik, który przyszedł przez kanał proxy.

nslookup jest przydatny do szybkiego sprawdzenia, który resolver odpowiada i jaki adres IP jest zwracany. Porównaj adres IP uzyskany lokalnie z adresem IP, do którego faktycznie idzie połączenie przez proxy. Rozbieżność – wskaźnik, że resolver idzie różnymi ścieżkami.

tcpdump na porcie 53 – najbardziej uczciwy test

To moja ulubiona metoda, ponieważ nie kłamie. Uruchom na swojej maszynie przechwytywanie ruchu z filtrem na port 53 (i na 443 dla podejrzeń DoH). Następnie wykonaj zapytanie przez proxy. Logika jest prosta:

  • jeśli przy zdalnym resolverze widzisz wychodzące pakiety DNS na port 53 bezpośrednio z Twojej maszyny – masz wyciek, resolver idzie lokalnie;
  • jeśli port 53 milczy, a cały ruch idzie w tunel proxy – zdalny resolver działa poprawnie;
  • jeśli port 53 milczy, ale są podejrzane połączenia HTTPS do znanych punktów końcowych DoH z pominięciem proxy – masz wyciek przez DoH.

tcpdump pokazuje fizyczną rzeczywistość sieci, a nie deklaracje z konfiguracji. Dlatego jest niezastąpiony przy końcowej weryfikacji.

Test wycieku online: jak poprawnie odczytać wynik

Istnieją usługi internetowe pokazujące, który resolver wykonał Twoje zapytanie DNS i z jakiego regionu. Kluczem do poprawnego odczytania wyniku jest nie mylenie dwóch parametrów:

  • Twój widoczny adres IP – to adres IP, z którego przyszło połączenie HTTP, czyli IP proxy;
  • resolver DNS – to adres i region tego, kto faktycznie wykonał resolver.

Poprawny obraz przy zdalnym resolverze: zarówno widoczny adres IP, jak i resolver wskazują na region proxy. Niepokojący sygnał: widoczny IP – region proxy, a resolver – Twój prawdziwy region. To klasyczny wyciek przez lokalny resolver. Inny wariant wycieku: resolver należy do dużego dostawcy DoH, ale połączenie do niego szło z pominięciem proxy – wtedy region resolvera może być neutralny, ale sama ścieżka i tak nie przechodzi przez proxy, co widać już w tcpdump.

Lista kontrolna weryfikacji resolvera

Przechodź przez punkty kolejno:

  1. Wyczyść pamięć podręczną DNS systemu operacyjnego i przeglądarki, zrestartuj aplikację.
  2. Upewnij się, że schemat to socks5h lub włączony jest zdalny resolver w kliencie.
  3. Sprawdź zmienne środowiskowe proxy pod kątem kolidujących schematów.
  4. Uruchom tcpdump z filtrem na porty 53 i 443.
  5. Wykonaj zapytanie przez proxy do zasobu testowego.
  6. Upewnij się, że nie ma bezpośrednich pakietów DNS na port 53.
  7. Sprawdź brak niezależnych połączeń HTTPS do punktów końcowych DoH.
  8. Otwórz test wycieku online i porównaj region IP z regionem resolvera.
  9. Sprawdź ścieżkę IPv6: czy nie ma równoległych zapytań AAAA i połączeń.
  10. Udokumentuj referencyjną konfigurację w dokumentacji zespołu.

Typowe błędy, które popełnia prawie każdy

Po latach pracy z proxy zebrała się kolekcja grabi. Omówimy najczęstsze, abyś na nie nie wpadł.

Błąd 1: mylenie socks5 i socks5h

Absolutny lider. Człowiek pisze socks5:// i jest przekonany, że resolver jest zdalny. A jest lokalny. Jedna brakująca litera h – i cały region się rozjeżdża. Zawsze jawnie podawaj socks5h, jeśli potrzebujesz zdalnego resolvera, i sprawdzaj to zrzutem.

Błąd 2: skonfigurowanie proxy, ale zapomnienie o DoH

Klasyka w przeglądarkach. Proxy jest ustawione, ale wbudowany Secure DNS / DoH jest aktywny i omija je. Użytkownik widzi poprawny adres IP i uspokaja się, a w międzyczasie resolver wycieka. Zawsze synchronizuj politykę DoH z proxy.

Błąd 3: ignorowanie IPv6

Proxy na IPv4, a maszyna żyje podwójnym stosem. Happy Eyeballs robi swoje i część połączeń idzie przez IPv6 bezpośrednio. Albo wyłącz IPv6 dla aplikacji, albo upewnij się, że proxy w pełni obsługuje IPv6.

Błąd 4: przedwczesny lokalny resolver w kodzie

Częsty problem w Node.js i Go. Deweloper w dobrej wierze wywołuje resolver z wyprzedzeniem (do sprawdzenia, logowania) i przekazuje do proxy już adres IP. Zdalny resolver umarł. Nie rozwiązuj nazwy przed przekazaniem do dialera proxy.

Błąd 5: ufanie zmiennym środowiskowym

HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY – cisi dywersanci. Nadpisują ustawienia w kodzie lub kolidują ze schematem. Sprawdzaj środowisko przed uruchomieniem i czyść nadmiarowe.

Błąd 6: wierzenie konfiguracji zamiast sprawdzenia

Napisałeś poprawny ciąg i poszedłeś dalej. Ale konfiguracja to intencja, a nie fakt. Rzeczywiste zachowanie sprawdzaj tylko zrzutem ruchu i testem wycieku. Nigdy nie kończ konfiguracji bez weryfikacji.

Błąd 7: zapomniana pamięć podręczna DNS

Zmieniasz konfigurację, a wynik jest ten sam – bo stare wpisy i połączenia zostały zbuforowane. Zawsze czyść pamięć podręczną i restartuj przed sprawdzeniem.

Błąd 8: mieszanie typów proxy w jednym pipeline

W jednym miejscu proxy HTTP z CONNECT, w innym SOCKS z lokalnym resolverem. Zachowanie resolvera się różni i część zapytań wycieka. Ujednolicaj podejście w całym pipeline.

Błąd 9: nieuwzględnianie pamięci podręcznej aplikacji

Niektóre aplikacje trzymają własną pamięć podręczną DNS i pulę połączeń, która przetrwa zmianę ustawień. Restart procesu jest czasem konieczny.

Błąd 10: ignorowanie WebRTC w automatyzacji

Podczas automatyzacji przeglądarek WebRTC często bywa zapominany. Sterowana przeglądarka spokojnie inicjuje ICE i ujawnia ścieżki z pominięciem proxy. Zawsze kontroluj politykę WebRTC w zautomatyzowanych sesjach.

Narzędzia i zasoby do pracy z resolverem przez proxy

Zebraliśmy arsenał, który warto mieć pod ręką. Podzielimy według przeznaczenia.

Narzędzia diagnostyczne

  • tcpdump – przechwytywanie ruchu sieciowego, główny sędzia prawdy o ścieżkach resolvera.
  • Wireshark – graficzna analiza pakietów, wygodna do rozwiązywania skomplikowanych przypadków z DoH i IPv6.
  • dig i nslookup – ręczny resolver, szybkie sprawdzenie odpowiedzi resolvera.
  • testy wycieku DNS online – pokazują resolver i jego region, dają szybki werdykt.
  • about:networking w Firefox – wbudowana diagnostyka połączeń i DNS przeglądarki.

Narzędzia i biblioteki do konfiguracji

  • curl – wzorzec do sprawdzania zachowania socks5 i socks5-hostname, idealny do debugowania.
  • owijki SOCKS dla ruchu TCP – pozwalają owinąć dowolną aplikację w SOCKS do testów resolvera.
  • biblioteki SOCKS dla języków – pakiety obsługi SOCKS w Python, agenty SOCKS w Node.js, pakiet proxy w Go.
  • narzędzia automatyzacji przeglądarek – Selenium i Playwright z jawną konfiguracją proxy i resolvera.

Zasoby wiedzy

  • oficjalna dokumentacja curl dotycząca opcji proxy – najlepsze źródło na temat semantyki socks5 vs socks5h;
  • dokumentacja klientów HTTP w Python dotycząca pracy z proxy i schematami;
  • poradniki about:config Firefox dotyczące parametrów sieci i resolvera;
  • dokumentacja wybranego dostawcy proxy, w szczególności serwisu MobileProxy.space, gdzie opisane są obsługiwane schematy i zalecenia dotyczące zdalnego resolvera dla mobilnych proxy.

Mini-framework wyboru podejścia

Aby się nie pogubić, trzymaj prostą logikę podejmowania decyzji:

  1. Potrzebujesz ruch HTTPS i zdalnego resolvera? Proxy HTTP z CONNECT lub SOCKS5 ze schematem socks5h.
  2. Pracujesz z biblioteki lub CLI? Jawnie podawaj socks5h lub flagę zdalnego resolvera.
  3. Pracujesz z przeglądarki? Włącz zdalny resolver, wyłącz lub skieruj DoH przez proxy, ogranicz WebRTC i IPv6.
  4. Zawsze kończ konfigurację zrzutem ruchu i testem online.

Przypadki i wyniki: jak to wygląda w praktyce

Teoria bez praktyki martwa. Omówimy uogólnione przypadki odzwierciedlające typowe sytuacje. Liczby są umowne, ale proporcje i logika pochodzą z prawdziwej praktyki inżynieryjnej.

Przypadek 1: rozbieżność regionu u analityka danych

Zespół zbierał dane za pomocą skryptu Python z proxy odpowiedniego regionu. Wyniki przychodziły z lokalizacją innego kraju w około czterdziestu procentach przypadków. Diagnostyka wykazała schemat socks5:// w słowniku proxies – resolver lokalny. Zamiana na socks5h:// całkowicie usunęła rozbieżność. tcpdump potwierdził: bezpośrednie zapytania na port 53 zniknęły. Lekcja: jedna litera rozwiązała problem, na który wcześniej poświęcono dwa dni.

Przypadek 2: wyciek przez DoH w przeglądarce w automatyzacji

Podczas automatyzacji Chromium przez Playwright region IP był poprawny, ale docelowy zasób uparcie określał inny region. Test online pokazał resolver niepasujący do regionu proxy. Wireshark ujawnił niezależne połączenia HTTPS z punktem końcowym DoH z pominięciem proxy. Rozwiązanie: wyłączenie Secure DNS w konfiguracji uruchomieniowej i wymuszenie zdalnego resolvera. Po poprawce region resolvera pokrył się z regionem IP, fałszywe alarmy antyfraudowe spadły kilkukrotnie.

Przypadek 3: równoległe IPv6 w mikrousłudze

Usługa Go komunikowała się przez SOCKS5, ale okresowo część zapytań szła bezpośrednio. Przyczyna – podwójny stos i próby przez IPv6 z pominięciem proxy. Ograniczenie klienta tylko do IPv4 oraz poprawne przekazanie nazwy w dialerze usunęły wyciek. tcpdump przestał pokazywać bezpośrednie zapytania AAAA. Stabilność regionu wzrosła do prawie stu procent.

Przypadek 4: zmienne środowiskowe-dywersanci

Skrypt zachowywał się inaczej na dwóch maszynach przy identycznym kodzie. Na jednej działał zdalny resolver, na drugiej nie. Rozwiązanie: na problematycznej maszynie była ustawiona zmienna ALL_PROXY ze schematem bez h, która nadpisała ustawienia. Po wyczyszczeniu środowiska zachowanie stało się spójne. Lekcja: środowisko jest częścią konfiguracji – trzeba kontrolować je tak samo rygorystycznie jak kod.

Ogólny wniosek z przypadków

Zauważ prawidłowość. We wszystkich przypadkach objaw był podobny – błędny region lub uruchomienie zabezpieczeń – a przyczyny różne: schemat, DoH, IPv6, środowisko. Dlatego diagnostyka według listy kontrolnej jest ważniejsza niż intuicja. Systematyczne podejście znajduje źródło szybciej niż zgadywanie.

FAQ: najczęściej zadawane pytania

Czym różni się socks5 od socks5h w prostych słowach?

socks5 rozwiązuje nazwę domeny po Twojej stronie i wysyła do proxy gotowy adres IP. socks5h wysyła do proxy samą nazwę, a resolver wykonuje proxy. Dla prywatności i poprawnej geolokalizacji prawie zawsze potrzebujesz socks5h. Litera h oznacza hostname – nazwa hosta jest przekazywana zdalnie.

Jeśli używam proxy HTTP, czy muszę martwić się o resolver?

Przy HTTPS przez metodę CONNECT nazwa zwykle trafia na proxy, a on rozwiązuje sam – to dobrze. Ale niektórzy klienci wcześniej rozwiązują lokalnie i przekazują w CONNECT już adres IP. Dlatego nawet z proxy HTTP sprawdzaj faktyczne zachowanie zrzutem ruchu.

Dlaczego IP jest poprawne, a strona widzi inny region?

Prawie na pewno Twoje zapytanie DNS omija proxy – poprzez lokalny resolver lub DoH w przeglądarce. Docelowa infrastruktura przez geolokalizację DNS i CDN określa region Twojego resolvera, a nie proxy. Leczenie – zdalny resolver i kontrola DoH.

Jak WebRTC wiąże się z resolverem i wyciekami?

WebRTC do nawiązywania połączeń zbiera kandydatów sieciowych i może inicjować zapytania omijające proxy. Może to ujawnić ścieżki i adresy. Podczas pracy przez proxy, szczególnie w automatyzacji przeglądarek, politykę WebRTC należy kontrolować lub ograniczać.

Czy DoH psuje moją konfigurację proxy?

Może psuć. Szyfrowanie resolvera a jego routowanie przez proxy to różne rzeczy. DoH w przeglądarce lub systemowy może iść bezpośrednio, omijając proxy i ujawniając Twój region. Dla spójności wyłącz taki DoH lub skieruj resolver przez proxy.

Jak szybko sprawdzić, czy jest wyciek?

Dwa kroki. Po pierwsze – uruchom tcpdump z filtrem na port 53 i wykonaj zapytanie przez proxy: bezpośrednie pakiety DNS oznaczają wyciek. Po drugie – otwórz test online i porównaj region widocznego IP z regionem resolvera. Zgodne – dobrze, rozbieżne – wyciek.

Co zrobić z IPv6, jeśli proxy działa tylko na IPv4?

Albo wyłącz IPv6 dla aplikacji korzystającej z proxy, albo upewnij się, że proxy obsługuje IPv6 i cały ruch, w tym AAAA-resolver, idzie przez nie. W przeciwnym razie algorytm Happy Eyeballs wyśle część połączeń bezpośrednio, omijając proxy.

Dlaczego ten sam kod zachowuje się inaczej na dwóch maszynach?

Częsta przyczyna – zmienne środowiskowe proxy (HTTP_PROXY, ALL_PROXY itp.). Nadpisują ustawienia w kodzie lub ustawiają inny schemat. Sprawdź i wyczyść środowisko, aby zachowanie było spójne.

Czy wystarczy podać socks5h, aby na pewno nie było wycieków?

Dla samej aplikacji – duży krok naprzód, ale nie gwarancja dla całego systemu. Pozostają kanały takie jak DoH w przeglądarce, WebRTC i IPv6. Pełna ochrona to zdalny resolver plus kontrola wszystkich kanałów omijających plus obowiązkowe sprawdzenie zrzutem.

Czy można rozwiązywać przez proxy w wierszu poleceń do testu?

Tak. curl z opcją --socks5-hostname lub schematem socks5h to najprostszy sposób sprawdzenia zdalnego resolvera. Dla narzędzi takich jak dig wygodnie jest owinąć ruch TCP w SOCKS, pamiętając, że klasyczny DNS przez UDP nie jest natywnie proxyowany przez SOCKS.

Podsumowanie: wnioski i kolejne kroki

Przeszliśmy drogę od objawu do głębokiego zrozumienia. Zbierzmy najważniejsze w zwięzłą ramę znaczeniową, która zostanie z Tobą.

Resolver nazwy domeny to osobna transakcja sieciowa, która może iść trasą różną od Twojego głównego ruchu. To właśnie ta niezależność rodzi większość problemów. Resolver mogą wykonać cztery podmioty: system operacyjny, biblioteka aplikacji, przeglądarka i samo proxy. Twoim celem prawie zawsze jest oddanie resolvera serwerowi proxy, aby nazwa była określana z właściwego punktu sieci.

Różnica między socks5 a socks5h jest fundamentalna. socks5 – resolver lokalny, socks5h – zdalny. Jedna litera zmienia wszystko: region, prywatność, spójność. Proxy HTTP z metodą CONNECT z natury rzeczy przekazują nazwę na proxy, ale i tu nie można ślepo ufać – sprawdzaj.

Wycieki sprowadzają się do jednej zasady: istnieje kanał, którym nazwa wychodzi nie przez proxy. Systemowy resolver, WebRTC, DoH w przeglądarce, równoległe IPv6, pamięć podręczna – to główni podejrzani. I pamiętaj kluczową myśl: szyfrowanie resolvera nie równa się jego routowaniu przez proxy. Możesz mieć zaszyfrowany DoH, który jednocześnie całkowicie ujawnia Twój region.

Co zrobić od razu? Oto Twój plan działania:

  1. Przejrzyj swoje bieżące konfiguracje i zamień socks5 na socks5h tam, gdzie potrzebny jest zdalny resolver.
  2. Sprawdź przeglądarki: włącz zdalny resolver, rozwiąż kwestię polityki DoH i WebRTC.
  3. Upewnij się, że IPv6 nie tworzy równoległej ścieżki z pominięciem proxy.
  4. Wyczyść zmienne środowiskowe proxy z kolidujących wartości.
  5. Przeprowadź weryfikację przez tcpdump i test online według listy kontrolnej z artykułu.
  6. Udokumentuj referencyjną działającą konfigurację w dokumentacji, aby zespół nie wynajdował koła na nowo.

Temat resolvera przez proxy wydaje się wąski, ale to na nim psują się najdroższe i najbardziej irytujące konfiguracje. Teraz masz mapę terenu: rozumiesz, kto rozwiązuje, gdzie zapada decyzja, jak powstają wycieki i jak je zamykać. Trzymaj ten materiał w zakładkach i wracaj do tabeli oraz list kontrolnych za każdym razem, gdy proxy jest podłączone, a strona uparcie widzi inny region. Teraz wiesz, gdzie szukać.