Spis treści

Ten sam serwer proxy jest często udostępniany klientowi w dwóch trybach: jako HTTP proxy i jako SOCKS5. Wielu uważa to za chwyt marketingowy. To nieprawda. Za tymi dwiema literami kryją się dwa zasadniczo różne protokoły pośrednictwa, działające na różnych poziomach stosu sieciowego. Zrozumienie różnicy między nimi oszczędza godziny debugowania, zmniejsza opóźnienia i pomaga wybrać właściwe narzędzie do konkretnego zadania inżynierskiego.

W tym przewodniku przeanalizujemy mechanikę obu protokołów od pierwszego bajtu uzgadniania do ostatniego nagłówka. Zobaczymy, co dokładnie widzi pośrednik w każdym trybie, dlaczego SOCKS5 celowo nie analizuje zawartości ruchu i jak metoda CONNECT zamienia zwykły HTTP proxy w przezroczysty tunel TCP. Na końcu znajdziesz tabelę dopasowania zadanie-protokół i szczegółowy FAQ. Ton materiału jest inżynierski: minimum patosu, maksimum kodu i precyzyjnych sformułowań.

Wprowadzenie: dlaczego jeden proxy jest udostępniany w dwóch trybach

Wyobraź sobie urząd pocztowy. W pierwszym trybie pracownik czyta adres na kopercie, może przełożyć list do innej koperty, postawić stempel, a czasem nawet podpowiedzieć, że taki list już przyszedł wczoraj, i wyciągnąć kopię z archiwum. To HTTP proxy: rozumie język, w którym napisane jest żądanie, i pracuje z jego zawartością jak z sensownymi danymi.

W drugim trybie ten sam pracownik otrzymuje zapieczętowany kontener i instrukcję: dostarczyć na taki a taki adres i taki a taki port, a co jest w środku - to nie jego sprawa. Po prostu kładzie rurę od nadawcy do odbiorcy i przepompowuje bajty w obie strony. To SOCKS5: protokół poziomu sesji, dla którego zawartość tunelu jest obojętna.

Dlaczego dostawca, na przykład Proxeon, udostępnia oba tryby na tej samej infrastrukturze? Ponieważ zadania klientów są różne. Jednemu potrzebny jest cache i filtrowanie na poziomie HTTP, drugiemu - przezroczyste przesyłanie dowolnego protokołu TCP. Jeden serwer może nasłuchiwać na różnych portach i obsługiwać oba scenariusze. To decyzja techniczna, a nie gra słów.

Kluczowa myśl, którą warto zapamiętać od samego początku: HTTP proxy działa na poziomie aplikacji (L7), a SOCKS5 - bliżej poziomu sesji (umownie L5). Stąd wynikają wszystkie pozostałe różnice: co proxy widzi, co może zmienić, jakie protokoły obsługuje i jaki wprowadza narzut.

Podstawy: dwa poziomy pośrednictwa

Zanim zagłębimy się dalej, ustalmy podstawowe pojęcia. Proxy to pośrednik między klientem a serwerem docelowym. Klient wysyła żądanie nie bezpośrednio, lecz do proxy, które przekazuje je dalej. Różnica między typami proxy polega na tym, na jakim poziomie rozumieją to, co przekazują.

Poziom aplikacji kontra poziom sesji

HTTP proxy analizuje całą wiadomość HTTP. Widzi metodę (GET, POST), ścieżkę, wszystkie nagłówki, a w przypadku niezaszyfrowanym - także treść. To czyni go inteligentnym i jednocześnie ograniczonym: potrafi pracować tylko z tym protokołem, który rozumie.

SOCKS5 w ogóle nie analizuje protokołu aplikacji. Otrzymuje od klienta polecenie typu nawiąż połączenie TCP z hostem X na port Y i dalej po prostu przekłada bajty. Właśnie ta neutralność czyni SOCKS5 uniwersalnym transportem dla dowolnego protokołu TCP: HTTP, HTTPS, SMTP, IMAP, a także wielu własnościowych protokołów twojego oprogramowania.

Co znaczy "proxy widzi zawartość"

Kiedy mówimy, że HTTP proxy widzi zawartość, mamy na myśli niezaszyfrowany HTTP. Jeśli ruch idzie przez HTTPS metodą CONNECT (o tym szczegółowo poniżej), nawet HTTP proxy widzi jedynie zaszyfrowany strumień i nazwę hosta. To ważne uściślenie: współczesny web niemal w całości działa na TLS, więc głębia wglądu HTTP proxy w praktyce ogranicza się do etapu ustanawiania tunelu.

Porty i schematy adresowania

Po stronie klienta różnica przejawia się w sposobie wpisania proxy. Dla HTTP proxy schemat wygląda jak http://user:pass@host:port. Dla SOCKS5 - socks5://user:pass@host:port. Porty trybów z reguły są różne, ponieważ nasłuchują na nich różne procedury obsługi. Ten sam fizyczny serwer Proxeon może udostępniać HTTP proxy na jednym porcie i SOCKS5 na innym.

HTTP proxy: żądanie z absolutnym URI

Zacznijmy od klasycznego HTTP proxy i jego najbardziej charakterystycznej cechy - absolutnego URI w wierszu żądania. To właśnie wizualnie odróżnia żądanie do proxy od bezpośredniego żądania do serwera.

