SOCKS5 a HTTP: protokoły, DNS i zgodność

SOCKS5 a proxy HTTP: czym różnią się tunele HTTP CONNECT i SOCKS5, gdzie rozwiązywany jest DNS, które klienty obsługują które uwierzytelnianie i jak przetestować protokół, który kupiliście.

Ten przewodnik jest dla każdego, kto wybiera między punktem końcowym HTTP a SOCKS5 na planie proxy albo próbuje zrozumieć, czemu klient odmawia jednego z nich. Nie rozdajemy darmowych proxy i nie sprzedajemy adresów IP. Poniżej są same protokoły, to, gdzie lądują wasze lookupy DNS, i jak sprawdzić, co naprawdę dostaliście.

01HTTP CONNECT a SOCKS5: jak działa każdy tunel#

Zanim wejdziemy w szczegóły, jeden punkt liczy się bardziej niż reszta: protokół to nie pochodzenie. Pulę rezydencką można sprzedać jako HTTP, jako SOCKS5 albo jako oba. Adresy datacenter też przychodzą w obu formach. SOCKS5 nie jest klasą jakości. To sposób przenoszenia bajtów. Czy witryna docelowa ufa waszemu ruchowi, zależy od sieci i historii IP, nie od tego, którym handshake klient doszedł do bramy.

Proxy HTTP mówi HTTP do waszego klienta. Dwa rodzaje ruchu obsługuje inaczej.

Przy zwykłych URL http:// klient wysyła pełne żądanie do proxy, które je czyta, przekazuje i po drodze może dodać, zdjąć albo cache’ować nagłówki. Mało publicznych witryn nadal serwuje zwykły HTTP, więc w praktyce ta ścieżka jest rzadka.

Przy URL https:// i przy wszystkim, co nie jest zwykłym HTTP, klient używa metody CONNECT. Zgodnie z RFC 9110, sekcja 9.3.6 CONNECT prosi proxy, żeby otworzyło tunel do wskazanego celu, a po sukcesie przestało interpretować ruch i po prostu przekazywało bajty w obie strony, aż któraś strona zamknie. Celem żądania jest tylko host i port, na przykład CONNECT example.com:443. Gdy proxy odpowie statusem 2xx, TLS idzie od końca do końca między waszym klientem a witryną. Proxy widzi, o który host i port prosiliście, ale nie czyta odszyfrowanej strony.

Proxy SOCKS5 działa warstwę niżej. RFC 1928 definiuje krótki binarny handshake: klient oferuje metody uwierzytelniania, serwer wybiera jedną, a potem klient wysyła żądanie z poleceniem i celem. Są trzy polecenia: CONNECT dla zwykłego strumienia TCP, BIND dla połączeń przychodzących i UDP ASSOCIATE dla przekazywania UDP. SOCKS5 nie obchodzi, czy ładunek to HTTP, TLS, SMTP czy protokół gry. Po prostu rusza bajty.

Zatem „SOCKS5 kontra HTTP CONNECT” to nie naprawdę wybór między mądrym proxy a głupim. Dla ruchu HTTPS oba kończą jako nieprzezroczysty tunel TCP. Prawdziwe różnice to to, co każde potrafi nieść poza HTTPS, jak przekazywana jest nazwa celu i które klienty umieją do nich mówić.

RFC 9110 mówi też, że proxy „SHOULD restrict” CONNECT do znanych portów albo skonfigurowanej listy celów, bo otwarty CONNECT na port 25 mógłby służyć do przekazywania spamu. Punkt końcowy HTTP może więc odmówić tunelu do bazy, serwera poczty albo własnego portu TCP nawet przy poprawnych danych logowania. Jeśli potrzebujecie tych portów, sprawdźcie w dokumentacji dostawcy dozwolone porty CONNECT albo użyjcie punktu końcowego SOCKS5, który je dopuszcza.

02DNS: rozwiązywany na urządzeniu albo przez proxy#

DNS to część, która naprawdę zmienia to, czego witryna albo wasz ISP może się o was dowiedzieć, i to tu konfiguracja SOCKS5 psuje się najczęściej.

Przy proxy HTTP klient oddaje nazwę hosta w celu żądania (CONNECT example.com:443), a proxy robi lookup dla tego połączenia. To usuwa lokalny lookup dla żądań, które naprawdę idą przez proxy. Nie gwarantuje, że urządzenie w ogóle nie robi zapytań DNS: przeglądarki potrafią prefetchować DNS, listy ominięć i reguły „direct” puszczają część hostów obok proxy, WebRTC otwiera własne połączenia, a inne aplikacje na urządzeniu nadal używają systemowego resolvera.

