# 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](https://quantumproxies.io/socks5-proxies). 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:

```bash
# local no-auth SOCKS5 on :1080  ->  authenticated SOCKS5 upstream
gost -L socks5://:1080 -F socks5://USER:PASS@residentialpremium.quantumproxies.io:1080

# 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:

```bash
# local HTTP proxy on :8080  ->  authenticated SOCKS5 upstream
gost -L http://:8080 -F socks5://USER:PASS@residentialpremium.quantumproxies.io:1080

# Chrome/curl/anything with an HTTP proxy setting can now use 127.0.0.1:8080
```

![Lokalny przekaźnik uwierzytelniania SOCKS5 w trzech przeskokach: narzędzie łączy się z nasłuchem bez uwierzytelniania na 127.0.0.1:1080, przekaźnik dodaje nazwę użytkownika i hasło, a uwierzytelniona brama odbiera handshake SOCKS5. Karta pokazuje, gdzie znajdują się dane uwierzytelniające: tylko w przekaźniku, powiązanym z interfejsem loopback.](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785776557/blog/generated/qp-b10-035-diag1.png)
*Przekaźnik przechowuje dane uwierzytelniające na loopback i wykonuje handshake uwierzytelniania SOCKS5, więc narzędzie widzi tylko nieautoryzowany punkt końcowy.*

## 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:

```python
import asyncio, socks   # PySocks

UP_HOST, UP_PORT = "residentialpremium.quantumproxies.io", 1080   # 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](https://quantumproxies.io/blog/socks5-vs-http-proxy-difference).
- **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](https://quantumproxies.io/residential-proxies) — najprostsze rozwiązanie, gdy Twój IP jest stabilny.
- **Twoja biblioteka już obsługuje uwierzytelnianie SOCKS5.** curl, Python `requests[socks]` i `httpx`, 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.

```bash
# no relay needed — curl authenticates SOCKS5 directly (socks5h resolves DNS
# through the proxy, avoiding leaks):
curl -x socks5h://USER:PASS@residentialpremium.quantumproxies.io:1080 https://httpbin.org/ip

# and HTTP Basic proxy auth is even more widely supported:
curl -x http://USER:PASS@residentialpremium.quantumproxies.io:8080 https://httpbin.org/ip
```

![Kiedy przekaźnik uwierzytelniania SOCKS5 jest zbędny, a kiedy się opłaca: curl, Python requests i httpx natywnie uwierzytelniają się w SOCKS5, natomiast przeglądarki oparte na Chromium nie potrafią wysłać danych uwierzytelniających SOCKS5. Karta wymienia, co eliminuje przekaźnik: punkt końcowy HTTP, białe listowanie IP lub klient z natywnym uwierzytelnianiem SOCKS5.](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785776556/blog/generated/qp-b10-035-diag2.png)
*Większość konfiguracji może pominąć przekaźnik: punkt końcowy HTTP, białe listowanie IP lub klient, który natywnie obsługuje uwierzytelnianie SOCKS5, usuwają potrzebę jego użycia.*

## 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](https://quantumproxies.io/blog/playwright-socks5-proxy-authentication) i nasz [przewodnik rozwiązywania problemów 407](https://quantumproxies.io/blog/fix-407-proxy-authentication-required) 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.

[Zdobądź proxy SOCKS5 z białym listowaniem IP](https://quantumproxies.io/socks5-proxies)