Forma absolutna żądania

Kiedy przeglądarka łączy się ze stroną bezpośrednio, wysyła ścieżkę relatywną. Wiersz żądania wygląda tak:

GET /index.html HTTP/1.1
Host: example.com

Ale kiedy ta sama przeglądarka jest skonfigurowana na HTTP proxy, wysyła do serwera proxy formę absolutną URI. Proxy musi wiedzieć, dokąd dokładnie przekazać żądanie, więc cały adres trafia do pierwszego wiersza:

GET http://example.com/index.html HTTP/1.1
Host: example.com
Proxy-Connection: keep-alive

To fundamentalna różnica. Proxy czyta http://example.com/index.html, wyodrębnia hosta, ustanawia połączenie z serwerem docelowym i przekazuje żądanie już w zwykłej, relatywnej formie. Standard RFC 7230 wprost nakazuje klientom używać formy absolutnej przy zwracaniu się do proxy, a formy origin przy połączeniu bezpośrednim.

Co proxy widzi i może zmienić

W trybie niezaszyfrowanego HTTP proxy widzi bardzo wiele. Wymieńmy:

  • Pełny URL, wraz ze ścieżką i parametrami query.
  • Wszystkie nagłówki żądania: User-Agent, Accept, Cookie, Referer.
  • Treść żądania przy POST lub PUT.
  • Odpowiedź serwera w całości: status, nagłówki, treść.

Co więcej, proxy może legalnie i celowo modyfikować ruch. Typowe operacje firmowego lub usługowego HTTP proxy:

  • Dodawanie nagłówków technicznych, na przykład X-Forwarded-For lub Via.
  • Usuwanie nagłówków hop-by-hop, które nie powinny iść dalej (Connection, Proxy-Authorization).
  • Buforowanie odpowiedzi dla kolejnych żądań.
  • Kompresja lub transformacja treści przy jawnej konfiguracji.

Nagłówki specyficzne dla proxy

Są nagłówki, które mają sens tylko w dialogu klient-proxy i nie powinny wyciekać do serwera docelowego. Główny z nich to Proxy-Authorization, niosący dane uwierzytelniające dla dostępu do samego proxy. Nie myl go z Authorization, który jest przeznaczony dla serwera docelowego. Istnieje także para statusów: 407 Proxy Authentication Required oznacza, że proxy wymaga uwierzytelnienia, w odróżnieniu od 401 od serwera docelowego.

Praktyczny przykład: jawny HTTP proxy przez curl

Zobaczmy, jak zwrócić się do HTTP proxy Proxeon za pomocą curl. Flaga -x ustawia proxy, a -v pokaże dialog:

curl -v -x http://user:pass@proxy.proxeon.net:8080 http://example.com/

W wyniku zobaczysz wiersz żądania w formie absolutnej oraz nagłówek Proxy-Authorization z danymi uwierzytelniającymi zakodowanymi w Base64. To wyraźnie pokazuje, że curl komunikuje się właśnie z proxy, a nie bezpośrednio z serwerem docelowym.

Ograniczenie: tylko semantyka HTTP

Klasyczny HTTP proxy w swojej pierwotnej formie potrafi przekazywać tylko żądania HTTP. Nie wie, co zrobić z dowolnym strumieniem TCP SMTP ani z binarnym protokołem twojej aplikacji. Dla niezaszyfrowanego HTTP działa to znakomicie. Ale gdy tylko pojawia się HTTPS lub inny protokół - potrzebny jest mechanizm tunelowania. Tu na scenę wchodzi metoda CONNECT.

Metoda CONNECT: HTTP proxy jako tunel TCP

Metoda CONNECT to właśnie to, co pozwala HTTP proxy obsługiwać HTTPS i w ogóle dowolny strumień TCP. Zamienia inteligentnego pośrednika poziomu aplikacji w przezroczystą rurę. Przeanalizujmy mechanikę krok po kroku.

Po co wymyślono CONNECT

HTTPS szyfruje całą wiadomość, wraz z nagłówkami i ścieżką. Gdyby proxy próbował odczytać absolutny URI, natrafiłby na zaszyfrowane bajty. Uzgadnianie TLS musi odbywać się bezpośrednio między klientem a serwerem docelowym, inaczej traci się szyfrowanie end-to-end. Znaczy to, że proxy musi nie czytać, lecz po prostu połączyć dwa punkty i odejść na bok.

Jak wygląda żądanie CONNECT

Klient wysyła do proxy specjalne żądanie, w którym zamiast URL podaje parę host-port w formie authority:

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dХNlcjpwYXNz

Proxy ustanawia połączenie TCP z example.com:443 i, jeśli wszystko się udało, odpowiada:

HTTP/1.1 200 Connection Established

Po tym wierszu dzieje się rzecz najważniejsza: proxy przestaje być parserem HTTP. Zamienia się w dwukierunkowy przekaźnik bajtów. Wszystko, co klient wysyła dalej, jest kopiowane w stronę serwera, i na odwrót. Właśnie na tym tunelu przeglądarka uruchamia uzgadnianie TLS bezpośrednio z serwerem docelowym.

Co pośrednik widzi po ustanowieniu tunelu

