Los cuatro protocolos etiquetados como "proxy" comparten poco más que el nombre. Los proxies HTTP analizan la capa 7 y reescriben cabeceras; los proxies SOCKS no leen tu tráfico en absoluto. La diferencia determina qué proxy se adapta a la navegación, el scraping y el tunelizado en bruto.
Proxy HTTP
Un proxy HTTP espera semántica HTTP. Abre la solicitud, lee la URL, puede añadir cabeceras como Via o X-Forwarded-For, y rechaza cualquier cosa que no sea una solicitud HTTP válida. Los navegadores, curl y la mayoría de las bibliotecas de scraping usan proxies HTTP por defecto porque la configuración es prácticamente gratuita: basta con establecer una variable de entorno o pasar una bandera.
El costo de esa simplicidad es la visibilidad. El proxy ve la URL completa, incluida la ruta y la cadena de consulta, y en HTTP sin cifrar también ve el cuerpo. Los proxies de caché pueden reescribir las respuestas; los proxies transparentes pueden eliminar cookies. Trata cualquier proxy HTTP como un intermediario con plenos privilegios y nunca envíes credenciales a través de texto plano.
Proxy HTTPS y el método CONNECT
"Proxy HTTPS" es una etiqueta ligeramente engañosa. Se refiere a un proxy HTTP que además implementa el método CONNECT. CONNECT le indica al proxy que abra un túnel TCP en bruto hacia un host de destino y transporte bytes en ambas direcciones; el cliente y el destino negocian TLS como si el proxy no estuviera presente. El proxy ve el host y puerto de destino, y el volumen de bytes, pero no la carga útil.
Por lo tanto, un proxy "con soporte HTTPS" es un proxy que permite tunelizar TLS, no un proxy que se ejecuta sobre TLS. El enlace desde tu máquina al proxy puede ser texto plano o cifrado de forma independiente. Si te preocupa que ese enlace esté protegido, usa una implementación de SOCKS5 sobre TLS o un proxy comercial de pago que publique su punto final TLS.
SOCKS4
SOCKS4 es el mínimo de 1994: solo TCP, solo IPv4, sin UDP, sin IPv6, sin autenticación, sin resolución de nombres de host en el proxy. El handshake son seis bytes más un código de respuesta de un byte. Sobrevive en la naturaleza porque el protocolo es tan pequeño que casi cualquier herramienta que entienda TCP puede implementarlo correctamente. Si una lista anuncia SOCKS4, espera reenvío TCP en bruto a una dirección IPv4, y nada más.
SOCKS5
SOCKS5, definido en RFC 1928 (1996), es la versión que habla la mayoría de las herramientas modernas. Añade reenvío UDP, direcciones IPv6, autenticación GSSAPI y la opción de resolver nombres de host en el proxy en lugar de en el cliente. Debido a que SOCKS5 no asume nada sobre la capa de aplicación que corre encima, es la opción más flexible para cargas de trabajo que no son HTTP: SSH, IRC, BitTorrent, RPC personalizado.
Rendimiento y sobrecarga
Los proxies SOCKS tienen una sobrecarga menor por solicitud porque no analizan nada. Los proxies HTTP y HTTPS pagan por el análisis completo de la solicitud en cada conexión. Para una única sesión TLS de larga duración dentro de CONNECT, la diferencia es insignificante. Para miles de solicitudes cortas donde el proxy abre una nueva conexión cada vez, SOCKS5 gana de forma medible — típicamente 2–5 ms por solicitud por la ruta de análisis.
Anonimato, en la práctica
Un proxy HTTP que no elimine tus cabeceras puede filtrar tu IP de cliente a través de Via, X-Forwarded-For o Forwarded. Los proxies SOCKS no tienen tales cabeceras porque no tienen el concepto de cabeceras. Eso no es tanto una característica de anonimato como la ausencia de una superficie de fuga. Dentro de HTTPS tunelizado por CONNECT, el destino solo ve el handshake TLS, por lo que cualquier fuga a nivel HTTP en el proxy es irrelevante.
Convenciones de puertos
Verás estos en este directorio: 80, 8080, 3128, 8888 para HTTP; 443 para puntos finales que soportan explícitamente CONNECT; 1080 para SOCKS. Muchos proveedores exponen puertos altos no estándar (por encima de 10,000) para evadir el escaneo casual de puertos. El número de puerto no dice nada sobre la calidad — solo indica lo que el operador eligió exponer.