Proxy HTTP y SOCKS5 a nivel de protocolo: CONNECT, ATYP, qué ve el intermediario y cómo elegir

Si alguna vez abriste el panel de un servicio de proxies, viste esta escena: la misma dirección, el mismo usuario y, al lado, dos puertos. Uno etiquetado como HTTP, el otro como SOCKS5. Muchos eligen al azar o por costumbre. Sin embargo, detrás de esas dos líneas hay dos protocolos distintos, con estructuras diferentes a nivel de bytes, que ven tu tráfico de forma distinta y se comportan de manera diferente en los clientes reales. Esta guía desglosa la diferencia hasta el último byte y termina con tablas prácticas de elección.

Introducción: por qué un mismo proxy se ofrece en dos modos y no es marketing

Empecemos con una respuesta honesta a la pregunta del título. Cuando Proxeon te entrega una dirección con dos puertos, detrás de ellos hay la misma máquina, la misma IP de salida y la misma cuenta. La diferencia no está en hacia dónde va el tráfico. La diferencia está en el idioma con el que tu cliente habla con el servidor proxy en el primer tramo del camino: desde tu aplicación hasta el intermediario.

El proxy HTTP habla el idioma de HTTP. Recibe solicitudes HTTP, las lee, entiende qué querés obtener y él mismo va a buscar el recurso. Sabe cachear, agregar encabezados y responder con códigos de estado. Para todo lo que no sea HTTP tiene un único recurso universal: el método CONNECT, que lo convierte en una tubería simple.

SOCKS5 no sabe qué es HTTP. Es un protocolo de nivel de sesión: el cliente dice «conéctame con tal host y tal puerto», el proxy abre una conexión TCP y, a partir de ese momento, simplemente traslada bytes de un lado a otro. Le da igual qué haya adentro: TLS, IMAP, SSH, un protocolo de base de datos o tu propio formato binario.

¿Por qué no dejar un solo modo? Porque tienen compatibilidad distinta. La mitad del software corporativo y de escritorio solo sabe usar proxy HTTP a través de la configuración del sistema. Buena parte de las bibliotecas de red y prácticamente todo el tráfico que no es web se siente más cómodo en SOCKS5. Ofrecer ambos modos sobre una misma IP significa que vos elegís la herramienta según el cliente, y no que adaptás el cliente a la herramienta.

Qué vas a aprender en este artículo:

• cómo se ve una solicitud a un proxy HTTP a nivel de texto y en qué se diferencia de una solicitud normal a un sitio;
• qué ve exactamente el proxy y qué puede modificar en el modo HTTP transparente;
• cómo funciona el método CONNECT y qué queda visible para el intermediario una vez establecido el túnel;
• el handshake byte a byte de SOCKS5, los esquemas de autenticación y los tres tipos de dirección ATYP;
• por qué la elección entre dominio e IP en una solicitud SOCKS5 afecta la geolocalización y la privacidad del DNS;
• comparación por protocolos no HTTP, UDP, sobrecarga, caché y registro;
• una tabla de «tarea, protocolo, por qué» y el análisis de compatibilidad en clientes y bibliotecas populares.

La mecánica del comando UDP ASSOCIATE y la diferencia entre los esquemas socks5 y socks5h en curl y Python no las desarrollamos en detalle aquí: a esos temas están dedicados materiales específicos en el blog de Proxeon, y habrá enlaces donde corresponda.

Fundamentos: dónde vive el proxy en la pila de red

Para que hablar de protocolos tenga sentido, pongámonos de acuerdo en los términos. Son pocos.

Tres participantes y dos conexiones

En cualquier esquema con proxy hay tres partes: el cliente (tu navegador, tu script, tu programa de correo), el servidor proxy (el intermediario) y el servidor destino (origin). Entre ellos hay dos conexiones TCP independientes. La primera: del cliente al proxy. La segunda: del proxy al servidor destino. El servidor destino solo ve la segunda conexión y, por lo tanto, solo la dirección IP del proxy.

Todo lo que discutimos en este artículo se refiere exclusivamente a la primera conexión. Ahí es donde vive la diferencia entre HTTP y SOCKS5. La segunda conexión es igual en ambos casos: un TCP normal desde el proxy hasta el host destino.

Niveles del modelo y por qué importa

Una analogía útil: imaginá una empresa de mensajería. El proxy HTTP en modo transparente se parece a un mensajero que abre tu paquete, lee la dirección y el contenido, si hace falta lo reempaqueta y hasta puede responderte él mismo si tiene una copia en su depósito. SOCKS5 se parece a un mensajero al que le das la dirección y le entregás el paquete sellado. No sabe ni quiere saber qué hay adentro.

Si hablamos en términos del modelo de red, el proxy HTTP trabaja en la capa de aplicación: entiende la semántica de la solicitud. SOCKS5 trabaja en la capa de sesión: opera con los conceptos de «host», «puerto» y «conexión», y no sube más arriba.

Dónde se resuelven los nombres

Un concepto aparte que atraviesa todo el material: la resolución DNS. Cuando accedés a example.com, alguien tiene que convertir el nombre en una dirección IP. Eso puede hacerlo tu cliente localmente, o puede hacerlo el proxy de su lado. De esto depende qué infraestructura DNS usás, qué respuesta regional te da la CDN y si se filtra información sobre los dominios que visitás hacia la red local. Recordá este punto, va a aparecer tanto en la sección de HTTP como en la de SOCKS5.

Autenticación

Tanto el proxy HTTP como SOCKS5 saben verificar usuario y contraseña, pero lo hacen de manera distinta. HTTP usa el encabezado Proxy-Authorization y el código de respuesta 407. SOCKS5 usa un subprotocolo aparte con el número de método 0x02. También existe una alternativa que no depende del protocolo: la autorización por dirección IP del cliente, cuando el proxy deja pasar a todos los que llegan desde una dirección previamente permitida. En Proxeon están disponibles ambas variantes, y la elección entre ellas influye en qué tan fácil es conectar clientes que no saben transmitir credenciales.

Proxy HTTP: solicitud con URI absoluto, qué ve el proxy y qué puede modificar

