SOCKS5 Proxy Auth Relay: Construir ou Ignorar Totalmente
O Chrome e muitas ferramentas de automação ainda não conseguem autenticar um proxy SOCKS5. Um pequeno relay local resolve isso mantendo as credenciais — aqui está um minimalista funcional, as ferramentas prontas, e os casos onde você não precisa dele de forma alguma.
Um relay de autenticação de proxy SOCKS5 é um pequeno processo local que responde ao desafio de nome de usuário/senha de um proxy em seu nome, e então entrega à sua ferramenta um endpoint simples, sem autenticação, em 127.0.0.1. Ele existe para cobrir uma lacuna teimosa: o Chromium nunca suportou SOCKS5 autenticado (registrado como bug do Chromium 40829748), e muitas ferramentas de automação aceitam apenas um host:port simples. Um tópico do Reddit que circulou — alguém frustrado o suficiente para construir um pequeno relay porque as ferramentas ainda não conseguiam lidar com SOCKS5 autenticado — é o gênero inteiro em uma frase. Este guia mostra um relay funcional minimalista, as ferramentas prontas, e, igualmente importante, quando você não precisa de um.
O padrão: sem autenticação na frente, autenticado atrás
Todo relay neste espaço faz a mesma coisa. Ele escuta localmente sem autenticação, e para cada conexão ele abre a perna upstream usando suas credenciais reais. Sua ferramenta se conecta a 127.0.0.1 — sem necessidade de senha — e o relay realiza o handshake de autenticação SOCKS5 para o gateway SOCKS5. As credenciais vivem em um só lugar, no loopback, e nunca tocam na configuração da ferramenta. Isso importa por um segundo motivo: SOCKS5 não é criptografado e transmite credenciais em texto claro, então manter a perna autenticada em sua própria máquina, vinculada a 127.0.0.1, é a maneira segura de fazer isso.
O relay de um comando: gost
Raramente você precisa escrever um relay à mão. gost é uma ferramenta de tunelamento de código aberto que implementa toda a especificação SOCKS5, incluindo autenticação de nome de usuário/senha, e transforma todo o trabalho em um único comando. Exponha um ouvinte SOCKS5 sem autenticação localmente e encaminhe para seu upstream autenticado:
# 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 sua ferramenta fala HTTP mas não SOCKS5, o mesmo comando converte protocolos — exponha um proxy HTTP local que encaminha para o gateway SOCKS5 autenticado. Esta é a resposta limpa para a recorrente pergunta "converter SOCKS5 para HTTP proxy", e supera a configuração clássica do Privoxy porque gost lida com a autenticação upstream em um só lugar:
# 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
Um relay minimalista do zero
Se você prefere entender as partes móveis, aqui está a menor versão útil em Python puro. Ele usa PySocks (pip install PySocks) para abrir a perna upstream autenticada e canaliza bytes nos dois sentidos. Este esboço específico tunela um host alvo — suficiente para raspar uma única API através de uma saída SOCKS5 autenticada — o que o mantém curto e correto; um servidor SOCKS5 geral que analisa o handshake do cliente é o que ferramentas como gost já fazem por você:
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())Para um servidor SOCKS5 local completo que qualquer cliente pode apontar, o projeto comunitário socks-relay no GitHub é uma boa referência: ele executa um ouvinte sem autenticação ou com usuário/senha e relays para outro servidor SOCKS5, em algumas centenas de linhas construídas no PySocks. O projeto socks-to-http-proxy (Rust) faz o trabalho de conversão HTTP se você preferir um binário compilado. De qualquer forma, você está executando o mesmo padrão que gost oferece em uma linha.
Quando você NÃO precisa de um relay
Um relay é um salto que você possui, e muitas vezes você pode eliminar todo o problema. Ignore-o quando qualquer uma destas for verdadeira:
- Seu provedor tem um endpoint HTTP. Proxies HTTP autenticam com Basic auth na URL, que quase todas as ferramentas lidam. Aponte para o gateway HTTP e a dor de cabeça da autenticação SOCKS5 desaparece — as compensações são cobertas em SOCKS5 vs HTTP.
- Lista branca de IPs está disponível. Registre seu IP de saída com o provedor e não há credenciais para relays. Todo plano da QuantumProxies suporta lista branca junto com user:pass em seus proxies residenciais — a solução mais simples sempre que seu IP é estável.
- Sua biblioteca já faz autenticação SOCKS5. curl, Python
requests[socks]ehttpx, e a maioria dos clientes HTTP falam SOCKS5 autenticado nativamente. O relay é apenas para ferramentas que não conseguem — principalmente navegadores baseados em 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
O lado negativo honesto
Executar seu próprio relay adiciona um ponto de falha. É outro processo para supervisionar: se ele falhar, todas as solicitações atrás dele falham, e um script simples não oferece reinício, verificação de integridade ou registro a menos que você os adicione. Ele não tem rotação própria — ele encaminha para qualquer upstream único que você configurou, então a rotação de saída ainda tem que vir do gateway. Ele adiciona uma etapa de latência, e mantém credenciais em texto claro na memória, o que é exatamente por isso que deve se vincular a 127.0.0.1 e nunca a uma interface pública. Para um laptop raspando um site, isso é aceitável. Para qualquer coisa que você monitore, prefira uma solução sem novas partes móveis — lista branca ou um endpoint HTTP — em vez de um relay que agora você tem que manter vivo.
O mesmo padrão de relay aparece em todo o ecossistema stealth, porque a lacuna SOCKS5 do Chromium é compartilhada por todos os navegadores construídos sobre ele. Se você está integrando isso em um framework específico, veja autenticação SOCKS5 no Playwright e nosso guia de solução de problemas 407 para os erros que você encontrará pelo caminho.
Perguntas frequentes
O que é um relay de autenticação de proxy SOCKS5?
Um pequeno processo local que escuta sem autenticação e encaminha cada conexão para um proxy SOCKS5 upstream usando seu nome de usuário e senha. Ele permite que ferramentas que não conseguem enviar credenciais SOCKS5 — principalmente navegadores baseados em Chromium — alcancem um proxy autenticado apontando para um endereço de loopback como 127.0.0.1:1080. gost cria um em um único comando.
Como converto um proxy SOCKS5 para um proxy HTTP?
Você não pode converter o próprio proxy; você executa um intermediário que fala HTTP localmente e SOCKS5 upstream. gost -L http://:8080 -F socks5://USER:PASS@host:port expõe um proxy HTTP local que encaminha para o gateway SOCKS5 autenticado. Ferramentas dedicadas como socks-to-http-proxy e Privoxy fazem o mesmo trabalho se você preferir.
Por que o Chrome não pode usar um proxy SOCKS5 autenticado?
O Chromium nunca implementou autenticação de nome de usuário/senha SOCKS5 — é uma limitação de longa data registrada como bug do Chromium 40829748. SOCKS5 não autenticado funciona através de --proxy-server=socks5://host:port, mas não há como fornecer credenciais. Um relay local ou lista branca de IPs é a solução padrão, e uma extensão de autenticação de proxy cobre proxies HTTP.
É seguro enviar credenciais SOCKS5 para um relay?
Apenas sobre loopback. SOCKS5 não é criptografado e transmite credenciais em texto claro, então um relay deve se vincular a 127.0.0.1 e nunca a uma interface pública — isso mantém a perna autenticada em sua própria máquina. O túnel criptografado para o alvo é estabelecido de ponta a ponta para HTTPS independentemente, então o relay só vê bytes TLS que não pode ler.
Recorra a um relay apenas quando a ferramenta não lhe der escolha. gost é a resposta de uma linha, PySocks a do zero — mas a solução mais rápida para a maioria das pessoas é listar um IP ou usar um endpoint HTTP e não executar nada extra. Menos partes móveis, menos chamadas às 3 da manhã.