SOCKS5 Proxy Auth Relay: Zbudować czy całkowicie pominąć
Chrome i wiele narzędzi automatyzacyjnych nadal nie potrafi uwierzytelnić się z proxy SOCKS5. Mały lokalny przekaźnik rozwiązuje ten problem, przechowując dane uwierzytelniające — oto minimalnie działający przykład, gotowe narzędzia oraz przypadki, kiedy w ogóle go nie potrzebujesz.
SOCKS5 proxy auth relay to mały lokalny proces, który odpowiada na wyzwanie proxy dotyczące nazwy użytkownika/hasła w Twoim imieniu, a następnie przekazuje Twojemu narzędziu prosty, nieautoryzowany punkt końcowy na 127.0.0.1. Istnieje, aby załatać uporczywą lukę: Chromium nigdy nie obsługiwało uwierzytelnionego SOCKS5 (śledzone jako błąd Chromium 40829748), a wiele narzędzi automatyzacyjnych akceptuje tylko goły host:port. Wątek na Reddit, który zyskał popularność — ktoś na tyle sfrustrowany, by zbudować mały przekaźnik, ponieważ narzędzia nadal nie mogły obsłużyć uwierzytelnionego SOCKS5 — to cały gatunek w jednym zdaniu. Ten przewodnik pokazuje minimalnie działający przekaźnik, gotowe narzędzia oraz, co równie ważne, kiedy go nie potrzebujesz.
Wzorzec: brak uwierzytelnienia z przodu, uwierzytelnienie z tyłu
Każdy przekaźnik w tej przestrzeni robi to samo. Słucha lokalnie bez uwierzytelnienia, a dla każdego połączenia otwiera połączenie do góry, używając Twoich prawdziwych danych uwierzytelniających. Twoje narzędzie łączy się z 127.0.0.1 — bez potrzeby hasła — a przekaźnik wykonuje handshake uwierzytelniania SOCKS5 do bramy SOCKS5. Dane uwierzytelniające znajdują się w jednym miejscu, na loopback, i nigdy nie dotykają konfiguracji narzędzia. To ma znaczenie z drugiego powodu: SOCKS5 nie jest szyfrowany i przesyła dane uwierzytelniające w postaci niezaszyfrowanej, więc utrzymanie uwierzytelnionego połączenia na własnej maszynie, przypięte do 127.0.0.1, to bezpieczny sposób na to.
Przekaźnik na jedno polecenie: gost
Rzadko musisz pisać przekaźnik ręcznie. gost to narzędzie open-source do tunelowania, które implementuje pełną specyfikację SOCKS5, w tym uwierzytelnianie nazwą użytkownika/hasłem, i zamienia całą pracę w jedno polecenie. Udostępnij lokalnie słuchacza SOCKS5 bez uwierzytelnienia i przekieruj do uwierzytelnionego upstream:
# local no-auth SOCKS5 on :1080 -> authenticated SOCKS5 upstream
gost -L socks5://:1080 -F socks5://USER:PASS@gate.quantumproxies.io:PORT
# now point any tool at the loopback address, no credentials:
# --proxy-server=socks5://127.0.0.1:1080 (Chrome, nodriver, zendriver)Jeśli Twoje narzędzie obsługuje HTTP, ale nie SOCKS5, to samo polecenie konwertuje protokoły — udostępnij lokalny proxy HTTP, który przekierowuje do uwierzytelnionej bramy SOCKS5. To czysta odpowiedź na powracające pytanie "convert SOCKS5 to HTTP proxy", i przewyższa klasyczną konfigurację Privoxy, ponieważ gost obsługuje uwierzytelnienie upstream w jednym miejscu:
# local HTTP proxy on :8080 -> authenticated SOCKS5 upstream
gost -L http://:8080 -F socks5://USER:PASS@gate.quantumproxies.io:PORT
# Chrome/curl/anything with an HTTP proxy setting can now use 127.0.0.1:8080
Minimalny przekaźnik od podstaw
Jeśli wolisz zrozumieć działające elementy, oto najmniejsza użyteczna wersja w czystym Pythonie. Używa PySocks (pip install PySocks) do otwarcia uwierzytelnionego połączenia upstream i przesyła bajty w obie strony. Ten konkretny szkic tuneluje jeden docelowy host — wystarczająco, aby skrobać jedno API przez uwierzytelnione wyjście SOCKS5 — co utrzymuje go krótkim i poprawnym; ogólny serwer SOCKS5, który parsuje handshake klienta, to coś, co narzędzia takie jak gost już robią za Ciebie:
import asyncio, socks # PySocks
UP_HOST, UP_PORT = "gate.quantumproxies.io", 0000 # your SOCKS5 gateway
UP_USER, UP_PASS = "USER", "PASS"
TARGET = ("example.com", 443) # the one host to reach
async def pipe(reader, writer):
try:
while data := await reader.read(65536):
writer.write(data)
await writer.drain()
finally:
writer.close()
async def handle(local_r, local_w):
# open the upstream leg with SOCKS5 auth (PySocks is blocking -> a thread)
up = await asyncio.to_thread(
socks.create_connection, TARGET,
proxy_type=socks.SOCKS5, proxy_addr=UP_HOST, proxy_port=UP_PORT,
username=UP_USER, password=UP_PASS,
)
up_r, up_w = await asyncio.open_connection(sock=up)
await asyncio.gather(pipe(local_r, up_w), pipe(up_r, local_w))
async def main():
server = await asyncio.start_server(handle, "127.0.0.1", 1080)
async with server:
await server.serve_forever()
asyncio.run(main())Dla pełnego lokalnego serwera SOCKS5, na który każdy klient może wskazać, społecznościowy projekt socks-relay na GitHub to dobry punkt odniesienia: uruchamia słuchacza bez uwierzytelnienia lub z user/pass i przekierowuje do innego serwera SOCKS5, w kilku setkach linii zbudowanych na PySocks. Projekt socks-to-http-proxy (Rust) wykonuje zadanie konwersji HTTP, jeśli wolisz skompilowany binarny. W każdym przypadku uruchamiasz ten sam wzorzec, który gost daje Ci w jednej linii.
Kiedy NIE potrzebujesz przekaźnika
Przekaźnik to krok, który posiadasz, i często możesz usunąć cały problem zamiast niego. Pomiń go, gdy którakolwiek z tych sytuacji jest prawdziwa:
- Twój dostawca ma punkt końcowy HTTP. Proxy HTTP uwierzytelniają się za pomocą Basic auth w URL, co obsługuje prawie każde narzędzie. Wskaż na bramę HTTP, a problem z uwierzytelnieniem SOCKS5 znika — kompromisy są omówione w SOCKS5 vs HTTP.
- Dostępne jest białe listowanie IP. Zarejestruj swój adres IP wyjściowy u dostawcy i nie ma żadnych danych uwierzytelniających do przekazywania. Każdy plan QuantumProxies obsługuje białe listowanie obok user:pass na swoich proxy rezydencjalnych — najprostsze rozwiązanie, gdy Twój IP jest stabilny.
- Twoja biblioteka już obsługuje uwierzytelnianie SOCKS5. curl, Python
requests[socks]ihttpx, oraz większość klientów HTTP obsługuje natywnie uwierzytelnione SOCKS5. Przekaźnik jest tylko dla narzędzi, które nie mogą — głównie przeglądarki oparte na Chromium.
# no relay needed — curl authenticates SOCKS5 directly (socks5h resolves DNS
# through the proxy, avoiding leaks):
curl -x socks5h://USER:PASS@gate.quantumproxies.io:PORT https://httpbin.org/ip
# and HTTP Basic proxy auth is even more widely supported:
curl -x http://USER:PASS@gate.quantumproxies.io:PORT https://httpbin.org/ip
Szczera wada
Uruchamianie własnego przekaźnika dodaje punkt awarii. To kolejny proces do nadzorowania: jeśli się zawiesi, każde żądanie za nim zawiedzie, a goły skrypt nie zapewnia restartu, kontroli zdrowia ani logowania, chyba że je dodasz. Nie ma własnej rotacji — przekierowuje do jednego skonfigurowanego upstream, więc rotacja wyjścia nadal musi pochodzić z bramy. Dodaje opóźnienie, a także przechowuje dane uwierzytelniające w pamięci w postaci niezaszyfrowanej, co jest dokładnie powodem, dla którego musi być przypięty do 127.0.0.1 i nigdy do publicznego interfejsu. Dla laptopa skrobiącego jedną stronę to w porządku. Dla czegokolwiek, co wymaga powiadomień, lepiej wybrać rozwiązanie bez nowych ruchomych części — białe listowanie lub punkt końcowy HTTP — zamiast przekaźnika, który teraz musisz utrzymać przy życiu.
Ten sam wzorzec przekaźnika pojawia się w całym ekosystemie stealth, ponieważ luka SOCKS5 w Chromium jest wspólna dla każdej przeglądarki na nim zbudowanej. Jeśli integrujesz to z konkretnym frameworkiem, zobacz Playwright SOCKS5 authentication i nasz przewodnik rozwiązywania problemów 407 dla błędów, które napotkasz po drodze.
Często zadawane pytania
Czym jest przekaźnik uwierzytelniania proxy SOCKS5?
Mały lokalny proces, który słucha bez uwierzytelnienia i przekierowuje każde połączenie do upstream proxy SOCKS5, używając Twojej nazwy użytkownika i hasła. Pozwala narzędziom, które nie mogą przesłać danych uwierzytelniających SOCKS5 — głównie przeglądarkom opartym na Chromium — dotrzeć do uwierzytelnionego proxy, wskazując na adres loopback, taki jak 127.0.0.1:1080. gost tworzy jeden w jednym poleceniu.
Jak przekonwertować proxy SOCKS5 na proxy HTTP?
Nie możesz przekonwertować samego proxy; uruchamiasz pośrednika, który lokalnie obsługuje HTTP, a upstream SOCKS5. gost -L http://:8080 -F socks5://USER:PASS@host:port udostępnia lokalny proxy HTTP, który przekierowuje do uwierzytelnionej bramy SOCKS5. Dedykowane narzędzia, takie jak socks-to-http-proxy i Privoxy, wykonują tę samą pracę, jeśli je preferujesz.
Dlaczego Chrome nie może używać uwierzytelnionego proxy SOCKS5?
Chromium nigdy nie zaimplementowało uwierzytelniania SOCKS5 nazwą użytkownika/hasłem — to długotrwałe ograniczenie zarejestrowane jako błąd Chromium 40829748. Nieautoryzowane SOCKS5 działa przez --proxy-server=socks5://host:port, ale nie ma sposobu na dostarczenie danych uwierzytelniających. Lokalny przekaźnik lub białe listowanie IP to standardowe rozwiązanie, a rozszerzenie proxy-auth obejmuje proxy HTTP.
Czy bezpieczne jest przesyłanie danych uwierzytelniających SOCKS5 do przekaźnika?
Tylko przez loopback. SOCKS5 nie jest szyfrowany i przesyła dane uwierzytelniające w postaci niezaszyfrowanej, więc przekaźnik musi być przypięty do 127.0.0.1 i nigdy do publicznego interfejsu — to utrzymuje uwierzytelnione połączenie na Twojej własnej maszynie. Szyfrowany tunel do celu jest ustanawiany end-to-end dla HTTPS niezależnie, więc przekaźnik widzi tylko bajty TLS, których nie może odczytać.
Sięgnij po przekaźnik tylko wtedy, gdy narzędzie nie daje Ci wyboru. gost to odpowiedź na jedno polecenie, PySocks to wersja od podstaw — ale najszybszym rozwiązaniem dla większości ludzi jest białe listowanie IP lub użycie punktu końcowego HTTP i nie uruchamianie niczego dodatkowego. Mniej ruchomych części, mniej powiadomień o 3 nad ranem.