Una solicitud HTTP normal a un sitio se ve así:

GET /catalog/items?page=2 HTTP/1.1
Host: shop.example

Fijate que en la línea de solicitud solo está la ruta. El host se transmite en un encabezado aparte. Ese formato se llama origin-form. Cuando el cliente sabe que no está hablando con el sitio sino con un proxy, cambia el formato a absolute-form: en la línea de solicitud se coloca el URI completo.

GET http://shop.example/catalog/items?page=2 HTTP/1.1
Host: shop.example
Proxy-Authorization: Basic dXNlcjpwYXNz
User-Agent: my-parser/1.0
Accept: text/html

¿Para qué duplicar el host? Históricamente, la forma absoluta apareció antes que el encabezado Host y era la única manera de decirle al proxy a dónde ir. El estándar moderno HTTP/1.1 exige que el proxy sepa aceptar la forma absoluta y que los clientes que se dirigen a un proxy usen precisamente esa. El encabezado Host se conserva por compatibilidad y para el servidor destino, al que el proxy le reenviará la solicitud ya en origin-form.

Qué ve el proxy HTTP

En modo transparente (sin cifrado entre el cliente y el sitio destino), el proxy ve absolutamente todo lo que hay en la solicitud y en la respuesta:

• el método, la URL completa, incluidos los parámetros de query;
• todos los encabezados de la solicitud: User-Agent, Cookie, Authorization, Referer;
• el cuerpo completo de la solicitud: formularios, JSON, archivos que se suben;
• el estado de la respuesta, los encabezados de respuesta y el cuerpo de la respuesta.

Esto no es un efecto secundario. Es una característica fundamental de la arquitectura: para reenviar la solicitud, el proxy está obligado a parsearla. Y como la parseó, puede hacer con ella lo que quiera.

Qué puede modificar el proxy HTTP

El estándar divide los encabezados en de extremo a extremo (end-to-end) y salto a salto (hop-by-hop). Los encabezados salto a salto se refieren a una conexión concreta y el proxy está obligado a eliminarlos antes de reenviar. Entre ellos están Connection, Keep-Alive, Proxy-Authorization, Proxy-Authenticate, TE, Trailer, Transfer-Encoding, Upgrade. Por eso tu usuario y contraseña del proxy no vuelan al sitio destino: el encabezado Proxy-Authorization, por estándar, se retira en el proxy.

Además de la limpieza obligatoria, el proxy puede:

• agregar el encabezado Via con su nombre y la versión del protocolo; el estándar lo exige, pero en la práctica los proxies anónimos lo omiten;
• agregar X-Forwarded-For con la IP real del cliente; así lo hacen los proxies corporativos, y así nunca debería hacerlo un proxy que comprás para trabajar con recursos externos;
• entregar una respuesta desde su caché sin consultar al servidor destino, si la respuesta está marcada como cacheable;
• modificar la codificación del cuerpo, agregar o quitar compresión, reescribir enlaces en el HTML;
• rechazar la solicitud con su propia respuesta, por ejemplo 403 o 407.

La respuesta 407 Proxy Authentication Required merece una mención aparte. Si el proxy exige autenticación y el cliente no la envió, el proxy responde con el código 407 y el encabezado Proxy-Authenticate, donde enumera los esquemas que admite. Los buenos clientes, después de eso, repiten la solicitud con Proxy-Authorization. Los malos clientes le muestran al usuario un error incomprensible. De ahí el problema típico de configuración: la aplicación «no ve el proxy», cuando en realidad simplemente no sabe procesar el 407.

Veámoslo en la práctica

La manera más simple de ver todo esto con tus propios ojos: curl con la opción -v.

curl -v -x http://user:pass@gate.proxeon.net:8080 http://httpbin.org/get

En la salida vas a ver una línea como GET http://httpbin.org/get HTTP/1.1 y el encabezado Proxy-Authorization. Eso es la forma absoluta.

La misma solicitud a mano por socket en Python, para que no quede magia:

import socket, base64

creds = base64.b64encode(b"user:pass").decode()
req = (
"GET http://httpbin.org/get HTTP/1.1\r\n"
"Host: httpbin.org\r\n"
f"Proxy-Authorization: Basic {creds}\r\n"
"Connection: close\r\n\r\n"
)
s = socket.create_connection(("gate.proxeon.net", 8080))
s.sendall(req.encode())
print(s.recv(65535).decode(errors="replace"))

Aquí no hay ninguna biblioteca para proxies. Solo un socket y una cadena correctamente armada. El proxy HTTP en modo transparente es tan simple que se puede escribir en una tarde, y ahí está a la vez su fortaleza y su debilidad.

Dónde se resuelve el nombre en modo HTTP

En la forma absoluta, el cliente le pasa al proxy el nombre del host tal cual. La resolución la hace el proxy. El cliente no necesita saber la dirección IP del servidor destino y no se realiza ninguna consulta DNS local. Es cómodo, pero nos lleva a la limitación principal: el esquema descrito funciona solo para HTTP sin cifrar. Para HTTPS, la forma absoluta es inútil, porque la conexión TLS debe establecerse entre el cliente y el servidor destino, y el proxy no puede ponerse en el medio sin romper el certificado. Para eso se inventó CONNECT.

Método CONNECT: convertir un proxy HTTP en túnel TCP

CONNECT es un método HTTP que le pide al proxy que no reenvíe la solicitud, sino que establezca una conexión TCP con el host y puerto indicados y, a partir de ahí, se convierta en una tubería transparente. La solicitud se ve así:

CONNECT shop.example:443 HTTP/1.1
Host: shop.example:443
Proxy-Authorization: Basic dXNlcjpwYXNz
Proxy-Connection: Keep-Alive

Fijate en el formato del destino: solo host y puerto, sin esquema ni ruta. Es la authority-form de la solicitud, el tercero de los formatos después de origin-form y absolute-form.

Si el proxy acepta, responde:

HTTP/1.1 200 Connection established

El texto después del código puede ser cualquiera; los clientes se guían solo por el 2xx. A partir de este momento, HTTP se termina. Todo lo que el cliente escribe en el socket, el proxy lo reenvía byte a byte al servidor destino, y viceversa. El cliente comienza el handshake TLS directamente en ese socket, como si estuviera conectado al servidor de forma directa.

