SOCKS5 vs HTTP proxy: czym się różnią i którego użyć

Jak proxy HTTP przenosi ruch HTTPS?

Proxy HTTP przenosi ruch HTTPS przez tunel, który Twój klient otwiera metodą CONNECT z RFC 9110. Klient podaje host i port, proxy łączy się z nim i odpowiada 200, a od tego momentu tylko przesyła zaszyfrowane bajty.

Wymiana wygląda tak, z danymi uwierzytelniającymi z dokumentacji:

CONNECT api.ipify.org:443 HTTP/1.1
Host: api.ipify.org:443
Proxy-Authorization: Basic VVNFUk5BTUU6UEFTU1dPUkQ=

HTTP/1.1 200 Connection established

Jak proxy SOCKS5 otwiera połączenie?

Proxy SOCKS5 otwiera połączenie w trzech krótkich wymianach binarnych zdefiniowanych przez RFC 1928: powitanie uzgadniające metodę uwierzytelniania, logowanie oraz żądanie połączenia z docelowym adresem. Tabela pokazuje bajty dla logowania z nazwą użytkownika i hasłem (RFC 1929) oraz żądania dla api.ipify.org na porcie 443.

RFC 1929 wysyła nazwę użytkownika i hasło w postaci jawnej, każde do 255 bajtów. Podobnie jak uwierzytelnianie Basic przez HTTP, samo w sobie niczego nie chroni; sesja TLS ze stroną działa później wewnątrz przekaźnika. Lista dozwolonych IP pozwala w ogóle uniknąć wysyłania hasła. Opcje logowania: Nazwa użytkownika i hasło lub lista dozwolonych IP (do 10 IP).

Jaka jest różnica między socks5 a socks5h?

W przypadku socks5:// Twoja maszyna sama rozwiązuje nazwę hosta i wysyła do proxy adres IP; w przypadku socks5h:// proxy otrzymuje nazwę hosta i rozwiązuje ją. Litera „h” oznacza hostname (nazwę hosta). Nazwy pochodzą z curl i są też używane przez Python requests z PySocks.

Różnica ma znaczenie pod dwoma względami. Po pierwsze, lokalne rozwiązywanie wysyła zapytanie DNS z Twojej sieci, co informuje Twój resolver, które strony odwiedzasz. Po drugie, odpowiedź DNS uzyskana lokalnie może wskazywać serwer blisko Ciebie, a nie blisko proxy, więc CDN może obsłużyć Cię z niewłaściwego regionu. Używaj socks5h://, chyba że masz powód, by postąpić inaczej. Proxy HTTP zawsze rozwiązują po stronie proxy, ponieważ CONNECT przenosi nazwę hosta.

curl -x socks5h://USERNAME:[email protected]:PORT https://api.ipify.org
curl -x http://USERNAME:[email protected]:PORT https://api.ipify.org

Czy SOCKS5 obsługuje UDP?

Standard SOCKS5 definiuje przekazywanie UDP przez polecenie UDP ASSOCIATE, ale obsługa zależy od serwera i klienta. Wiele usług proxy i wiele bibliotek klienckich implementuje tylko TCP.

RackProxies sprzedaje swoje IP do HTTP, HTTPS (CONNECT) i SOCKS5 i nie obiecujemy UDP. Jeśli Twoje zastosowanie wymaga UDP, przetestuj to w planie 1 IP przed zakupem większej liczby, i najpierw zapytaj support. W przypadku żądań webowych, API i monitoringu po HTTPS TCP to wszystko, czego potrzebujesz.

Który wybrać do mojego narzędzia?

Wybierz HTTP, gdy Twoje narzędzie obsługuje HTTP, a SOCKS5, gdy go nie obsługuje lub obsługuje tylko SOCKS. W praktyce:

• Python requests, Node.js fetch z undici, Playwright, Scrapy: HTTP działa od razu. SOCKS5 wymaga dodatkowego pakietu w requests (requests[socks]).
• curl i wget: curl obsługuje oba; wget używa proxy HTTP.
• Przeglądarki: oba, ale wbudowany klient SOCKS5 w Chromium historycznie nie obsługiwał uwierzytelniania nazwą użytkownika i hasłem, więc bezpiecznym wyborem jest forma HTTP lub allowlista.
• Klienci TCP nie-HTTP (narzędzia do baz danych, niestandardowe protokoły): SOCKS5.

Przykłady kodu pokazują każdy przypadek, a quickstart testuje oba protokoły z curl.