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

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

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:

# 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

Diagramma di flusso di un relay di autenticazione SOCKS5 locale: uno strumento si connette a un listener loopback senza autenticazione, che aggiunge credenziali e inoltra a un gateway proxy autenticato — 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:

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

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.
È 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 — 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.

# 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

Checklist che confronta quando un relay di autenticazione SOCKS5 è inutile rispetto a quando è utile, coprendo gli endpoint HTTP, la whitelist degli IP, il supporto nativo delle librerie e la lacuna di SOCKS5 di Chromium — 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 e la nostra guida alla risoluzione dei problemi 407 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