Qué ve el intermediario después del CONNECT

Aquí empieza lo más interesante. El proxy, que hace un momento lo veía todo, de golpe queda ciego. Después de un CONNECT exitoso, el proxy sabe:

• el nombre del host y el puerto de la línea CONNECT; esta es la única información semántica que obtuvo;
• la hora de establecimiento y de cierre de la conexión;
• el volumen de bytes transmitidos en ambos sentidos;
• el contenido del TLS ClientHello, si dentro del túnel hay TLS: ahí se transmite en claro el SNI (nombre del servidor), la lista de cifrados admitidos y las extensiones; la extensión moderna Encrypted Client Hello también oculta el SNI, pero su soporte todavía no es universal;
• nada del nivel HTTP: ni URL, ni encabezados, ni cookies, ni cuerpo.

En otras palabras, después del CONNECT el proxy HTTP ve exactamente lo mismo que SOCKS5. Host, puerto, tiempos, volúmenes. La diferencia de visibilidad entre ambos protocolos existe solo para el tráfico HTTP sin cifrar, y de eso queda muy poco en tareas reales en 2026.

CONNECT no tiene por qué llevar a HTTPS

Un error de razonamiento frecuente: CONNECT solo se necesita para HTTPS. En realidad, el estándar no limita el contenido del túnel. A través de CONNECT se puede establecer conexión con un servidor IMAP en el puerto 993, con SSH en el puerto 22, con cualquier servicio TCP. La única pregunta es si la configuración del proxy lo permite. Muchos proxies HTTP públicos y corporativos permiten CONNECT solo hacia los puertos 443 y, a veces, 80, para prevenir abusos. Proxeon permite CONNECT hacia puertos arbitrarios, pero si tu software sabe usar SOCKS5, para protocolos que no son HTTP sigue siendo la opción más natural, como veremos más abajo.

Ejemplo: TLS a través de CONNECT a mano

La utilidad openssl puede atravesar un proxy HTTP por sí sola:

openssl s_client -proxy gate.proxeon.net:8080 -connect shop.example:443 -servername shop.example

Y así se ve en Python con la biblioteca estándar, sin dependencias externas:

import http.client, ssl

conn = http.client.HTTPSConnection("gate.proxeon.net", 8080,
 context=ssl.create_default_context())
conn.set_tunnel("shop.example", 443,
headers={"Proxy-Authorization": "Basic dXNlcjpwYXNz"})
conn.request("GET", "/")
resp = conn.getresponse()
print(resp.status, resp.getheader("server"))

El método set_tunnel hace exactamente lo descrito arriba: envía CONNECT, espera el 200 y luego envuelve el socket en TLS. Notá que el contexto TLS verifica el certificado de shop.example, no el del proxy. El proxy, en este esquema, no puede sustituir el certificado sin provocarle un error al cliente.

CONNECT en HTTP/2 y HTTP/3

En HTTP/2 el método CONNECT se conserva, pero funciona dentro de una única conexión multiplexada: cada túnel es un stream aparte. Esto permite mantener decenas de túneles por una sola conexión TCP con el proxy y ahorrar en handshakes. El CONNECT extendido (con el pseudo-encabezado :protocol) se usa para WebSocket sobre HTTP/2. En HTTP/3, basado en QUIC, apareció la especificación CONNECT-UDP, que formalmente permite tunelizar UDP a través de un proxy HTTP. Sin embargo, en las bibliotecas de cliente esto todavía es exótico y, en la práctica, si necesitás UDP a través de un proxy, vas a mirar hacia SOCKS5.

Qué no sabe hacer CONNECT

• Cachear: el contenido del túnel es opaco.
• Modificar encabezados: simplemente no se ven.
• Multiplexar varios hosts destino por un solo túnel en HTTP/1.1: un CONNECT equivale a una conexión TCP.
• Transmitir UDP en HTTP/1.1 y HTTP/2.

SOCKS5: handshake, autenticación y ATYP

SOCKS5 está descrito en el RFC 1928, y su esquema de autenticación por usuario y contraseña en el RFC 1929. Ambas especificaciones caben en unas pocas páginas, y esa es una de las ventajas del protocolo: implementarlo desde cero no es difícil, así que hay muchas implementaciones y rara vez discrepan en la interpretación.

SOCKS5 es un protocolo binario. Nada de texto, solo bytes de estructura fija. Veamos el intercambio completo para el comando CONNECT.

Paso 1: saludo y elección del método de autenticación

El cliente envía la versión y la lista de métodos de autenticación que admite:

05 02 00 02
VER=5 NMETHODS=2 METHODS: 00 (sin autenticación), 02 (usuario/contraseña)

El servidor elige un método y responde con dos bytes:

05 02
VER=5 METHOD=02 (el servidor exige usuario/contraseña)

Si el servidor responde 05 FF, eso significa «ninguno de los métodos propuestos sirve» y el cliente debe cerrar la conexión. Así se ve, a nivel de bytes, la situación en la que olvidaste poner la contraseña y el proxy de Proxeon está configurado con autorización por usuario.

Paso 2: autenticación según RFC 1929

Si se elige el método 02, el cliente envía:

01 04 75 73 65 72 04 70 61 73 73
VER=1 ULEN=4 UNAME="user" PLEN=4 PASSWD="pass"

Ojo: la versión del subprotocolo aquí es 01, no 05. Esta es una fuente frecuente de errores en clientes caseros. El servidor responde:

01 00
VER=1 STATUS=00 (éxito; cualquier otro valor significa rechazo)

El usuario y la contraseña se transmiten en texto plano. Si entre vos y el proxy hay una red no confiable, vale la pena recordarlo. En la práctica, la conexión con el proxy suele ir por un canal propio del proveedor, y el tema se resuelve a nivel de transporte o cambiando a autorización por IP.

Paso 3: solicitud de conexión

Ahora sí, el mensaje más importante:

05 01 00 03 0C 73 68 6F 70 2E 65 78 61 6D 70 6C 65 01 BB
VER=5 CMD=01 (CONNECT) RSV=00 ATYP=03 (dominio)
LEN=12 ADDR="shop.example" PORT=0x01BB (443)

