Proxies SOCKS y HTTP: diferencias, velocidad y elección del protocolo
Los proxies HTTP y SOCKS conectan una aplicación con un destino a través de un intermediario. Para un navegador, un programa de extracción de datos o un cliente de API, un proxy HTTP con CONNECT es un punto de partida práctico. SOCKS5 resulta útil cuando la aplicación espera SOCKS, necesita otros protocolos TCP o admite reenvío UDP. Ambos pueden transportar tráfico a sitios HTTPS.
El protocolo determina cómo se comunica el programa con el proxy. El origen de la IP de salida, la rotación y el acceso compartido o dedicado son decisiones separadas, explicadas en la guía de tipos de proxies y elección de una configuración. Cambiar de HTTP a SOCKS no modifica por sí solo ninguna de esas propiedades.
Cómo gestionan HTTP y SOCKS una conexión
Reenvío HTTP: el proxy procesa una solicitud web
En una solicitud HTTP ordinaria sin cifrar, el cliente envía al proxy la URL de destino, el método y las cabeceras. El proxy procesa esa solicitud y obtiene la respuesta del destino. Puede aplicar reglas HTTP, cambiar cabeceras o utilizar una caché cuando está configurado para ello. Son funciones posibles de un proxy HTTP; un servicio no necesariamente las activa todas.
SOCKS5: el proxy abre una conexión para la aplicación
El cliente acuerda un método de autenticación, se autentica si es necesario y proporciona una dirección y un puerto de destino. Después, el proxy establece la conexión TCP solicitada y retransmite los bytes de la aplicación. El mismo mecanismo puede transportar HTTPS, SSH u otro protocolo de aplicación TCP compatible. El proxy no necesita interpretar solicitudes HTTP para reenviarlas.
HTTPS mediante CONNECT: los dos métodos se aproximan
Al abrir un sitio HTTPS a través de un proxy HTTP convencional, el cliente suele enviar una solicitud CONNECT. Cuando el proxy acepta el túnel, el cliente establece TLS con el sitio dentro de él. El proxy retransmite los datos cifrados. SOCKS5 puede retransmitir el mismo intercambio TLS después de su propio establecimiento de conexión.
Esto importa al comparar velocidad y privacidad: un proxy HTTP que transporta HTTPS en un túnel no analiza cada solicitud de página cifrada. Ambos tipos retransmiten el tráfico protegido. La secuencia y la distinción entre reenvío HTTP y túneles se explican en Proxies HTTP y HTTPS.
HTTP y SOCKS5 de un vistazo
La siguiente comparación utiliza SOCKS5. Las versiones anteriores SOCKS4 y SOCKS4a tienen menos funciones y resultan relevantes sobre todo cuando un programa existente las exige.
| Función | Proxy HTTP / HTTPS | Proxy SOCKS5 |
|---|---|---|
| Solicitudes web | Reenvío HTTP; HTTPS suele utilizar un túnel CONNECT. | La aplicación envía HTTP o HTTPS a través de la conexión establecida. |
| Otras aplicaciones TCP | Posibles mediante CONNECT si el cliente lo admite y el puerto de destino está permitido. | Una opción natural para aplicaciones compatibles con SOCKS; las reglas del servicio siguen aplicándose. |
| DNS del destino | El proxy puede resolver el nombre de host proporcionado en la solicitud o en el destino de CONNECT. | El cliente puede enviar un nombre de host para su resolución remota o resolverlo primero localmente. |
| Protección hasta el proxy | Un proxy HTTPS utiliza TLS en esta conexión. Un proxy HTTP sin TLS no lo hace. | Los modos ordinarios sin autenticación y con usuario y contraseña no cifran esta conexión. |
| Control de acceso | Métodos de autenticación HTTP y/o reglas de acceso del servicio, como una lista de IP permitidas. | Métodos de autenticación negociados y/o reglas de acceso del servicio, como una lista de IP permitidas. |
| UDP | El CONNECT ordinario no basta. UDP necesita un mecanismo de túnel adicional compatible. | Definido por el protocolo, pero deben implementarlo el cliente y el servicio. |
| Rendimiento | Para un túnel HTTPS nuevo, el establecimiento puede requerir menos viajes de ida y vuelta. La velocidad de transferencia también depende de la implementación y de la ruta. | Tiene sus propios intercambios de establecimiento. La ausencia de análisis HTTP no garantiza transferencias HTTPS más rápidas. |
¿Qué es más rápido: HTTP o SOCKS5?
Una conexión HTTPS nueva puede estar lista antes mediante HTTP CONNECT porque su establecimiento habitual exige menos intercambios con el proxy. La comparación siguiente muestra las condiciones que explican esa diferencia. Una vez abierto un túnel, una descarga larga o solicitudes posteriores pueden reutilizarlo. Ningún protocolo tiene una ventaja fija en velocidad de transferencia sostenida.
Conexiones nuevas: cuenta los intercambios
Cuenta los mensajes de establecimiento después de que la conexión TCP con el proxy esté lista, esperando la respuesta de cada solicitud. Esta comparación no utiliza una capa TLS hasta el proxy. La autenticación HTTP no es necesaria o se completa con las credenciales incluidas en la primera solicitud CONNECT.
| Método de conexión | Intercambios antes de que el túnel esté listo |
|---|---|
HTTP CONNECT | 1: la solicitud CONNECT y su respuesta satisfactoria. |
| SOCKS5 sin autenticación de protocolo | 2: selección del método y después solicitud de conexión y respuesta. |
| SOCKS5 con nombre de usuario y contraseña | 3: selección del método, verificación de usuario y contraseña, y después solicitud de conexión y respuesta. |
Por tanto, bajo estas condiciones, SOCKS5 añade un viaje de ida y vuelta entre cliente y proxy sin autenticación, o dos con la autenticación estándar de usuario y contraseña. Un viaje de ida y vuelta, o RTT, es el tiempo que tarda un mensaje en llegar al proxy y su respuesta en volver. Con un RTT ilustrativo de 50 ms, esos intercambios adicionales suponen aproximadamente 50 o 100 ms. Es una estimación basada en la secuencia del protocolo, no una medición de un servicio de proxies ni del tiempo total de la solicitud.
Ambas rutas también requieren que el proxy se conecte al destino y que el cliente complete el establecimiento TLS con el sitio. El tiempo DNS, el procesamiento y la congestión pueden ser distintos. Un desafío de autenticación HTTP añade intercambios; TLS hasta un proxy HTTPS añade su propio establecimiento. Esos casos deben incluirse al comparar las configuraciones reales.
Conexiones reutilizadas: la diferencia inicial se reparte entre solicitudes
Un grupo de conexiones mantiene conexiones adecuadas disponibles para solicitudes posteriores. Reutilizar una conexión HTTPS evita repetir TCP, la negociación del proxy y el intercambio TLS del sitio en cada solicitud. Si el cliente y el destino admiten HTTP/2, varios flujos de solicitudes pueden compartir una conexión establecida. Esto puede funcionar tanto dentro de un túnel HTTP CONNECT como de una conexión SOCKS5; el proxy no necesita analizar los mensajes HTTP/2 que van dentro de TLS.
Crear un objeto cliente HTTP nuevo para cada URL puede descartar su grupo de conexiones. Aquí, reutilizar un cliente significa conservar el objeto del programa y sus conexiones, no pedir al proxy que conserve una IP de salida. Cuando un lote contacta repetidamente con los mismos hosts, reutilizar esas conexiones puede ahorrar más trabajo de establecimiento que cambiar de protocolo de proxy. Los destinos nuevos, las conexiones cerradas y los cambios de configuración del proxy pueden seguir requiriendo túneles nuevos.
Transferencias grandes: considera el ancho de banda disponible
Una vez establecido un túnel, la velocidad de descarga depende de la ruta, la pérdida de paquetes, el ancho de banda disponible, la carga del proxy y los límites del servicio. Retransmitir HTTPS mediante CONNECT ya es una tarea de reenvío de bytes. Describir SOCKS5 como más rápido porque «no lee HTTP» pasa por alto este caso.
Para HTTP sin cifrar, una caché configurada o el procesamiento de contenido pueden cambiar el resultado. Una respuesta almacenada en caché supone una carga distinta de descargar el mismo contenido desde el origen. Una comparación justa debe tener en cuenta esa diferencia.
¿Qué protocolo debería utilizar un script web grande?
Un script web sigue haciendo solicitudes HTTP cuando utiliza SOCKS5; la opción de proxy cambia cómo llega al servidor. Para un script nuevo que obtiene páginas web o llama a API HTTPS, empieza con un cliente HTTP consolidado y HTTP CONNECT, salvo que un requisito concreto aconseje otra opción. Mantén la elección de proxy en la configuración para poder probar SOCKS5 con la misma lógica de solicitudes. Elige una biblioteca compatible con ambos si esta comparación importa al proyecto.
| Carga de trabajo | Punto de partida práctico |
|---|---|
| Muchas solicitudes breves, a menudo a hosts nuevos | Prueba primero HTTP CONNECT. Su negociación más corta puede ayudar cuando se necesitan túneles nuevos con frecuencia. Mide solicitudes completas y satisfactorias. |
| Muchas solicitudes a un conjunto pequeño de API o sitios | Utiliza un cliente persistente, un grupo de conexiones y HTTP/2 cuando se admita. Compara HTTP y SOCKS5 después de comprobar la reutilización. |
| Archivos grandes o sesiones TCP de larga duración | Elige el protocolo con buena compatibilidad y prueba el rendimiento sostenido y las interrupciones. El establecimiento representa una parte menor del trabajo. |
| Otros protocolos TCP o una función UDP necesaria | Considera SOCKS5 si la aplicación admite el modo necesario. Si UDP es esencial, verifica que la aplicación y el servicio puedan intercambiar datagramas a través del proxy. |
Tanto HTTP como SOCKS5 pueden utilizarse en programas asíncronos. El protocolo del proxy no determina si las solicitudes se ejecutan simultáneamente. Comprueba que la biblioteca cliente pueda utilizar el modo de proxy elegido para solicitudes simultáneas, conservar su grupo de conexiones y limitar el número de operaciones en curso. Aumenta la concurrencia observando el trabajo completado y los errores: cuando el proxy, la red o el destino alcanzan su límite, más conexiones pueden significar colas más largas y más reintentos.
Cómo comparar la velocidad antes de ampliar la carga
- Utiliza el mismo programa, solicitudes de destino, tamaños de respuesta y concurrencia. Cuando sea posible, compara puntos de conexión de los protocolos con la misma IP de salida y ruta; en caso contrario, mantén comparables la región de salida y los límites del servicio, y registra la diferencia.
- Ejecuta una serie con conexiones nuevas y otra con el grupo de conexiones habitual después del calentamiento. Mantén equivalentes el comportamiento DNS, la protección TLS, la autenticación, la versión HTTP y la política de reintentos, o documenta por qué son distintos.
- Mide las operaciones completadas satisfactoriamente por segundo y el tiempo de todo el lote, incluidos los reintentos. Registra también la mediana y el percentil 95 del tiempo de finalización, los tiempos de espera agotados y las operaciones fallidas. El percentil 95 indica el tiempo dentro del cual termina el 95% de las operaciones medidas.
- En las descargas, registra los bytes útiles recibidos por segundo. Para solicitudes breves, separa el establecimiento de la conexión del tiempo hasta el primer byte y del tiempo de respuesta completa. El tiempo hasta el primer byte también incluye la espera a que el destino genere una respuesta.
- Repite ejecuciones alternadas con ambas configuraciones y verifica la ruta de proxy prevista. Si una prueba utiliza otro grupo de salidas o recurre a una conexión directa, su resultado no aísla el protocolo del proxy.
Elige la configuración que complete el trabajo real más rápido con una tasa de errores aceptable. Un fallo rápido de autenticación o una respuesta incompleta no son rendimiento útil. Si ambos ofrecen resultados similares, prefiere el que sea más sencillo de mantener en la aplicación elegida.
Por qué la compatibilidad de la aplicación es lo primero
Un campo llamado «proxy» no promete todos los protocolos ni todos los métodos de autenticación. Por ejemplo, la compatibilidad SOCKS5 incorporada en Chrome admite solicitudes TCP, pero no implementa la autenticación SOCKS5 con usuario y contraseña ni el reenvío UDP. Un servicio SOCKS5 con esas funciones no puede hacer que un modo de navegador incompatible las utilice.
Para SSH, transferencia de archivos u otra aplicación TCP, la compatibilidad SOCKS nativa puede resultar cómoda. HTTP CONNECT también puede transportar otros protocolos TCP, siempre que el programa pueda crear el túnel y el proxy permita el puerto de destino. Por tanto, «proxy HTTP» no siempre significa «solo tráfico web».
La configuración de proxy del navegador tampoco cubre automáticamente otro programa ni todas las funciones del navegador. Los adaptadores externos tienen su propio alcance y restricciones. Las diferencias entre versiones y la negociación se tratan en Proxies SOCKS5 y SOCKS4.
¿Quién resuelve el nombre de host del destino?
Con SOCKS5, la aplicación puede resolver el destino localmente y enviar una dirección IP, o enviar un nombre de host para que lo resuelva el proxy. En curl, socks5:// selecciona la resolución local del destino, mientras que socks5h:// solicita su resolución a través del proxy. La letra adicional selecciona el comportamiento del cliente; no crea un protocolo SOCKS nuevo.
Los proxies HTTP también pueden resolver nombres de destino recibidos en URL o solicitudes CONNECT. Por tanto, ambos protocolos disponen de DNS remoto para el destino. Una consulta desde el lado del proxy puede devolver otra dirección de servidor y evita una consulta local para ese destino. El cliente puede seguir necesitando resolver el nombre de host del propio proxy, y otras aplicaciones mantienen su propia configuración DNS. Elige el comportamiento DNS en el cliente en lugar de deducirlo del protocolo del proxy.
¿Qué conexión está cifrada?
Distingue la protección del contenido del sitio de la protección de la conexión hasta el proxy. Un sitio HTTPS normalmente mantiene cifrados los datos de aplicación entre cliente y sitio a través de cualquiera de los dos tipos de túnel. Esto presupone una validación normal de certificados y que no haya interceptación TLS configurada.
Un proxy HTTPS añade TLS entre cliente y proxy. Protege la solicitud al proxy y las credenciales en esa parte de la ruta. En una dirección de proxy, https:// suele indicar esta conexión protegida. Una opción descrita solo como «proxy para sitios HTTPS» puede referirse, en cambio, a un proxy HTTP sin TLS que admite CONNECT.
Las credenciales HTTP Basic enviadas a un proxy HTTP sin TLS, y el intercambio estándar SOCKS5 de usuario y contraseña, son legibles para quien pueda observar esa ruta de red sin protección. La conexión TLS posterior con el sitio web no protege retroactivamente el inicio de sesión del proxy. El SOCKS5 ordinario necesita un transporte seguro separado cuando se requiere esta protección.
El proxy sigue siendo un extremo de su propia conexión TLS y sabe a dónde se le pide conectarse. Si el destino final utiliza HTTP sin cifrar, TLS hasta el proxy no cifra la conexión HTTP posterior. Del mismo modo, el reenvío SOCKS no oculta el contenido en texto claro simplemente porque el proxy no necesite analizarlo.
¿Cambian UDP o HTTP/3 la elección?
Para una aplicación que realmente necesita UDP, SOCKS5 define UDP ASSOCIATE. El cliente y el servicio deben implementarlo, y la ruta de red debe transportar los datagramas. El HTTP CONNECT ordinario transporta un túnel TCP. Es posible reenviar UDP mediante HTTP con mecanismos adicionales como CONNECT-UDP, pero ambos extremos deben implementarlos.
HTTP/3 utiliza QUIC sobre UDP. Que una página HTTPS cargue correctamente a través de un proxy no demuestra que funcione HTTP/3: el cliente puede haber utilizado HTTP/2 o HTTP/1.1 sobre TCP. Esa alternativa puede servir para un script web; no puede sustituir a UDP en una función que requiere datagramas. Consulta UDP y QUIC a través de proxies para conocer las rutas de reenvío y sus limitaciones.
¿Oculta SOCKS mejor al cliente?
En el reenvío HTTP sin cifrar, un proxy puede añadir una cabecera como Forwarded con información sobre el cliente original. Un túnel HTTPS CONNECT convencional no puede insertar esa cabecera en la solicitud cifrada sin terminar la conexión TLS del sitio. SOCKS5 tampoco añade automáticamente cabeceras HTTP.
Esto no convierte a ninguno de los dos protocolos en una garantía de anonimato o aceptación por un sitio web. El operador del proxy puede observar metadatos de conexión, mientras el destino puede reconocer una cuenta, las cookies o el comportamiento de la aplicación. La reputación de la IP de salida y el número de usuarios que la comparten son factores separados. Cambiar de HTTP a SOCKS en el mismo servicio no elimina automáticamente los bloqueos ni reinicia una sesión del sitio web.
Cómo tomar la decisión final
Empieza por los protocolos y métodos de acceso compatibles con la aplicación. Para la automatización web ordinaria, HTTP CONNECT es una primera opción razonable; para una aplicación basada en SOCKS o en un modo UDP compatible, SOCKS5 puede encajar mejor. Después, elige el comportamiento DNS y la protección hasta el proxy que necesitas, y compara el rendimiento con la carga real.
Utiliza el nombre de host y el puerto reales del servicio para el protocolo elegido. Sustituir http:// por socks5:// en una configuración no activa SOCKS en un servidor que no lo proporciona. Antes de ampliar la carga, confirma que las solicitudes salen por el proxy previsto y que un fallo del proxy no provoca silenciosamente una ruta directa no deseada.