Przy SOCKS5 decyduje klient. RFC 1928 pozwala, żeby pole celu trzymało surowy adres IPv4, surowy adres IPv6 albo w pełni kwalifikowaną nazwę domeny. Jeśli klient rozwiązuje nazwę lokalnie i wysyła tylko IP, resolver ISP (albo ten, którego używa system) nadal widzi każdą odwiedzaną domenę, choć sam ruch idzie przez proxy. Jeśli klient wysyła nazwę domeny, proxy rozwiązuje ją na swoim końcu.

curl czyni ten wybór widocznym. Jego podręcznik opisuje --socks5 jako „use the specified SOCKS5 proxy - but resolve the hostname locally”, a --socks5-hostname albo schemat socks5h:// jako „let the proxy resolve the hostname”. Dla żądań przez proxy ta jedna litera h decyduje, czy lokalny resolver widzi nazwę celu. Inne klienty chowają ten sam przełącznik pod nazwami w rodzaju „Proxy DNS when using SOCKS v5” albo „remote DNS”. Ta sama uwaga co przy HTTP: zdalny DNS pokrywa ruch, który idzie tunelem SOCKS, nie prefetch, ominięte hosty, WebRTC ani inne aplikacje, więc potwierdźcie testem wycieku, zamiast zakładać.

Zdalne rozwiązywanie ma też znaczenie dla wyników, nie tylko prywatności. CDN, które odpowiada według lokalizacji resolvera, może wysłać lokalnie rozwiązaną nazwę do krawędzi koło was, a nie koło wyjścia proxy. Strona ładuje się wtedy ze złego regionu, choć IP wygląda dobrze.

Przykład schematyczny, nie pomiar sieci: gdzie dla żądań przez proxy rozwiązywana jest nazwa celu w każdej konfiguracji. Nie obejmuje prefetchu przeglądarki, reguł ominięcia, WebRTC ani innych aplikacji, które nadal potrafią robić lokalne lookupy.

03Zgodność klientów i uwierzytelnianie#

Wybierzcie protokół, którym wasz klient już dobrze mówi. Doklejanie obsługi przez dodatkowe pakiety albo opakowania to częste źródło zgłoszeń „proxy jest zepsute”.

Przeglądarki. Firefox ma pola HTTP i SOCKS we własnych ustawieniach proxy. Przeglądarki oparte na Chromium idą za ustawieniami systemu albo flagą --proxy-server. Oba bez problemu obsługują CONNECT. Słabym punktem jest SOCKS5 z nazwą użytkownika i hasłem: wbudowane ustawienia SOCKS przeglądarki mogą nie mieć miejsca na dane logowania, i to jeden z powodów, dla których ludzie używają rozszerzeń proxy albo przeglądarek antydetekcyjnych. Jeden protokół na profil. Mieszanie systemowego proxy HTTP z rozszerzeniem SOCKS5 w tym samym profilu to łatwy sposób, żeby część żądań poszła jedną trasą, a część drugą.

Scrapery i biblioteki HTTP. Popularne klienty HTTP, takie jak curl, przyjmują proxy http://user:pass@host:port od razu i same używają CONNECT dla HTTPS. W części bibliotek SOCKS5 potrzebuje dodatkowego pakietu albo opcji kompilacji. Jeśli stos tylko pobiera strony, punkt końcowy HTTP to ścieżka z mniejszą liczbą niespodzianek. Stronę pochodzenia tego wyboru pokrywa nasz przewodnik o web scrapingu.

Aplikacje poza HTTP. Komunikatory, launchery gier, klienty poczty, SSH i narzędzia baz danych nie są klientami HTTP. Gdy w ogóle obsługują proxy, często jest to pole SOCKS, nie HTTP. Tam SOCKS5 pasuje lepiej, i także do ruchu UDP takiego jak głos, gdy brama naprawdę implementuje UDP ASSOCIATE. Sama obsługa SOCKS5 na planie nie znaczy, że UDP jest obsługiwane, więc potwierdźcie to, zanim kupicie pod UDP.

Uwierzytelnianie. Proxy HTTP wysyłają dane logowania w nagłówku Proxy-Authorization i odpowiadają 407 Proxy Authentication Required, gdy ich brakuje albo są złe. SOCKS5 najpierw negocjuje metodę. RFC 1928 wymienia GSSAPI i USERNAME/PASSWORD; plan, który daje wam login i hasło, używa tego drugiego, opisanego w RFC 1929.