El campo CMD admite tres valores: 01 CONNECT (conexión TCP saliente), 02 BIND (esperar una conexión entrante, prácticamente sin uso), 03 UDP ASSOCIATE (crear un retransmisor UDP). La mecánica de UDP ASSOCIATE y sus trampas las analizamos en un artículo aparte sobre UDP en SOCKS5; aquí solo fijamos esto: es el único de los dos protocolos que tiene UDP de forma nativa.

ATYP: dominio frente a IP

El campo ATYP define en qué forma el cliente transmitió la dirección de destino:

• 0x01 IPv4: los siguientes 4 bytes son la dirección;
• 0x03 nombre de dominio: un byte de longitud y luego el nombre sin cero final;
• 0x04 IPv6: los siguientes 16 bytes son la dirección.

Parece un detalle técnico. En realidad, es una de las decisiones más importantes que toma el cliente, y he aquí por qué.

Si el cliente usa ATYP=0x01 o 0x04, significa que él mismo hizo la resolución DNS antes de enviar la solicitud. Tu máquina consultó a su servidor DNS, obtuvo la dirección y le pasó al proxy una IP ya lista. Consecuencias:

• la consulta DNS salió por tu red local y es visible para tu proveedor o administrador;
• obtuviste la IP que el DNS devolvió para tu región; para sitios detrás de una CDN, eso significa que el proxy, ubicado en otro país, se conectará a un edge-server «ajeno», lo que ralentiza la conexión y puede verse anómalo;
• si tu máquina no tiene IPv6, nunca recibirás el registro AAAA y no aprovecharás la ruta IPv6 del proxy, aunque exista;
• si el DNS de tu red se comporta de manera no estándar, el proxy recibirá una dirección incorrecta y vas a tardar en encontrar la causa.

Si el cliente usa ATYP=0x03, la resolución la hace el proxy. Usa su infraestructura DNS, obtiene una dirección relevante para su ubicación y tu red local no ve a qué dominios accedés. Para tareas con geovinculación esto es crítico: el sentido del proxy en un país determinado se pierde en parte si el servidor destino se elige según el DNS de tu red doméstica.

¿Cómo hacer que el cliente transmita el dominio? Depende del cliente. En curl y en las bibliotecas de Python, de eso se encarga la elección del esquema socks5 frente a socks5h, y ese es el tema de un análisis aparte. Aquí importa entender la causa: la letra h significa «hostname» y activa ATYP=0x03. Sin ella, la biblioteca resuelve el nombre localmente.

Paso 4: respuesta del servidor

05 00 00 01 C0 A8 01 0A 1F 90
VER=5 REP=00 (éxito) RSV=00 ATYP=01 BND.ADDR=192.168.1.10 BND.PORT=8080

El campo REP contiene el código de resultado. Es útil saberlos de memoria al depurar:

• 00 éxito;
• 01 error general del servidor;
• 02 conexión prohibida por las reglas;
• 03 red inalcanzable;
• 04 host inalcanzable;
• 05 conexión rechazada por el servidor destino;
• 06 TTL expirado;
• 07 comando no soportado;
• 08 tipo de dirección no soportado.

El código 08 aparece en implementaciones antiguas o simplificadas que no soportan ATYP=0x03 o IPv6. Proxeon soporta los tres tipos de dirección.

Por qué SOCKS5 no analiza el contenido

Después de la respuesta REP=00, el protocolo SOCKS5 terminó. Todo lo que el cliente escriba a partir de ahí, el proxy lo vuelca en la conexión destino sin analizarlo. Esto no es una limitación de implementación, sino una propiedad del diseño. SOCKS5 no tiene noción de «solicitud» ni de «encabezado». No sabe qué es HTTP, IMAP o TLS. Le pasaron una dirección y un puerto, y él conectó dos tuberías.

De esto se derivan varias consecuencias prácticas:

• SOCKS5 no puede cachear: no entiende dónde termina una respuesta y empieza otra;
• SOCKS5 no puede agregar encabezados ni sustituir contenido; lo máximo que puede hacer es cerrar la conexión;
• SOCKS5 no puede filtrar por URL, solo por host y puerto;
• SOCKS5 funciona igual de bien con cualquier protocolo TCP, incluido el que inventaste ayer.

Handshake SOCKS5 completo en Python

import socket, struct

def socks5_connect(proxy, user, pwd, host, port):
s = socket.create_connection(proxy)
s.sendall(b"\x05\x02\x00\x02")
ver, method = s.recv(2)
if method == 0x02:
u, p = user.encode(), pwd.encode()
s.sendall(b"\x01" + bytes([len(u)]) + u + bytes([len(p)]) + p)
if s.recv(2)[1] != 0:
raise RuntimeError("auth failed")
elif method != 0x00:
raise RuntimeError("no acceptable auth method")
h = host.encode()
s.sendall(b"\x05\x01\x00\x03" + bytes([len(h)]) + h + struct.pack("!H", port))
reply = s.recv(4)
if reply[1] != 0:
raise RuntimeError(f"connect failed, REP={reply[1]}")
atyp = reply[3]
s.recv({1: 4, 4: 16}.get(atyp, 0) if atyp != 3 else s.recv(1)[0])
s.recv(2)
return s

sock = socks5_connect(("gate.proxeon.net", 1080), "user", "pass", "shop.example", 443)
# дальше sock можно обернуть в ssl.wrap_socket или передать любому протоколу

Treinta líneas y tenés un cliente SOCKS5 funcionando, que transmite el dominio (ATYP=0x03) y deja la resolución al servidor proxy. Esa simpleza es la que convierte a SOCKS5 en el estándar de facto para el acceso programable.

Comparación por criterios: dónde gana cada uno

Ahora que la mecánica de ambos protocolos está desglosada hasta los bytes, la comparación deja de ser una discusión de gustos y se convierte en una lista de diferencias medibles.

Protocolos que no son HTTP

