# SOCKS5 Proxy Auth Relay: Costruirne uno o evitarlo del tutto

Chrome e molti strumenti di automazione non riescono ancora ad autenticare un proxy SOCKS5. Un piccolo relay locale risolve il problema gestendo le credenziali — ecco un esempio minimo funzionante, gli strumenti pronti all'uso e i casi in cui non è necessario.

Un **relay di autenticazione per proxy SOCKS5** è un piccolo processo locale che risponde alla richiesta di username/password di un proxy per conto tuo, quindi fornisce al tuo strumento un endpoint semplice, senza autenticazione su `127.0.0.1`. Esiste per colmare una lacuna ostinata: Chromium non ha mai supportato SOCKS5 autenticato (tracciato come bug di Chromium 40829748), e molti strumenti di automazione accettano solo un semplice `host:port`. Un thread su Reddit che ha fatto il giro — qualcuno abbastanza frustrato da costruire un piccolo relay perché gli strumenti non riuscivano ancora a gestire SOCKS5 autenticato — riassume tutto il genere in una frase. Questa guida mostra un relay minimo funzionante, gli strumenti pronti all'uso e, altrettanto importante, quando non ne hai bisogno.

## Il modello: senza autenticazione davanti, autenticato dietro

Ogni relay in questo ambito fa la stessa cosa. Ascolta localmente senza autenticazione e per ogni connessione apre il collegamento a monte utilizzando le tue credenziali reali. Il tuo strumento si connette a `127.0.0.1` — senza bisogno di password — e il relay esegue l'handshake di autenticazione SOCKS5 al [gateway SOCKS5](https://quantumproxies.io/socks5-proxies). Le credenziali risiedono in un unico posto, sul loopback, e non toccano mai la configurazione dello strumento. Questo è importante per un secondo motivo: SOCKS5 non è criptato e trasmette le credenziali in chiaro, quindi mantenere il collegamento autenticato sulla tua macchina, legato a `127.0.0.1`, è il modo sicuro di farlo.

## Il relay con un solo comando: gost

Raramente hai bisogno di scrivere un relay a mano. `gost` è uno strumento di tunneling open-source che implementa l'intera specifica SOCKS5, inclusa l'autenticazione username/password, e trasforma l'intero lavoro in un unico comando. Esporre un listener SOCKS5 senza autenticazione localmente e inoltrare al tuo upstream autenticato:

```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)
```

Se il tuo strumento parla HTTP ma non SOCKS5, lo stesso comando converte i protocolli — espone un proxy HTTP locale che inoltra al gateway SOCKS5 autenticato. Questa è la risposta pulita alla ricorrente domanda "convertire SOCKS5 in proxy HTTP", e supera la classica configurazione di Privoxy perché gost gestisce l'autenticazione a monte in un unico posto:

```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
```

![Un relay di autenticazione SOCKS5 locale in tre passaggi: lo strumento si connette a un listener senza autenticazione su 127.0.0.1:1080, il relay aggiunge nome utente e password e il gateway autenticato riceve la stretta di mano SOCKS5. La scheda mostra dove stanno le credenziali: solo nel relay, vincolato al loopback.](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785776557/blog/generated/qp-b10-035-diag1.png)
*Il relay mantiene le credenziali sul loopback ed esegue l'handshake di autenticazione SOCKS5, quindi lo strumento vede solo un endpoint senza autenticazione.*

## Un relay minimo da zero

Se preferisci capire le parti in movimento, ecco la versione più piccola utile in puro Python. Utilizza PySocks (`pip install PySocks`) per aprire il collegamento a monte autenticato e trasferisce byte in entrambe le direzioni. Questo particolare schema tunnelizza un host target — sufficiente per eseguire il scraping di una singola API attraverso un'uscita SOCKS5 autenticata — il che lo mantiene breve e corretto; un server SOCKS5 generale che analizza l'handshake del client è ciò che strumenti come gost già fanno per te:

```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())
```

Per un server SOCKS5 locale completo a cui qualsiasi client può puntare, il progetto comunitario `socks-relay` su GitHub è un buon riferimento: esegue un listener senza autenticazione o con user/pass e inoltra a un altro server SOCKS5, in un paio di centinaia di righe costruite su PySocks. Il progetto `socks-to-http-proxy` (Rust) svolge il lavoro di conversione HTTP se preferisci un binario compilato. In entrambi i casi stai eseguendo lo stesso modello che gost ti offre in una riga.

## Quando NON hai bisogno di un relay

Un relay è un passaggio che possiedi, e spesso puoi eliminare l'intero problema invece. Evitalo quando una di queste condizioni è vera:

- **Il tuo provider ha un endpoint HTTP.** I proxy HTTP si autenticano con Basic auth nell'URL, che quasi tutti gli strumenti gestiscono. Punta al gateway HTTP e il problema dell'autenticazione SOCKS5 scompare — i compromessi sono trattati in [SOCKS5 vs HTTP](https://quantumproxies.io/blog/socks5-vs-http-proxy-difference).
- **È disponibile la whitelist degli IP.** Registra il tuo IP di uscita con il provider e non ci sono credenziali da inoltrare. Ogni piano QuantumProxies supporta la whitelist insieme a user:pass sui suoi [proxy residenziali](https://quantumproxies.io/residential-proxies) — la soluzione più semplice quando il tuo IP è stabile.
- **La tua libreria già supporta l'autenticazione SOCKS5.** curl, Python `requests[socks]` e `httpx`, e la maggior parte dei client HTTP parlano SOCKS5 autenticato nativamente. Il relay è solo per strumenti che non possono — principalmente browser basati su 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
```

![Quando un relay di autenticazione SOCKS5 è inutile e quando serve davvero: curl, Python requests e httpx gestiscono l'autenticazione SOCKS5 in modo nativo, mentre i browser basati su Chromium non possono inviare credenziali SOCKS5. La scheda elenca cosa rende superfluo il relay: un endpoint HTTP, la whitelist degli IP o un client con autenticazione SOCKS5 nativa.](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785776556/blog/generated/qp-b10-035-diag2.png)
*La maggior parte delle configurazioni può evitare il relay: un endpoint HTTP, la whitelist degli IP o un client che supporta nativamente l'autenticazione SOCKS5 eliminano la necessità di uno.*

## Il lato negativo onesto

Gestire il tuo relay aggiunge un punto di guasto. È un altro processo da supervisionare: se si arresta, ogni richiesta dietro di esso fallisce, e uno script semplice non ti offre riavvio, controllo dello stato e registrazione a meno che non li aggiungi. Non ha una rotazione propria — inoltra a qualsiasi upstream singolo tu abbia configurato, quindi la rotazione dell'uscita deve ancora venire dal gateway. Aggiunge un passaggio di latenza e mantiene le credenziali in chiaro in memoria, ed è esattamente per questo che deve essere legato a `127.0.0.1` e mai a un'interfaccia pubblica. Per un laptop che esegue scraping di un sito, va bene. Per qualsiasi cosa su cui fai paging, preferisci una soluzione senza nuove parti mobili — whitelist o un endpoint HTTP — rispetto a un relay che ora devi mantenere in vita.

Lo stesso modello di relay appare in tutto l'ecosistema stealth, perché la lacuna di SOCKS5 di Chromium è condivisa da ogni browser costruito su di esso. Se stai integrando questo in un framework specifico, vedi [autenticazione SOCKS5 con Playwright](https://quantumproxies.io/blog/playwright-socks5-proxy-authentication) e la nostra [guida alla risoluzione dei problemi 407](https://quantumproxies.io/blog/fix-407-proxy-authentication-required) per gli errori che incontrerai lungo il percorso.

## Domande frequenti

### Cos'è un relay di autenticazione per proxy SOCKS5?

Un piccolo processo locale che ascolta senza autenticazione e inoltra ogni connessione a un proxy SOCKS5 a monte utilizzando il tuo username e password. Consente agli strumenti che non possono inviare credenziali SOCKS5 — principalmente browser basati su Chromium — di raggiungere un proxy autenticato puntando a un indirizzo loopback come `127.0.0.1:1080`. gost ne crea uno con un solo comando.

### Come posso convertire un proxy SOCKS5 in un proxy HTTP?

Non puoi convertire il proxy stesso; esegui un intermediario che parla HTTP localmente e SOCKS5 a monte. `gost -L http://:8080 -F socks5://USER:PASS@host:port` espone un proxy HTTP locale che inoltra al gateway SOCKS5 autenticato. Strumenti dedicati come `socks-to-http-proxy` e Privoxy svolgono lo stesso lavoro se li preferisci.

### Perché Chrome non può utilizzare un proxy SOCKS5 autenticato?

Chromium non ha mai implementato l'autenticazione username/password SOCKS5 — è una limitazione di lunga data registrata come bug di Chromium 40829748. SOCKS5 non autenticato funziona tramite `--proxy-server=socks5://host:port`, ma non c'è modo di fornire credenziali. Un relay locale o la whitelist degli IP è la soluzione standard, e un'estensione proxy-auth copre i proxy HTTP.

### È sicuro inviare credenziali SOCKS5 a un relay?

Solo tramite loopback. SOCKS5 non è criptato e trasmette le credenziali in chiaro, quindi un relay deve essere legato a `127.0.0.1` e mai a un'interfaccia pubblica — questo mantiene il collegamento autenticato sulla tua macchina. Il tunnel criptato verso il target è stabilito end-to-end per HTTPS indipendentemente, quindi il relay vede solo byte TLS che non può leggere.

Ricorri a un relay solo quando lo strumento non ti lascia scelta. gost è la risposta in una riga, PySocks quella da zero — ma la soluzione più rapida per la maggior parte delle persone è fare la whitelist di un IP o utilizzare un endpoint HTTP e non eseguire nulla di extra. Meno parti mobili, meno chiamate alle 3 del mattino.

[Ottieni proxy SOCKS5 con whitelist degli IP](https://quantumproxies.io/socks5-proxies)