SOCKS4 i SOCKS4a to inne protokoły bez obsługi hasła, a klient tylko SOCKS4 nie dokończy handshake z punktem końcowym, który mówi wyłącznie SOCKS5. Lista dozwolonych IP usuwa potrzebę hasła, ale nie zmienia protokołu. Potrzebujecie albo punktu końcowego, który dostawca wprost dokumentuje jako SOCKS4/SOCKS4a, zwykle w parze z listą dozwolonych IP, albo klienta, który obsługuje SOCKS5 albo HTTP.

Na zwykłym, niezaszyfrowanym połączeniu między klientem a proxy login nie jest chroniony: dane HTTP Basic są tylko zakodowane Base64, a nazwa użytkownika i hasło SOCKS5 idą jawnym tekstem. Ktokolwiek na tej ścieżce sieci może je przeczytać. Punkt końcowy proxy HTTPS, czyli taki, w którym samo połączenie klient–proxy jest owinięte TLS, chroni ten przeskok, w tym dane logowania. Tak czy inaczej nie używajcie danych proxy nigdzie, gdzie to ma znaczenie.

Szybkość. Ludzie często pytają o „szybkość SOCKS5 kontra HTTP”. Różnica jest mała. Oba dodają jeden handshake przy otwarciu połączenia, a potem oba przekazują bajty. W praktyce o szybkości decyduje odległość do bramy, obciążenie dostawcy i IP wyjścia, nie protokół. Zwykłe proxy HTTP potrafią wydawać się szybsze, gdy cache’ują, ale to rzadko dotyczy HTTPS.

SOCKS5 a HTTPS. „Proxy HTTPS” znaczy dwie różne rzeczy. Zwykle oznacza proxy HTTP, które tuneluje witryny HTTPS metodą CONNECT, czyli wszystko opisane powyżej. Czasem oznacza, że samo łącze między wami a proxy jest owinięte TLS, co ukrywa dane logowania proxy i nazwy hostów celu przed lokalną siecią. Zwykłe połączenia proxy HTTP i SOCKS5 nie szyfrują tego pierwszego przeskoku, więc jeśli jego ukrycie ma znaczenie, użyjcie punktu końcowego owiniętego TLS, jeśli dostawca i klient to obsługują, albo VPN na ten odcinek.

04Które wybrać#

Ostatni wiersz to błąd, który kupujący popełniają najczęściej. Przełączenie IP datacenter z HTTP na SOCKS5 nie sprawia, że wygląda jak połączenie domowe. Jeśli witryna punktuje waszą sieć, zmieńcie typ wyjścia. Porównajcie proxy rezydenckie, proxy mobilne i proxy datacenter albo najpierw przeczytajcie rezydenckie a datacenter.

05Jak sprawdzić, który protokół kupiliście#

Nie ufajcie numerowi portu. 8080, 3128, 1080 i wysokie porty w rodzaju 60000 bywają używane dla obu protokołów, a część bram odpowiada oboma na tym samym porcie.

1. Najpierw poznajcie własne IP. Otwórzcie Wasze IP bez proxy, żeby mieć linię bazową do porównania.

2. Sprawdźcie, że punkt końcowy odpowiada. Wklejcie punkt końcowy dostawcy do sprawdzania proxy jako HOST:PORT albo HOST:PORT:USER:PASS. Sprawdzanie działa na naszym serwerze, próbuje obsługiwanych protokołów i zgłasza pierwszy udany. Prefiks protokołu zmienia, który protokół próbuje najpierw, ale nie wyłącza fallbacku. Jeden udany wynik nie dowodzi więc, że punkt końcowy przyjmuje i HTTP, i SOCKS5. Żeby porównać je osobno, użyjcie dwóch poleceń curl poniżej albo klienta, który pozwala wymusić każdy protokół. Jeśli sprawdzenie pada, obejrzyjcie błąd i zweryfikujcie dane logowania, listę dozwolonych IP oraz ograniczenia planu, zanim uznacie, że protokół nie jest obsługiwany.

3. Sprawdźcie to samo z wiersza poleceń. Użyjcie jednego neutralnego URL testowego w obu przebiegach, żeby wyniki dało się porównać:

   # HTTP proxy: curl sends CONNECT for an https:// URL
   curl -v -x http://USER:PASS@HOST:PORT https://example.com/ -o /dev/null
   
   # SOCKS5 with proxy-side DNS (no local lookup)
   curl -v -x socks5h://USER:PASS@HOST:PORT https://example.com/ -o /dev/null
   

   W wyjściu verbose pierwszego polecenia linia CONNECT example.com:443 i potem odpowiedź 200 potwierdza tunel HTTP. 407 znaczy, że proxy mówi HTTP, ale odrzuciło dane logowania, czyli problem uwierzytelniania, nie protokołu. Jeśli próba HTTP pada od razu zniekształconą odpowiedzią, a socks5h:// się łączy, punkt końcowy najpewniej mówi SOCKS na tym porcie; potwierdźcie to w dokumentacji dostawcy.