SOCKS5 funciona con cualquier protocolo TCP de forma nativa: comando CONNECT, host, puerto, listo. El proxy HTTP también puede, vía CONNECT, pero con matices: el cliente debe saber enviar CONNECT para tráfico no HTTP (los clientes de correo saben, la mayoría de las herramientas CLI no), y el proxy debe permitir el puerto necesario. Ganador: SOCKS5.

UDP

SOCKS5 tiene UDP ASSOCIATE. El proxy HTTP en versiones 1.1 y 2 no tiene nada, y el CONNECT-UDP de HTTP/3 prácticamente no está soportado por los clientes. Si tu tarea incluye consultas DNS directas, QUIC, protocolos de voz o tráfico de juegos, no hay elección. Ganador: SOCKS5, con la salvedad de que no todo servidor SOCKS5 habilita UDP, consultá la documentación del plan.

Sobrecarga al establecer la conexión

Contemos en round-trips (RTT) entre el cliente y el proxy, sobre el propio handshake TCP:

• proxy HTTP, modo transparente, sin autenticación: 0 RTT adicionales, la solicitud sale de inmediato;
• HTTP CONNECT con autenticación en la primera solicitud: 1 RTT (CONNECT, respuesta 200);
• SOCKS5 sin autenticación: 2 RTT (saludo, solicitud);
• SOCKS5 con usuario y contraseña: 3 RTT (saludo, autenticación, solicitud).

En bytes la diferencia es la inversa: el handshake completo de SOCKS5 con autenticación cabe en aproximadamente 40 bytes, y un CONNECT con encabezados Host, Proxy-Authorization y User-Agent fácilmente ocupa 150 o más. Pero en tareas reales lo que decide es el RTT, no los bytes. Con una latencia al proxy de 50 ms, SOCKS5 con autenticación agrega 150 ms a cada conexión nueva contra 50 ms de CONNECT. Si el cliente reutiliza conexiones (keep-alive, pools), es un pago único. Si cada solicitud abre un socket nuevo, la diferencia se acumula. Ganador por RTT: HTTP. Cómo acortar la brecha para SOCKS5: autorización por IP, que elimina un RTT.

Cacheo

Solo el proxy HTTP en modo transparente. Ni CONNECT ni SOCKS5. Y aun así, solo puede cachear tráfico sin cifrar, del que hoy queda poco, por lo que este criterio dejó de ser decisivo y se volvió de nicho. Es relevante para sistemas de compilación internos, espejos de paquetes y solicitudes repetidas a API sin TLS dentro de un perímetro confiable. Ganador: HTTP, pero con un ámbito de aplicación estrecho.

Registro

Este punto suele entenderse mal. ¿Qué puede registrar el proxy en cada modo?

• HTTP transparente: URL completa, método, encabezados y, si se quiere, cuerpo; estado de respuesta; volúmenes.
• HTTP CONNECT: host y puerto de la línea CONNECT; hora; volúmenes; si se quiere, el SNI del ClientHello.
• SOCKS5 con ATYP=0x03: nombre de dominio y puerto; hora; volúmenes; si se quiere, el SNI.
• SOCKS5 con ATYP=0x01/0x04: solo IP y puerto; el proxy no conoce el dominio; hora; volúmenes; SNI.

Para tráfico cifrado, CONNECT y SOCKS5 le dan al intermediario la misma visibilidad. La diferencia aparece solo donde el cliente SOCKS5 transmite IP en lugar de dominio, y entonces el proxy sabe incluso menos. Pero el servidor destino, en ese caso, recibe la solicitud desde la «región equivocada», ver la sección sobre ATYP. Empate con matices.

Diagnóstico de errores

El proxy HTTP responde con códigos legibles: 407 habla de autenticación, 403 de prohibición, 502 de destino inaccesible, 504 de timeout. Algunas implementaciones agregan un cuerpo con explicación. SOCKS5 responde con un solo byte REP, y no toda biblioteca lo traduce a un mensaje comprensible. Al depurar en un entorno desconocido, el proxy HTTP es más fácil de diagnosticar. Ganador: HTTP.

Multiplexación

El proxy HTTP/2 permite conducir muchos túneles CONNECT por una sola conexión. SOCKS5 exige una conexión TCP separada por cada destino. Para clientes con cientos de conexiones en paralelo, esto reduce notablemente la carga sobre la pila de red y el proxy. Pero el soporte de HTTP/2 hacia el proxy en los clientes todavía es fragmentario. Ganador potencial: HTTP, empate real.

Posibilidad de intervenir en el tráfico

El proxy HTTP en modo transparente puede modificarlo todo. En modo CONNECT y en SOCKS5 solo puede cortar la conexión. Para un cliente que quiere garantías de que el tráfico no se modifica, lo mejor es SOCKS5 o CONNECT con TLS adentro. Ganador por previsibilidad: SOCKS5.

Autenticación

Ambos admiten usuario y contraseña. HTTP además soporta esquemas Digest, NTLM y Negotiate, lo cual importa en entornos corporativos. SOCKS5 formalmente tiene el método GSSAPI, pero en proxies comerciales prácticamente no aparece. Para trabajar con un servicio como Proxeon esto no tiene relevancia: ahí se usa Basic o lista blanca de IP.

Qué elegir según la tarea: tabla

Juntemos las conclusiones en una herramienta de trabajo. La tabla parte de que ambos modos están disponibles sobre una misma IP, como está armado en Proxeon, y la única pregunta es qué puerto indicar.

Algoritmo de elección en cuatro pasos

1. Determiná el protocolo interno. Si no es HTTP ni HTTPS, tomá SOCKS5 y no lo dudes.
2. Verificá qué sabe hacer el cliente. Abrí su documentación y buscá socks5, proxy, CONNECT. Si no hay SOCKS5 o está sin autenticación, la elección ya está hecha por vos.
3. Decidí dónde debe resolverse el dominio. Si la región importa (CDN, contenido geodependiente, monitoreo), tomá SOCKS5 con transmisión de dominio o HTTP CONNECT: en ambos casos resuelve el proxy.
4. Evaluá el perfil de conexiones. Muchas conexiones cortas sin pool: mirá el RTT del handshake, elegí HTTP CONNECT o activá la autorización por IP.