To kluczowe pytanie o prywatność i bezpieczeństwo. Po 200 Connection Established HTTP proxy widzi:

  • Nazwę hosta i port z samego polecenia CONNECT - przed ustanowieniem tunelu.
  • Zaszyfrowany strumień bajtów - i nic więcej.
  • SNI (Server Name Indication) wewnątrz TLS ClientHello, jeśli nie stosuje się szyfrowania SNI - technicznie to również ujawnia nazwę hosta.
  • Metadane połączenia: ilość przesłanych danych, czas trwania, czasy.

Czego proxy NIE widzi po tunelu: ścieżki URL, parametrów query, nagłówków, cookie, treści żądań i odpowiedzi. To wszystko jest chronione przez TLS. Tak więc dla ruchu HTTPS HTTP proxy w trybie CONNECT zachowuje się niemal jak SOCKS5: jest jedynie transportem. Różnica pozostaje w sposobie, w jaki klient uzgadnia tunel.

Praktyka: CONNECT w akcji

Kiedy wykonujesz żądanie HTTPS przez HTTP proxy, curl automatycznie używa CONNECT. Obserwuj dialog:

curl -v -x http://user:pass@proxy.proxeon.net:8080 https://example.com/

W wyniku verbose zobaczysz najpierw wiersz CONNECT example.com:443 HTTP/1.1, potem odpowiedź 200 Connection Established, a dopiero po niej - wiersze uzgadniania TLS i właściwe żądanie GET, idące wewnątrz zaszyfrowanego tunelu. Proxy widział przy tym tylko pierwszą część.

CONNECT nie ogranicza się do portu 443

Choć najczęściej CONNECT prowadzi do portu 443, specyfikacja nie wiąże go z HTTPS. Technicznie przez CONNECT można tunelować dowolny protokół TCP na dowolny port, jeśli proxy na to pozwala. W praktyce administratorzy często ograniczają listę dozwolonych portów ze względów bezpieczeństwa, zostawiając 443 i czasem 22 lub inne. Dlatego próba przepchnięcia, powiedzmy, SMTP przez CONNECT może natrafić na politykę proxy.

SOCKS5: uzgadnianie, uwierzytelnianie i ATYP

Przejdźmy teraz do SOCKS5, zdefiniowanego w RFC 1928. To protokół o zasadniczo innej filozofii. Nie wie i nie chce wiedzieć, co przekazujesz. Jego zadaniem jest ustanowić połączenie i stać się rurą.

Ogólna logika uzgadniania

Dialog SOCKS5 jest binarny, a nie tekstowy jak w HTTP. Składa się z kilku krótkich wymian komunikatów. Schematycznie:

  1. Klient przysyła listę obsługiwanych metod uwierzytelniania.
  2. Serwer wybiera jedną metodę i informuje o wyborze.
  3. W razie potrzeby odbywa się uwierzytelnianie.
  4. Klient wysyła żądanie połączenia: polecenie, typ adresu, adres, port.
  5. Serwer odpowiada wynikiem.
  6. Zaczyna się przezroczyste przesyłanie danych.

Powitanie i wybór metody

Pierwszy komunikat klienta jest bardzo zwięzły. Zawiera numer wersji (0x05), liczbę proponowanych metod i same metody. Najczęściej używane są dwie: 0x00 - bez uwierzytelniania i 0x02 - uwierzytelnianie nazwą użytkownika i hasłem (username/password, RFC 1929). Serwer odpowiada dwoma bajtami: wersja i wybrana metoda. Jeśli serwer zwrócił 0xFF, żadna z zaproponowanych metod nie pasowała i połączenie jest zamykane.

Uwierzytelnianie loginem i hasłem

Jeśli wybrano metodę 0x02, klient wysyła osobny komunikat z wersją podprotokołu, długością i wartością nazwy użytkownika, a następnie długością i wartością hasła. Serwer odpowiada statusem. Ważny niuans inżynierski: w klasycznym SOCKS5 te dane są przesyłane bez wbudowanego szyfrowania, więc takim proxy warto ufać tylko przez zabezpieczone kanały lub w kontrolowanym środowisku. Dla proxy usługowych typu Proxeon uwierzytelnianie może być uzupełnione przypisaniem po IP, co zmniejsza ryzyko wycieku danych uwierzytelniających.

Polecenia: CONNECT, BIND i UDP ASSOCIATE

SOCKS5 obsługuje trzy polecenia. Najczęstsze - CONNECT (0x01), ustanowienie wychodzącego połączenia TCP. Jest BIND (0x02) dla połączeń przychodzących w protokołach typu stary FTP. I jest UDP ASSOCIATE (0x03) dla proxy datagramów UDP. Mechaniki UDP ASSOCIATE i różnic między schematami socks5 i socks5h tutaj celowo nie omawiamy - to osobne duże tematy, którym poświęcono specjalne materiały. Skupimy się na tym, co najbardziej zasadnicze dla porównania z HTTP proxy: na polu ATYP.

ATYP: domena kontra IP i dlaczego to kluczowe dla resolvu

W żądaniu połączenia SOCKS5 jest pole ATYP (address type), określające, jak interpretować następujący po nim adres. Możliwe są trzy wartości:

  • 0x01 - adres IPv4, cztery bajty.
  • 0x03 - nazwa domenowa, pierwszy bajt długość, dalej sam ciąg.
  • 0x04 - adres IPv6, szesnaście bajtów.

