SOCKS5 Proxy Auth Relay: Construir uno o prescindir de él por completo
Chrome y muchas herramientas de automatización aún no pueden autenticar un proxy SOCKS5. Un pequeño relay local soluciona eso manteniendo las credenciales — aquí tienes uno mínimo funcional, las herramientas listas para usar y los casos en los que no lo necesitas en absoluto.
Un relay de autenticación de proxy SOCKS5 es un pequeño proceso local que responde al desafío de nombre de usuario/contraseña de un proxy en tu nombre, luego entrega a tu herramienta un endpoint simple, sin autenticación en 127.0.0.1. Existe para cubrir una brecha persistente: Chromium nunca ha soportado SOCKS5 autenticado (seguido como el error 40829748 de Chromium), y muchas herramientas de automatización solo aceptan un simple host:port. Un hilo de Reddit que se hizo popular — alguien lo suficientemente frustrado como para construir un pequeño relay porque las herramientas aún no podían manejar SOCKS5 autenticado — es todo el género en una oración. Esta guía muestra un relay mínimo funcional, las herramientas listas para usar y, igual de importante, cuándo no necesitas uno.
El patrón: sin autenticación al frente, autenticado detrás
Cada relay en este espacio hace lo mismo. Escucha localmente sin autenticación, y para cada conexión abre la conexión ascendente usando tus credenciales reales. Tu herramienta se conecta a 127.0.0.1 — sin necesidad de contraseña — y el relay realiza el apretón de manos de autenticación SOCKS5 con el gateway SOCKS5. Las credenciales viven en un solo lugar, en loopback, y nunca tocan la configuración de la herramienta. Eso importa por una segunda razón: SOCKS5 no está encriptado y transmite credenciales en texto claro, por lo que mantener la conexión autenticada en tu propia máquina, vinculada a 127.0.0.1, es la forma segura de hacerlo.
El relay de un solo comando: gost
Rara vez necesitas escribir un relay a mano. gost es una herramienta de túnel de código abierto que implementa toda la especificación SOCKS5, incluida la autenticación de nombre de usuario/contraseña, y convierte todo el trabajo en un solo comando. Expón un oyente SOCKS5 sin autenticación localmente y reenvía a tu conexión ascendente autenticada:
# 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)Si tu herramienta habla HTTP pero no SOCKS5, el mismo comando convierte los protocolos — expón un proxy HTTP local que reenvíe al gateway SOCKS5 autenticado. Esta es la respuesta limpia a la recurrente pregunta "convertir SOCKS5 a HTTP proxy", y supera la configuración clásica de Privoxy porque gost maneja la autenticación ascendente en un solo 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
Un relay mínimo desde cero
Si prefieres entender las partes móviles, aquí tienes la versión más pequeña útil en Python puro. Usa PySocks (pip install PySocks) para abrir la conexión ascendente autenticada y transmite bytes en ambas direcciones. Este boceto en particular tunela un host objetivo — suficiente para extraer una sola API a través de una salida SOCKS5 autenticada — lo que lo mantiene corto y correcto; un servidor SOCKS5 general que analiza el apretón de manos del cliente es lo que herramientas como gost ya hacen por ti:
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 un servidor SOCKS5 local completo al que cualquier cliente pueda apuntar, el proyecto comunitario socks-relay en GitHub es una buena referencia: ejecuta un oyente sin autenticación o con usuario/contraseña y retransmite a otro servidor SOCKS5, en un par de cientos de líneas construidas sobre PySocks. El proyecto socks-to-http-proxy (Rust) hace el trabajo de conversión HTTP si prefieres un binario compilado. De cualquier manera, estás ejecutando el mismo patrón que te da gost en una línea.
Cuándo NO necesitas un relay
Un relay es un salto que posees, y a menudo puedes eliminar todo el problema en su lugar. Prescinde de él cuando cualquiera de estos sea cierto:
- Tu proveedor tiene un endpoint HTTP. Los proxies HTTP se autentican con Basic auth en la URL, que casi todas las herramientas manejan. Apunta al gateway HTTP y el dolor de cabeza de la autenticación SOCKS5 desaparece — los compromisos se cubren en SOCKS5 vs HTTP.
- Está disponible la lista blanca de IP. Registra tu IP de salida con el proveedor y no hay credenciales que retransmitir en absoluto. Cada plan de QuantumProxies admite la lista blanca junto con usuario:contraseña en sus proxies residenciales — la solución más simple siempre que tu IP sea estable.
- Tu biblioteca ya hace autenticación SOCKS5. curl, Python
requests[socks]yhttpx, y la mayoría de los clientes HTTP hablan SOCKS5 autenticado de forma nativa. El relay es solo para herramientas que no pueden — principalmente navegadores basados en 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
El inconveniente honesto
Ejecutar tu propio relay agrega un punto de falla. Es otro proceso que supervisar: si se bloquea, cada solicitud detrás de él falla, y un script simple no te da reinicio, verificación de estado ni registro a menos que los agregues. No tiene rotación propia — reenvía a cualquier conexión ascendente única que hayas configurado, por lo que la rotación de salida aún debe provenir del gateway. Agrega un salto de latencia y mantiene credenciales en texto claro en la memoria, que es exactamente por qué debe vincularse a 127.0.0.1 y nunca a una interfaz pública. Para una laptop extrayendo un sitio, eso está bien. Para cualquier cosa que monitorees, prefiere una solución sin nuevas partes móviles — lista blanca o un endpoint HTTP — sobre un relay que ahora debes mantener vivo.
El mismo patrón de relay aparece en todo el ecosistema de sigilo, porque la brecha de SOCKS5 de Chromium es compartida por cada navegador construido sobre él. Si estás integrando esto en un marco específico, consulta autenticación SOCKS5 de Playwright y nuestra guía de solución de problemas 407 para los errores que encontrarás en el camino.
Preguntas frecuentes
¿Qué es un relay de autenticación de proxy SOCKS5?
Un pequeño proceso local que escucha sin autenticación y reenvía cada conexión a un proxy SOCKS5 ascendente usando tu nombre de usuario y contraseña. Permite que herramientas que no pueden enviar credenciales SOCKS5 — principalmente navegadores basados en Chromium — alcancen un proxy autenticado apuntando a una dirección de loopback como 127.0.0.1:1080. gost crea uno en un solo comando.
¿Cómo convierto un proxy SOCKS5 a un proxy HTTP?
No puedes convertir el proxy en sí; ejecutas un intermediario que habla HTTP localmente y SOCKS5 ascendente. gost -L http://:8080 -F socks5://USER:PASS@host:port expone un proxy HTTP local que reenvía al gateway SOCKS5 autenticado. Herramientas dedicadas como socks-to-http-proxy y Privoxy hacen el mismo trabajo si las prefieres.
¿Por qué Chrome no puede usar un proxy SOCKS5 autenticado?
Chromium nunca ha implementado la autenticación de nombre de usuario/contraseña SOCKS5 — es una limitación de larga data registrada como el error 40829748 de Chromium. SOCKS5 sin autenticación funciona a través de --proxy-server=socks5://host:port, pero no hay forma de proporcionar credenciales. Un relay local o la lista blanca de IP es la solución estándar, y una extensión de autenticación de proxy cubre los proxies HTTP.
¿Es seguro enviar credenciales SOCKS5 a un relay?
Solo sobre loopback. SOCKS5 no está encriptado y transmite credenciales en texto claro, por lo que un relay debe vincularse a 127.0.0.1 y nunca a una interfaz pública — eso mantiene la conexión autenticada en tu propia máquina. El túnel encriptado al objetivo se establece de extremo a extremo para HTTPS independientemente, por lo que el relay solo ve bytes TLS que no puede leer.
Recurre a un relay solo cuando la herramienta no te deje otra opción. gost es la respuesta de una línea, PySocks la desde cero — pero la solución más rápida para la mayoría de las personas es poner en lista blanca una IP o usar un endpoint HTTP y no ejecutar nada extra. Menos partes móviles, menos alertas a las 3 a.m.