Compatibilidad en clientes y bibliotecas populares

La teoría termina donde empiezan los clientes reales. Abajo, un análisis del comportamiento de las herramientas más comunes al estado de 2026. Verificá las versiones actuales: el comportamiento cambia de release a release.

curl

Soporta todo. Esquemas en el parámetro -x o en variables de entorno: http://, https:// (TLS hasta el propio proxy), socks4://, socks4a://, socks5://, socks5h://. La diferencia entre socks5 y socks5h está descrita en un artículo aparte; aquí recordá: para resolución en el proxy se necesita socks5h.

curl -x socks5h://user:pass@gate.proxeon.net:1080 https://shop.example/
curl -x http://user:pass@gate.proxeon.net:8080 https://shop.example/

Las variables de entorno http_proxy, https_proxy y all_proxy se leen automáticamente; all_proxy también acepta esquemas SOCKS.

wget

Solo proxy HTTP. SOCKS no está soportado de ninguna forma. Si necesitás wget a través de SOCKS5, vas a necesitar un proxyficador del sistema.

Python: requests

Proxy HTTP de fábrica. Para SOCKS5 se necesita el paquete adicional PySocks (se instala como requests[socks]).

import requests

proxies = {
"http": "socks5h://user:pass@gate.proxeon.net:1080",
"https": "socks5h://user:pass@gate.proxeon.net:1080",
}
r = requests.get("https://shop.example/api/items", proxies=proxies, timeout=15)
print(r.status_code, r.headers.get("cf-ray"))

Para HTTPS a través de un proxy HTTP, requests usa CONNECT automáticamente. Para HTTP a través de un proxy HTTP, se usa la forma absoluta.

Python: httpx

Proxy HTTP de fábrica, SOCKS5 a través del paquete socksio (httpx[socks]). El esquema socks5:// en httpx transmite el dominio al servidor proxy. Soporta async, lo que lo hace cómodo para tareas en paralelo.

import httpx, asyncio

async def main():
async with httpx.AsyncClient(proxy="socks5://user:pass@gate.proxeon.net:1080") as c:
r = await c.get("https://shop.example/")
print(r.status_code)

asyncio.run(main())

Python: aiohttp

Proxy HTTP de forma nativa. SOCKS5 a través del paquete aiohttp-socks con la clase ProxyConnector, cuyo parámetro rdns controla dónde se resuelve.

Node.js: fetch y undici

El fetch integrado de Node.js usa undici, donde existe ProxyAgent para proxy HTTP. Para SOCKS5 se aplica un agente aparte del ecosistema, por ejemplo socks-proxy-agent para los módulos http/https.

import { ProxyAgent, fetch } from "undici";

const agent = new ProxyAgent({
 uri: "http://gate.proxeon.net:8080",
 token: "Basic " + Buffer.from("user:pass").toString("base64"),
});
const res = await fetch("https://shop.example/", { dispatcher: agent });
console.log(res.status);

Go

El net/http estándar soporta proxy HTTP a través de Transport.Proxy y de variables de entorno. Desde Go 1.13, el esquema socks5:// en HTTP_PROXY también es aceptado por la biblioteca estándar. Para control fino se usa el paquete golang.org/x/net/proxy.

package main

import (
"fmt"
"net/http"
"net/url"
)

func main() {
u, _ := url.Parse("socks5://user:pass@gate.proxeon.net:1080")
tr := &http.Transport{Proxy: http.ProxyURL(u)}
client := &http.Client{Transport: tr}
resp, err := client.Get("https://shop.example/")
if err != nil {
panic(err)
}
fmt.Println(resp.Status)
}

En Go, el esquema socks5 transmite el dominio al proxy: no se realiza resolución local.

Java

Proxy HTTP a través de las propiedades del sistema http.proxyHost, https.proxyHost o del objeto Proxy con tipo Type.HTTP. SOCKS a través de socksProxyHost y Proxy.Type.SOCKS. La autenticación se hace a través de la clase Authenticator. Desde JDK 8u111, el esquema Basic para HTTPS a través de CONNECT está desactivado por defecto mediante la propiedad jdk.http.auth.tunneling.disabledSchemes; hay que limpiarla, de lo contrario vas a recibir un 407 sin explicación. Esta es una de las causas más frecuentes de consultas al soporte.

.NET

HttpClient con SocketsHttpHandler soporta proxy HTTP a través de WebProxy. El soporte de SOCKS4, SOCKS4a y SOCKS5 apareció en .NET 6 y se activa con la misma construcción WebProxy con una dirección del tipo socks5://host:port.

Navegadores

Los navegadores basados en Chromium usan la configuración de proxy del sistema o el flag --proxy-server. El proxy HTTP con autenticación funciona: el navegador muestra el diálogo de login. SOCKS5 a través de la configuración del sistema funciona sin autenticación; no se puede pasar usuario y contraseña. Para SOCKS5 con contraseña se necesita una extensión con la API proxy o autorización por IP. Firefox tiene su propia configuración de proxy, soporta SOCKS5 y la opción «Proxy DNS when using SOCKS v5», que activa ATYP=0x03. La autenticación para SOCKS5 en Firefox tampoco está prevista de fábrica.

Clientes de correo

Thunderbird usa una configuración de proxy similar a la de Firefox y sabe usar SOCKS5 para IMAP y SMTP. Muchos otros clientes de correo de escritorio tienen su propia sección de proxy SOCKS5 en la configuración de la cuenta. A través de un proxy HTTP, el correo funciona solo si el cliente sabe enviar CONNECT a los puertos 993 y 465, algo que rara vez ocurre.

Proxyficadores del sistema

Para aplicaciones sin configuración de proxy propia existen programas que interceptan las llamadas de red a nivel del sistema y las redirigen a un proxy SOCKS5 o HTTP. Prácticamente todos prefieren SOCKS5 como transporte, justamente porque no depende del protocolo interno. Si tu tarea incluye una herramienta así, tené listo el puerto SOCKS5.

Checklist de compatibilidad