Tu kryje się jedna z najważniejszych praktycznych różnic. Kiedy klient wysyła nazwę domenową (ATYP 0x03), resolv DNS wykonuje serwer proxy, a nie klient. Kiedy klient wysyła już rozwiązany adres IP, resolv nastąpił po stronie klienta. Różnica wpływa na to, czyj DNS jest używany, jaki IP ostatecznie otrzyma serwer docelowy i jak poprawnie działa routing zależny od geolokalizacji.

Dla inżyniera oznacza to tyle: jeśli zależy ci, aby nazwa była rozwiązywana w sieci proxy, trzeba przekazywać domenę, a nie IP. Wiele bibliotek domyślnie najpierw rozwiązuje nazwę lokalnie i dopiero potem idzie do proxy - to zmienia zachowanie. Szczegółowe omówienie różnic między lokalnym a zdalnym rozwiązywaniem, a także schematów socks5 i socks5h zostało wyniesione do osobnego artykułu, więc tutaj jedynie odnotowujemy sam fakt istnienia pola ATYP jako kluczowej dźwigni sterowania.

Praktyka: SOCKS5 przez curl

Zwracanie się do proxy SOCKS5 w curl wygląda symetrycznie do wariantu HTTP, zmienia się jedynie schemat:

curl -v --socks5 user:pass@proxy.proxeon.net:1080 https://example.com/

Przy tym curl nie będzie wysyłał żadnych wierszy CONNECT w formie tekstowej - zamiast tego przeprowadzi binarne uzgadnianie SOCKS5, a następnie przepompuje ruch TLS przez ustanowiony tunel. Dla aplikacji różnica jest niemal niezauważalna, ale na poziomie protokołu odbywa się zupełnie inna rozmowa.

Dlaczego SOCKS5 nie analizuje zawartości - i to jest jego siła

Filozofia SOCKS5 to minimalizm. Nie próbuje zrozumieć, czy w środku jest HTTP, SMTP czy twój własny protokół. To czyni go:

  • Uniwersalnym: każdy protokół TCP przechodzi bez specjalnego wsparcia.
  • Lekkim: uzgadnianie jest krótkie, parsowanie warstwy aplikacji nie występuje.
  • Przezroczystym: proxy nie ingeruje w dane, nic nie zmienia i nie buforuje.

Odwrotna strona tego samego medalu: SOCKS5 nie potrafi buforować, filtrować po URL ani dodawać nagłówków - ponieważ ich po prostu nie widzi. Uniwersalność jest opłacona rezygnacją z inteligencji aplikacyjnej.

Porównanie według kryteriów: co ważne w praktyce

Zbierzmy różnice w ustrukturyzowane porównanie według tych parametrów, które realnie wpływają na wybór w zadaniach inżynierskich.

Obsługa protokołów innych niż HTTP

SOCKS5 działa z dowolnym protokołem TCP: pocztowe IMAP i SMTP, bazy danych, protokoły gier, twoje własne binarne wymiany. Klasyczny HTTP proxy natywnie rozumie tylko HTTP. Przez CONNECT może tunelować inne protokoły TCP, ale tylko pod warunkiem, że proxy pozwala na odpowiedni port. W praktyce jest to często ograniczone do 443. Wniosek: dla dowolnych protokołów SOCKS5 jest preferowany.

UDP

HTTP proxy z UDP nie działa w ogóle - jego model opiera się na żądaniach TCP. SOCKS5 ma polecenie UDP ASSOCIATE i potrafi proxować datagramy. Nie omawiamy tu jego mechaniki szczegółowo, ale sam fakt jest ważny: jeśli zadanie wymaga UDP, HTTP proxy odpada od razu.

Narzut

Uzgadnianie SOCKS5 to kilka krótkich komunikatów binarnych. Dla nowego połączenia jest to bardzo tanie. HTTP proxy w trybie CONNECT traci jeden dodatkowy round-trip na parę żądanie CONNECT i odpowiedź 200 przed rozpoczęciem TLS. W scenariuszu wielu krótkich połączeń różnica w opóźnieniu może się kumulować. Z drugiej strony, przy stałym keep-alive i ponownym użyciu połączeń różnica się niweluje. Dla ruchu HTTP HTTP proxy może wygrywać dzięki cache i puli połączeń.

Buforowanie

Tu HTTP proxy nie ma konkurencji. Ponieważ rozumie semantykę HTTP, może buforować odpowiedzi, respektować nagłówki Cache-Control i ETag, zwracać 304 Not Modified. Dla powtarzających się żądań do statyki to odczuwalnie zmniejsza ruch i opóźnienie. SOCKS5 nie może buforować fizycznie - nie widzi, co jest w środku. Jeśli twoim zadaniem jest przyspieszenie masowych żądań HTTP do powtarzających się zasobów, buforujący HTTP proxy daje realną korzyść.

Logowanie i obserwowalność

HTTP proxy potrafi prowadzić szczegółowy access-log: metoda, URL, kod odpowiedzi, rozmiar, User-Agent. To cenne dla audytu, debugowania i analityki - przy pracy z niezaszyfrowanym HTTP. Dla HTTPS przez CONNECT szczegółowość spada do poziomu host-port-objętość. SOCKS5 loguje tylko metadane połączenia: adres docelowy, czas, objętość ruchu. Jeśli potrzebujesz obserwowalności aplikacyjnej po HTTP, wybierz HTTP proxy; jeśli wystarczą metryki transportowe, wystarczy SOCKS5.