4. Porównujcie IP wyjścia, nie tylko zaliczenie albo porażkę. Sprawdźcie, że każdy protokół wychodzi w kraju i typie sieci, za które płaciliście. Na rotacyjnej puli dwa testy mogą pokazać różne IP albo nawet różne sieci niezależnie od protokołu, więc sama rozbieżność nie dowodzi osobnych pul. Sesja sticky czyni porównanie jeden do jednego bardziej prawdopodobnym, ale nie gwarantuje, że ten sam IP zostanie między testami albo po ponownym połączeniu.

5. Obserwujcie DNS w tej samej sesji. Użyjcie zdalnego DNS (socks5h:// albo „Proxy DNS” w kliencie) i puśćcie test wycieku. Przewodnik jak sprawdzić, czy proxy działa przechodzi sprawdzenia DNS i WebRTC.

6. IPv6 testujcie osobno. SOCKS5 potrafi nieść cel IPv6, ale tylko jeśli brama ma wyjście IPv6. Listing dual-stack wymaga testu dual-stack.

Oto hipotetyczny przepracowany przykład, jak czytać wyniki. Powiedzmy, że plan wymienia jeden host bramy z dwoma portami, a wy odpalacie oba polecenia curl powyżej wobec tego samego URL testowego. Te wzorce to ilustracje, nie wyniki od żadnego prawdziwego dostawcy:

Krótka lista przed osadzeniem się na protokole:

• Klient ma natywne ustawienie tego protokołu, w tym pole nazwy użytkownika i hasła, jeśli plan ich używa.
• DNS dla żądań przez proxy jest rozwiązywany na proxy (socks5h:// albo „Proxy DNS” dla SOCKS5), a test wycieku był puszczony w prawdziwej przeglądarce albo aplikacji.
• Potrzebne porty są dozwolone: cele CONNECT na punkcie HTTP, UDP na punkcie SOCKS5, jeśli go potrzebujecie.
• Kraj wyjścia i typ sieci zgadzają się z planem, oceniane osobno od protokołu.
• Łącze z urządzenia do proxy jest chronione (punkt końcowy TLS albo VPN), jeśli dane logowania na tej sieci są problemem.

Protokół to wybór zgodności, pochodzenie to wybór dostępu, a tryb sesji (sticky albo rotacyjny) to wybór przepływu. Decydujcie w tej kolejności i nie dopłacicie za SOCKS5, myśląc, że to czystszy IP.

06Dostawcy, którzy oferują i HTTP, i SOCKS5#

Przed zakupem sprawdźcie w dokumentacji każdego dostawcy, które protokoły plan obejmuje, porty albo nazwy hostów dla każdego, obsługę UDP i to, czy lista dozwolonych IP jest dostępna, jeśli klient jej potrzebuje.

SOAX — proxy rezydenckie i mobilne3.8218

SOAX sprzedaje rotacyjne proxy rezydenckie i mobilne na wspólnej puli kredytów, z datacenter i ISP w tych samych planach. Builder od $200/mies. + VAT (200 kredytów); ruch Tier 1 to $3/GB na Builderze.

85 krajów

3,00 USD

za 1 GB

Bright Data — proxy rezydenckie i datacenter4.41442

Bright Data to duża sieć proxy do zbierania danych: IP rezydenckie, mobilne, ISP i datacenter w około 195 krajach. Ruch rezydencki można płacić na bieżąco bez subskrypcji, a adresy datacenter i ISP przychodzą w pakietach od 10 IP. Dostęp rezydencki i mobilny wymaga weryfikacji tożsamości.

10 krajów

5,00 USD

za 1 GB

Oxylabs — proxy rezydenckie i datacenter4.0771

Oxylabs sprzedaje proxy rezydenckie, mobilne, ISP i datacenter w jednej subskrypcji miesięcznej od $30. Płatności: karty, przelew, AliPay, PayPal.

10 krajów

0,45 USD

za 1 GB

Decodo (Smartproxy) — proxy rezydenckie i datacenter4.22118

Decodo (dawniej Smartproxy) sprzedaje proxy rezydenckie i datacenter. Rezydenckie: $4/GB bez planu miesięcznego albo pakiety miesięczne od $3.75/GB za 3 GB. Płatności: karty, PayPal, Alipay, Google/Apple Pay, krypto (z ograniczeniami).

83 kraje

0,38 USD

za 1 GB