• ¿El cliente soporta SOCKS5? ¿Sabe transmitir usuario y contraseña en SOCKS5?
• ¿El cliente resuelve el dominio por su cuenta o se lo entrega al proxy? ¿Tiene opción de remote DNS?
• ¿El cliente procesa correctamente el 407 y repite la solicitud con autorización?
• ¿El cliente usa CONNECT para HTTPS o intenta enviar un URI absoluto con esquema https (así lo hacen algunas bibliotecas antiguas, y no funciona)?
• ¿El cliente reutiliza conexiones al proxy o abre una nueva por cada solicitud?

Casos de la práctica ingenieril

Las cifras de abajo son típicas de los escenarios descritos y se dan para entender el orden del efecto, no como resultado garantizado.

Caso 1: monitoreo de vitrinas desde distintas regiones

El equipo seguía la disponibilidad y los precios de sus propias vitrinas regionales a través de proxies de varios países. Usaban Python y requests con el esquema socks5://. De vez en cuando las métricas mostraban el «precio equivocado» para la región, aunque la vitrina funcionaba bien. Causa: la biblioteca resolvía el dominio localmente, en el país de la oficina, y le pasaba al proxy una IP de edge-server de la CDN ya lista. El proxy de otro país se conectaba honestamente a esa dirección, y la CDN entregaba contenido definiendo la región por su propio nodo, no por la IP del cliente. Cambiar el esquema a socks5h trasladó la resolución al proxy. La proporción de mediciones anómalas cayó prácticamente a cero, y el tiempo medio de respuesta bajó alrededor de un tercio gracias a que el proxy empezó a ir al nodo de la CDN más cercano a él.

Caso 2: flota de recolectores de datos con conexiones cortas

Un servicio de agregación de precios abiertos realizaba hasta varios cientos de miles de solicitudes por día a través de SOCKS5 con usuario y contraseña, abriendo una conexión nueva por solicitud. El perfilado mostró que los tres RTT del handshake por conexión, con una latencia al proxy de unos 40 ms, generaban 120 ms de sobrecarga por solicitud, alrededor de un cuarto del tiempo total. Dos cambios: activaron el pool de conexiones en el cliente HTTP y pasaron a autorización por IP, eliminando un RTT. El tiempo total de recorrido de la lista se redujo aproximadamente un 30 por ciento sin cambiar la cantidad de proxies. El protocolo quedó en SOCKS5, porque cambiar a HTTP CONNECT habría dado menos ganancia que el pool.

Caso 3: buzones de correo e IMAP

El equipo de soporte desplegaba un cliente de correo de escritorio para varias representaciones regionales, donde cada buzón debía conectarse al servidor de correo a través de la IP de una región determinada. El primer intento con proxy HTTP falló: el cliente no sabía usar CONNECT para IMAP. Cambiar al puerto SOCKS5 de Proxeon resolvió la tarea en minutos, porque el cliente tenía configuración nativa de SOCKS5 para cada cuenta. Sin software adicional.

Caso 4: aplicación Java y el misterioso 407

Un integrador corporativo conectaba un servicio Java a una API externa a través de un proxy HTTP con autenticación Basic. El proxy devolvía 407 de forma estable, aunque las credenciales eran correctas y curl con los mismos parámetros funcionaba. Causa: a partir de cierta actualización del JDK, la autenticación Basic para túneles CONNECT está desactivada por defecto. Un flag de la JVM limpiando jdk.http.auth.tunneling.disabledSchemes resolvió el problema. Aquí fue útil justamente que el proxy HTTP responde con un código legible: el 407 indicó de inmediato hacia dónde buscar, mientras que SOCKS5 en una situación análoga habría devuelto 05 FF y, sin conocer el protocolo, habría sido más difícil de interpretar.

Equívocos frecuentes

• «SOCKS5 es más seguro que un proxy HTTP». Para tráfico cifrado, ambos protocolos le dan al intermediario la misma visibilidad: host, puerto, tiempos, volúmenes, SNI. La seguridad del contenido la da TLS, no el protocolo del proxy. La diferencia existe solo para HTTP sin cifrar, donde el proxy HTTP transparente lo ve todo.
• «El proxy HTTP no funciona con HTTPS». Funciona vía CONNECT. Es el mecanismo estándar y universal, así es como todos los navegadores acceden a sitios HTTPS a través de proxies corporativos.
• «SOCKS5 es más rápido porque es binario». Al establecer la conexión, SOCKS5 con autenticación gasta más RTT que HTTP CONNECT. En la transmisión de datos ninguno agrega nada: después del handshake, en ambos casos es una tubería TCP limpia. La velocidad la define el canal del proxy, no el protocolo.
• «CONNECT solo sirve para el puerto 443». El estándar no limita el puerto. Los límites los pone la configuración de cada proxy.
• «SOCKS5 siempre resuelve el dominio en el proxy». Solo si el cliente transmite ATYP=0x03. Muchas bibliotecas, por defecto, resuelven localmente y transmiten IP.
• «El proxy HTTP siempre agrega X-Forwarded-For y revela mi IP». Eso es comportamiento de configuraciones corporativas concretas, no una propiedad del protocolo. Los proxies comerciales no agregan esos encabezados, y en modo CONNECT es físicamente imposible agregarlos.
• «El proxy ve mi contraseña del proxy en claro, así que también la del sitio». La contraseña del proxy se transmite al proxy y, por estándar, no se reenvía más allá. La contraseña del sitio, dentro del túnel TLS, el proxy no la ve.
• «Como SOCKS5 no analiza el contenido, no se puede limitar». El proxy puede limitar por host destino, puerto, volumen, velocidad y cantidad de conexiones. Simplemente no por URL.
• «Los puertos HTTP y SOCKS5 de un mismo proveedor son servidores distintos». Por regla general, es el mismo servidor y la misma IP de salida, solo cambia el protocolo de entrada. En Proxeon es así.
• «En el navegador, SOCKS5 con contraseña se configura igual que HTTP». No. La configuración del sistema en Chromium y Firefox no transmite credenciales en SOCKS5. Se necesita autorización por IP o una extensión.

FAQ

¿El sitio destino puede determinar si llegué por proxy HTTP o por SOCKS5?