Modyfikacja ruchu

HTTP proxy może legalnie dodawać i usuwać nagłówki, co jest przydatne dla celów technicznych. SOCKS5 w ogóle nie dotyka danych. Dla scenariuszy, w których ingerencja jest niedopuszczalna w zasadzie, przezroczystość SOCKS5 jest zaletą.

Zbiorcza tabela różnic

  • Poziom modelu: HTTP proxy - aplikacyjny L7; SOCKS5 - sesyjny L5.
  • Format dialogu: HTTP - tekstowy; SOCKS5 - binarny.
  • Protokoły inne niż HTTP: HTTP - tylko przez CONNECT i z ograniczeniami; SOCKS5 - natywnie.
  • UDP: HTTP - nie; SOCKS5 - tak.
  • Buforowanie: HTTP - tak; SOCKS5 - nie.
  • Logowanie aplikacyjne: HTTP - tak dla niezaszyfrowanego; SOCKS5 - tylko metadane.
  • Modyfikacja nagłówków: HTTP - tak; SOCKS5 - nie.
  • Narzut na połączenie: HTTP CONNECT - dodatkowy round-trip; SOCKS5 - minimalne.

Co wybrać pod zadanie: praktyczny framework

Teoria jest cenna, gdy zamienia się w rozwiązanie. Poniżej - framework wyboru i główna tabela dopasowania. Zacznijmy od trzech pytań, które warto sobie zadać przed wyborem.

Trzy pytania przed wyborem

  1. Jaki protokół przekazuję? Tylko HTTP i HTTPS - pasują oba, ale HTTP proxy daje bonusy cache i logów. Dowolny TCP lub UDP - tylko SOCKS5.
  2. Czy potrzebuję obserwowalności aplikacyjnej lub cache? Jeśli tak - HTTP proxy. Jeśli potrzebuję czystej przezroczystej rury - SOCKS5.
  3. Gdzie powinno odbywać się rozwiązywanie DNS? Jeśli ważne jest rozwiązywanie nazw po stronie proxy, weź pod uwagę zachowanie ATYP i ustawienia klienta.

Główna tabela: zadanie - protokół - dlaczego

  • Przeglądarka internetowa, zwykłe surfowanie - HTTP proxy lub SOCKS5 - oba działają; HTTP proxy doda cache i zgodność z politykami firmowymi, SOCKS5 jest prostszy dla niestandardowych portów.
  • Klient HTTP do integracji API - HTTP proxy - natywne wsparcie, prosta konfiguracja przez zmienne środowiskowe, szczegółowe logi do debugowania.
  • Masowe zbieranie danych przez HTTPS - SOCKS5 lub HTTP proxy - przy HTTPS oba są jedynie transportem; SOCKS5 oszczędza round-trip na krótkotrwałych połączeniach, HTTP proxy jest wygodny dzięki puli połączeń.
  • Klient pocztowy (SMTP, IMAP, POP3) - SOCKS5 - protokoły pocztowe nie są HTTP; HTTP proxy przez CONNECT jest często blokowany po portach.
  • Własne oprogramowanie z binarnym protokołem TCP - SOCKS5 - uniwersalny transport dla dowolnego TCP bez specjalnego wsparcia.
  • Aplikacja wymagająca UDP - SOCKS5 - jedyny wariant przez UDP ASSOCIATE; HTTP proxy nie umie UDP.
  • Przyspieszenie dostępu do powtarzającej się statyki - buforujący HTTP proxy - potrafi zwracać zbuforowane odpowiedzi i oszczędzać ruch.
  • Audyt i szczegółowy log żądań HTTP - HTTP proxy - widzi metody, URL i kody przy niezaszyfrowanym HTTP.
  • Praca z kilkoma protokołami jednocześnie z jednej aplikacji - SOCKS5 - jeden transport pokrywa wszystkie wymiany TCP.

Checklista wyboru

  • Określ protokół aplikacji: HTTP, inny TCP lub UDP.
  • Zdecyduj, czy potrzebny jest cache i log aplikacyjny.
  • Sprawdź, czy twój klient obsługuje potrzebny schemat proxy.
  • Ustal u dostawcy, jakie porty są otwarte dla CONNECT, jeśli planujesz tunelować nie-443.
  • Przemyśl, gdzie powinno odbywać się rozwiązywanie DNS.
  • Załóż uwierzytelnianie: loginem-hasłem lub po IP.

Zgodność w popularnych klientach i bibliotekach

Wybór protokołu nie ma sensu bez zrozumienia, jak go skonfigurować w konkretnych narzędziach. Przejdźmy przez typowe.

curl

curl obsługuje oba protokoły. Dla HTTP proxy użyj -x http://..., dla SOCKS5 - --socks5 lub -x socks5://.... Jest także wariant ze zdalnym rozwiązywaniem nazwy po stronie proxy SOCKS5, co ustawia się osobnym schematem; szczegóły zostały wyniesione do specjalistycznego materiału. Przykład:

curl -x socks5://user:pass@proxy.proxeon.net:1080 https://api.example.com/v1/status

Zmienne środowiskowe

Wiele narzędzi CLI i bibliotek respektuje zmienne http_proxy, https_proxy i all_proxy. Ta ostatnia często przyjmuje schemat SOCKS5. To wygodne dla konfiguracji przekrojowej bez edycji kodu:

export https_proxy=http://user:pass@proxy.proxeon.net:8080
export all_proxy=socks5://user:pass@proxy.proxeon.net:1080

Python: requests i httpx

Biblioteka requests konfiguruje się słownikiem proxies. Dla SOCKS5 wymagany jest dodatkowy pakiet z obsługą SOCKS:

import requests
proxies = {"http": "http://user:pass@proxy.proxeon.net:8080", "https": "http://user:pass@proxy.proxeon.net:8080"}
r = requests.get("https://example.com/", proxies=proxies, timeout=10)
print(r.status_code)

Dla SOCKS5 schemat zmienia się na socks5, a dla zdalnego rozwiązywania stosuje się osobny schemat. Biblioteka httpx działa podobnie i umie asynchroniczne żądania, co jest wygodne przy masowych operacjach.

Node.js

W ekosystemie Node proxy ustawia się przez specjalne agenty. Dla HTTP proxy używa się https-proxy-agent, dla SOCKS - socks-proxy-agent. Schematycznie:

const { SocksProxyAgent } = require('socks-proxy-agent');
const agent = new SocksProxyAgent('socks5://user:pass@proxy.proxeon.net:1080');
fetch('https://example.com/', { agent }).then(r => console.log(r.status));

Przeglądarki

Przeglądarki obsługują oba typy przez ustawienia systemowe lub pliki PAC. Rodzina Chromium przyjmuje flagę startową ze wskazaniem serwera proxy, a Firefox ma własne ustawienia, w tym opcję proxowania DNS przy użyciu SOCKS. Właśnie w przeglądarkach najczęściej ujawnia się pytanie, kto rozwiązuje nazwę - szczegóły w osobnym artykule o schematach SOCKS.

Klienty pocztowe

Klasyczne klienty pocztowe zwykle obsługują SOCKS5 jako transport dla SMTP i IMAP. HTTP proxy dla poczty stosuje się rzadko i tylko przez CONNECT, co często natrafia na ograniczenia portów. Praktyczny wniosek: dla poczty domyślnie rozważaj SOCKS5.

Własne oprogramowanie

Jeśli piszesz aplikację sam, SOCKS5 realizuje się biblioteką transportu lub nakładką na gniazdo. Dla klienta HTTP wewnątrz aplikacji prościej oprzeć się na wbudowanym wsparciu HTTP proxy w używanej bibliotece HTTP. Kluczowa rada: nie wymyślaj ręcznego parsowania uzgadniania SOCKS, używaj sprawdzonych bibliotek - binarny protokół łatwo zrealizować z błędami w przypadkach brzegowych.

Typowe błędne przekonania

Wokół tematu narosło wiele mitów. Przeanalizujmy je listą, abyś nie tracił czasu na fałszywe założenia.

  • "SOCKS5 jest zawsze szybszy od HTTP proxy". Nie zawsze. Na krótkich połączeniach SOCKS5 oszczędza round-trip, ale HTTP proxy z cache i pulą połączeń może go wyprzedzać na powtarzających się żądaniach HTTP.
  • "SOCKS5 szyfruje ruch". Nie. SOCKS5 nie dodaje szyfrowania. Prywatność zapewnia TLS wewnątrz tunelu, a nie sam SOCKS5. Nawet dane uwierzytelniające w klasycznym SOCKS5 są przesyłane bez wbudowanego szyfrowania.
  • "HTTP proxy widzi wszystko, łącznie z HTTPS". Nie. Dla HTTPS przez CONNECT proxy widzi jedynie nazwę hosta, port i objętość. Zawartość jest chroniona przez TLS.
  • "HTTP proxy i SOCKS5 to to samo na różnych portach". Nie. To różne protokoły. Zbieżność adresu serwera nie czyni ich identycznymi.
  • "SOCKS5 nie obsługuje uwierzytelniania". Obsługuje - metodą username/password według RFC 1929, możliwe jest także przypisanie po IP.
  • "Przez HTTP proxy nie można pracować z protokołami innymi niż HTTP". Można przez CONNECT, ale pod warunkiem, że proxy pozwala na potrzebny port.
  • "Jeśli przeglądarka jest skonfigurowana na SOCKS5, DNS zawsze rozwiązuje proxy". Nie zawsze. Zależy to od ustawień klienta i tego, czy przekazywana jest domena, czy już gotowy IP w polu ATYP.
  • "CONNECT działa tylko dla 443". Technicznie nie, ale administratorzy często ograniczają porty polityką.
  • "SOCKS5 potrafi buforować". Nie. Nie widzi zawartości i fizycznie nie może buforować.

Narzędzia i zasoby do pracy

Aby pewnie pracować z oboma protokołami, warto mieć pod ręką zestaw narzędzi diagnostyki i weryfikacji.

Diagnostyka połączeń

  • curl z flagą -v - najlepszy sposób, by zobaczyć rzeczywisty dialog: wiersz CONNECT, odpowiedź proxy, uzgadnianie TLS.
  • Analizator ruchu - pokazuje binarne uzgadnianie SOCKS5 i różnicę z tekstowym dialogiem HTTP na poziomie pakietów.
  • Narzędzia sprawdzania otwartości portów - pomagają zrozumieć, które porty są dostępne dla CONNECT na twoim proxy.

Biblioteki

  • Dla Pythona - requests i httpx z rozszerzeniem obsługi SOCKS.
  • Dla Node.js - agenty https-proxy-agent i socks-proxy-agent.
  • Dla integracji systemowej - zmienne środowiskowe http_proxy, https_proxy, all_proxy.

Co sprawdzać przy podłączaniu do Proxeon

  • Właściwy schemat: http dla HTTP proxy, socks5 dla SOCKS5.
  • Poprawny port dla każdego trybu - są różne.
  • Metodę uwierzytelniania: login-hasło lub przypisanie po IP.
  • Listę dozwolonych portów dla CONNECT, jeśli planujesz tunelować nie-443.
  • Zachowanie DNS: gdzie dokładnie chcesz rozwiązywać nazwy.

Mini-framework debugowania

  1. Powtórz żądanie bezpośrednio bez proxy - upewnij się, że cel jest dostępny.
  2. Powtórz z proxy i flagą -v - przeanalizuj dialog.
  3. Jeśli HTTPS się nie ustanawia - sprawdź, czy port dla CONNECT jest dozwolony.
  4. Jeśli nazwa się nie rozwiązuje - sprawdź, czy do proxy idzie domena czy IP.
  5. Jeśli 407 - sprawdź dane uwierzytelniające i nagłówek Proxy-Authorization.

Case'y i wyniki zastosowania

Rozważmy kilka typowych scenariuszy inżynierskich i to, jak wybór protokołu wpływa na wynik. Liczby są umowne i służą ilustracji zależności, a nie obietnicy reklamowej.

Case 1: Integracja API z zewnętrzną usługą

Zespół zintegrował swój backend z zewnętrznym REST API przez proxy Proxeon dla kontroli adresu wychodzącego. Początkowo wybrano SOCKS5, ale napotkano problem, że standardowa biblioteka HTTP łatwiej konfigurowała się na HTTP proxy przez zmienne środowiskowe. Przejście na HTTP proxy uprościło konfigurację, a szczegółowe access-logi z niezaszyfrowanych wywołań technicznych pomogły szybko znajdować przyczyny błędów 5xx po stronie partnera. Wniosek: dla czystego HTTP API wygodniejszy jest HTTP proxy.

Case 2: Brama pocztowa

Usługa wysyłała powiadomienia przez SMTP z ustalonego adresu wychodzącego. Próba użycia HTTP proxy przez CONNECT nie powiodła się: proxy pozwalał tylko na 443. Przełączenie na SOCKS5 rozwiązało zadanie natychmiast, ponieważ SOCKS5 jest neutralny wobec protokołu i przeprowadził połączenie na 587 bez ograniczeń na poziomie rozumienia warstwy aplikacji. Wniosek: dla protokołów innych niż HTTP SOCKS5 to naturalny wybór.

Case 3: Masowe zbieranie publicznych danych przez HTTPS

Przy zbieraniu dużej liczby stron przez HTTPS inżynierowie porównali oba tryby. Na wielu krótkotrwałych połączeniach SOCKS5 dawał nieco mniejsze średnie opóźnienie ustanowienia dzięki brakowi dodatkowego round-trip CONNECT. Kiedy natomiast włączono ponowne użycie połączeń i keep-alive przez HTTP proxy, różnica niemal zniknęła. Wniosek: przy krótkotrwałych połączeniach SOCKS5 oszczędza na uzgadnianiu, przy długich - różnica jest nieistotna.

Case 4: Własny binarny protokół telemetrii

Firma przekazywała telemetrię przez własny protokół TCP. HTTP proxy nie pasował konceptualnie - protokół nie jest HTTP. SOCKS5 stał się jedynym rozsądnym transportem: aplikacja otwierała zwykłe gniazdo przez agenta SOCKS5 i protokół działał bez zmian. Wniosek: dla dowolnego TCP SOCKS5 jest niezastąpiony.

Case 5: Przyspieszenie dostępu do statyki

Wewnętrzna usługa często odwoływała się do tego samego zestawu statycznych zasobów po HTTP. Buforujący HTTP proxy wyraźnie zmniejszył ruch wychodzący i czas odpowiedzi dzięki zwracaniu zbuforowanych reprezentacji i poprawnej obsłudze żądań warunkowych. SOCKS5 nie mógł dać takiej optymalizacji w zasadzie. Wniosek: gdzie jest powtarzalność żądań HTTP, buforujący HTTP proxy przynosi wymierną korzyść.

FAQ: często zadawane pytania

Czy można używać tego samego konta Proxeon i do HTTP, i do SOCKS5?

Z reguły tak - zmieniają się jedynie schemat i port połączenia. Ustal w swoim panelu, które porty odpowiadają każdemu trybowi i jaka metoda uwierzytelniania jest ustawiona. Technicznie to ten sam zasób, udostępniony w dwóch trybach.

Co wybrać, jeśli nie jestem pewien, jaki protokół jest mi potrzebny?