No. El servidor destino ve solo la segunda conexión, del proxy hacia él, y en ambos casos se trata de un TCP normal desde la IP del proxy. La única excepción: el proxy HTTP transparente, que agrega encabezados Via o X-Forwarded-For. En modo CONNECT y en SOCKS5 eso es imposible.

Si uso un proxy HTTP para HTTPS, ¿el proxy puede espiar o sustituir el contenido?

Solo si realiza una interceptación TLS con sustitución de certificado, y entonces tu cliente verá un error de verificación de certificado, a menos que hayas instalado manualmente el certificado raíz de confianza de ese proxy. En el funcionamiento normal, después del CONNECT el proxy ve un flujo cifrado y no puede ni leer ni modificar su contenido.

¿Por qué SOCKS5 con contraseña no funciona en Chrome, pero el proxy HTTP con contraseña sí?

La implementación de la pila de red de Chromium soporta el diálogo de autenticación para proxy HTTP a través del mecanismo 407, pero no implementa el método 0x02 del RFC 1929 para SOCKS5. Es una decisión de los desarrolladores del navegador, no una limitación del protocolo. Solución: autorización por dirección IP en el panel de Proxeon o una extensión que gestione el proxy a través de la API.

¿Qué hacer si el proxy devuelve REP=05 en SOCKS5?

El código 05 significa que el servidor destino rechazó la conexión TCP: puerto cerrado, servicio no iniciado o el firewall del destino bloquea la IP del proxy. Verificá que hayas pasado el puerto correcto y probá otra dirección de proxy. El proxy en sí funciona bien, el problema está en la segunda mitad del camino.

¿Cuál es la diferencia entre REP=02 en SOCKS5 y 403 en un proxy HTTP?

Semánticamente son lo mismo: el proxy se negó a establecer la conexión según sus reglas. Normalmente significa que el puerto o el host destino están prohibidos por la política del proxy. En el proxy HTTP, el cuerpo de la respuesta 403 a veces trae una explicación; en SOCKS5, solo el byte.

¿Puedo usar el mismo usuario y contraseña para el puerto HTTP y el SOCKS5?

En Proxeon sí: la cuenta es común, solo cambian el puerto y el protocolo. Al cambiar de protocolo no hace falta cambiar las credenciales.

¿Cómo saber si mi cliente resuelve el dominio localmente o en el proxy?

La forma más confiable: hacer una captura de tráfico en tu interfaz y ver si sale una consulta DNS hacia el dominio destino antes de conectarse al proxy. Más simple: poner temporalmente en el archivo hosts una dirección deliberadamente incorrecta para el dominio destino. Si la solicitud a través del proxy sigue funcionando, resuelve el proxy. Si se rompe, resuelve el cliente.

¿Conviene usar HTTP/2 hacia el proxy si la biblioteca lo soporta?

Si tenés muchas conexiones en paralelo hacia destinos distintos y el cliente realmente multiplexa streams CONNECT, la ganancia se va a notar: menos conexiones TCP, menos handshakes. Pero el soporte de esta capacidad en clientes y servidores proxy todavía es desparejo. Revisá la documentación de tu cliente y averiguá si tu plan soporta HTTP/2 en la entrada.

¿Por qué en el proxy HTTP hay URI absoluto si existe el encabezado Host?

El estándar HTTP/1.1 exige que el cliente use la forma absoluta al dirigirse a un proxy, para que el proxy entienda sin ambigüedad que la solicitud debe reenviarse y no procesarse localmente. El encabezado Host se conserva porque el proxy reenviará la solicitud al servidor destino ya en origin-form, y ahí Host es obligatorio. La duplicación es el precio de la compatibilidad.

¿Qué es más importante para el scraping: HTTP o SOCKS5?

Para destinos HTTPS no hay diferencia de visibilidad; la diferencia está en el comportamiento de la biblioteca. Si la biblioteca funciona bien con SOCKS5 y transmite el dominio, tomá SOCKS5: no corre el riesgo de intervenir en los encabezados y da la resolución regional correcta. Si la biblioteca con SOCKS5 da problemas o tenés muchas conexiones cortas sin pool, HTTP CONNECT no es peor. El consejo principal: no abras una conexión nueva con el proxy por cada solicitud, eso cuesta más que cualquier elección de protocolo.

Conclusión

Dos puertos en el panel no son una pareja de marketing «el común y el avanzado». Son dos idiomas distintos para hablar con la misma máquina. El proxy HTTP habla el idioma de solicitudes y respuestas, entiende la semántica, puede cachear y explica los errores con códigos legibles, y para todo lo que no entiende tiene CONNECT, que lo convierte en túnel TCP. SOCKS5 habla el idioma de «host y puerto», no analiza el contenido, soporta cualquier protocolo TCP y UDP, y permite controlar explícitamente dónde se resuelve el dominio.

Para tráfico cifrado, ambos protocolos le dan al intermediario la misma visibilidad. La elección entre ellos no la determina la seguridad, sino tres cosas prácticas: qué sabe hacer tu cliente, qué protocolo hay adentro y dónde querés resolver los nombres.

Qué hacer ahora

1. Determiná el protocolo interno de tu tarea. No es HTTP: directo a SOCKS5.
2. Verificá en la documentación del cliente el soporte de SOCKS5 con autenticación y la opción de resolución remota.
3. Si trabajás con recursos geodependientes, asegurate de que el dominio salga hacia el proxy: socks5h, remote DNS, ATYP=0x03 o HTTP CONNECT.
4. Activá un pool de conexiones o keep-alive hacia el proxy. Eso te va a dar más que cualquier cambio de protocolo.
5. Si el cliente no sabe transmitir el login en SOCKS5, configurá la autorización por IP en el panel de Proxeon.
6. Al depurar, empezá con curl -v: va a mostrar todo el diálogo con el proxy y va a separar de inmediato el problema del cliente del problema de red.

Y para terminar. Ambos protocolos son más viejos que la mayoría de los ingenieros que los usan, y los dos siguen funcionando sin cambios de fondo. Es un caso raro en el que la simplicidad del diseño ganó. Entendiendo qué pasa exactamente en los primeros cuarenta bytes de la conexión, dejás de elegir el puerto al azar y empezás a elegir la herramienta.