Jeśli twoja aplikacja pracuje wyłącznie z HTTP i HTTPS - zacznij od HTTP proxy, jest prostszy w konfiguracji i daje logi z cache. Jeśli pojawia się choć jeden protokół inny niż HTTP lub UDP - wybierz SOCKS5 jako bardziej uniwersalny transport.

Dlaczego przy HTTPS różnica między HTTP proxy a SOCKS5 jest niemal niezauważalna?

Ponieważ przy HTTPS zawartość jest chroniona przez TLS, a oba typy proxy są jedynie transportem. HTTP proxy w tym przypadku przez CONNECT staje się taką samą rurą jak SOCKS5. Różni się tylko sposób uzgodnienia tunelu: tekstowy CONNECT kontra binarne uzgadnianie.

Czy wybór protokołu wpływa na to, kto wykonuje rozwiązywanie DNS?

Tak, pośrednio. W SOCKS5 reguluje to pole ATYP: jeśli przekazywana jest domena, rozwiązuje proxy, jeśli IP - klient. W HTTP proxy nazwa z URL lub z wiersza CONNECT także może być rozwiązywana po stronie proxy. Dokładne zachowanie zależy od klienta i jego ustawień, a szczegółowe omówienie wynieśliśmy do osobnego materiału.

Czy bezpieczne jest przekazywanie loginu i hasła w SOCKS5?

Klasyczny SOCKS5 nie szyfruje danych uwierzytelniających wbudowanie. Dlatego używaj go w zaufanym środowisku lub w połączeniu z dodatkowymi środkami ochrony. Dla proxy usługowych często dostępne jest przypisanie po IP, które zmniejsza zależność od przekazywania hasła przy każdym połączeniu.

Czy można tunelować dowolny port przez CONNECT?

Technicznie specyfikacja nie zabrania, ale w praktyce administrator proxy nierzadko ogranicza listę portów ze względów bezpieczeństwa. Najczęściej dozwolony jest 443. Jeśli potrzebujesz niestandardowego portu, ustal politykę lub rozważ SOCKS5, który jest neutralny wobec portów.

Czy SOCKS5 daje większą anonimowość niż HTTP proxy?

Sam w sobie nie. Anonimowość określa nie typ protokołu, lecz to, jakie metadane są przekazywane i logowane oraz czy ruch jest chroniony przez TLS. HTTP proxy może dodawać nagłówki techniczne ujawniające klienta, ale przy poprawnej konfiguracji można tego uniknąć. SOCKS5 nie dodaje nagłówków aplikacyjnych po prostu dlatego, że ich nie widzi.

Co się stanie, jeśli serwer docelowy za proxy jest niedostępny?

HTTP proxy zwróci kod błędu na poziomie HTTP, na przykład 502 lub 504. SOCKS5 zwróci kod błędu w odpowiedzi na polecenie połączenia - na przykład nieosiągalność hosta lub odmowę połączenia. W obu przypadkach klient otrzyma czytelny sygnał, ale w innej formie: tekstowej w HTTP i binarnej w SOCKS5.

Czy potrzebny jest osobny proxy do UDP?

UDP obsługuje tylko SOCKS5 przez polecenie UDP ASSOCIATE. HTTP proxy z UDP nie działa. Mechanikę tego polecenia omawiamy szczegółowo w osobnym artykule, tutaj ważne jest jedynie zapamiętanie samego faktu: jeśli potrzebujesz UDP - to terytorium SOCKS5.

Jak poznać, że proxy rzeczywiście działa w potrzebnym trybie?

Najbardziej niezawodny sposób - wykonać żądanie przez curl z flagą -v i obejrzeć dialog. Dla HTTP proxy zobaczysz absolutny URI lub wiersz CONNECT, dla SOCKS5 - brak tekstowego dialogu HTTP aż do samego żądania i poprawny kod odpowiedzi. Dodatkowo można sprawdzić adres wychodzący przez usługę pokazującą twój IP.

Zakończenie: jak podjąć właściwą decyzję

Przeszliśmy drogę od filozofii dwóch protokołów do konkretnych wierszy kodu. Podsumujmy inżyniersko i bez zbędnych słów.

HTTP proxy - to inteligentny pośrednik poziomu aplikacji. Rozumie HTTP, widzi i może zmieniać niezaszyfrowane żądania, umie buforować i prowadzić szczegółowe logi. Jego metoda CONNECT zamienia go w tunel TCP dla HTTPS i innych protokołów, ale z zastrzeżeniem co do dozwolonych portów. Wybierz go, gdy pracujesz głównie z HTTP i HTTPS i cenisz obserwowalność oraz cache.

SOCKS5

O autorze

Andrey Kokh

Andrey Kokh

Leading Expert and Business Consultant

Doświadczenie zawodowe: Leading expert with 12 years of experience. Consults Forbes-listed companies, author of 3 books. Teaches at HSE and SKOLKOVO. His methodologies are used by hundreds of companies across Russia. RBC and Forbes expert on strategic development and digital transformation.
Wykształcenie: Higher School of Economics. Faculty of Economics, Master's Program
Ekspertyza:
Strategic Consulting Digital Transformation Change Management Business Strategy Innovation Management Organizational Development Lean Management Agile Transformation

Podziel się artykułem: