Un proxy HTTP y SOCKS5 resuelven la misma tarea —sustituir tu dirección ante el servidor—, pero lo hacen en niveles distintos de la pila de red, y de ahí se deriva todo lo demás: qué tráfico dejan pasar, qué ven y pueden modificar, cómo se comportan con DNS y UDP y con qué programas son compatibles en general. La velocidad, contra lo que se suele creer, aquí casi no influye. A continuación, un análisis de ambos protocolos, una tabla de diferencias y una regla de elección que resuelve nueve de cada diez casos.
En resumen
- Proxy HTTP entiende HTTP. Lee la petición, sabe a dónde vas, puede añadir encabezados, cachear la respuesta o bloquear una dirección. HTTPS lo deja pasar a ciegas mediante el comando
CONNECT. El tráfico que no es HTTP no es asunto suyo. - SOCKS5 no entiende nada y no quiere entender nada. Tras un breve handshake, simplemente reenvía bytes en ambos sentidos: TCP de cualquier protocolo y, si hace falta, UDP. Dentro puede haber cualquier cosa: una web, correo, Telegram, un juego, un torrent.
- Ni uno ni otro cifran el tráfico por sí mismos. La protección de los datos es responsabilidad del protocolo interno (HTTPS, TLS), no del proxy.
En qué nivel opera cada uno
El proxy HTTP vive en la capa de aplicación. El cliente le envía una petición HTTP normal, solo que con la dirección completa en la primera línea (GET http://example.com/page HTTP/1.1), el proxy abre la conexión con el servidor, recibe la respuesta y se la entrega al cliente. Todo el contenido pasa por él en texto plano y tiene derecho a modificarlo.
Para HTTPS el esquema es distinto: el cliente pide al proxy que establezca un túnel con el comando CONNECT example.com:443, el proxy conecta los dos sockets y a partir de ahí solo reenvía los bytes cifrados. Ve el nombre del host y el puerto, pero no la ruta, ni los encabezados, ni el cuerpo de la petición.
SOCKS5 (RFC 1928) está más abajo, entre el transporte y la aplicación. El cliente acuerda con el proxy el método de autenticación, indica la dirección de destino (IPv4, IPv6 o nombre de dominio) y el puerto, el proxy abre la conexión y desde ese momento se convierte en un tubo transparente. No sabe qué protocolo hay dentro y por eso funciona con cualquiera. Si necesitas repasar los fundamentos, empieza por el artículo sobre qué es un servidor proxy.
Cómo funciona un proxy HTTP
Qué puede hacer porque entiende el protocolo
- Cacheo. Las peticiones repetidas a un mismo recurso pueden no llegar al servidor: así funcionan los proxies corporativos y de proveedor.
- Filtrado por URL. El proxy ve la dirección y puede bloquearla, eliminar rastreadores o redirigir.
- Modificación de encabezados. Puede añadir
Via,X-Forwarded-ForoForwarded(RFC 7239) y con ello revelar tu dirección real. También puede eliminar lo que sobre. - Autenticación. El usuario y la contraseña se transmiten en el encabezado
Proxy-Authorization, casi siempre con el esquema Basic, es decir, en codificación Base64 y sin cifrado. Por un canal no protegido se ven.
Qué no puede hacer
Todo lo que no sea HTTP. Los protocolos de correo, SSH, servidores de juegos, clientes de torrent, VoIP o bien no funcionan a través de un proxy HTTP, o bien exigen que el programa sepa envolver la conexión en CONNECT y que el proxy permita esos túneles hacia puertos arbitrarios. Muchos proxies solo permiten CONNECT al puerto 443.
Tres grados de anonimato
Por culpa de los encabezados, los proxies HTTP se dividen tradicionalmente en tres clases. El transparente transmite tu IP real en X-Forwarded-For y avisa de su presencia en Via. El anónimo oculta la dirección, pero deja los encabezados sobre el proxy: el servidor entiende que hay un intermediario delante. El elite no añade nada y parece un cliente normal. SOCKS5 no tiene esta clasificación: no accede a los encabezados y no añade nada por definición.
Cómo funciona SOCKS5
El handshake
La conexión empieza con el cliente enumerando los métodos de autenticación que admite y el servidor eligiendo uno: sin autenticación, con usuario y contraseña (RFC 1929) o GSS-API. Después el cliente envía una petición con el comando, el tipo de dirección y el puerto. Los comandos son tres: CONNECT —conexión TCP saliente normal—, BIND —aceptar una conexión entrante (necesario, por ejemplo, para FTP activo)— y UDP ASSOCIATE —abrir una retransmisión de datagramas UDP.
DNS remoto
La diferencia clave con SOCKS4: la dirección de destino se puede pasar como nombre de dominio, y entonces el nombre lo resuelve el proxy, no tu ordenador. En curl y Python esta distinción se refleja en el esquema de la URL: socks5:// resuelve el nombre localmente, socks5h:// lo hace del lado del proxy. La primera opción deja las consultas DNS en tu proveedor, la segunda se las lleva junto con el tráfico. Para tareas en las que importa no revelar la dirección, hace falta precisamente socks5h.
UDP
A través de UDP ASSOCIATE va todo aquello para lo que TCP no sirve: voz y vídeo en mensajería, DNS, parte de los protocolos de juegos, QUIC. En la práctica, no todos los servidores ni todos los clientes admiten UDP a través de SOCKS5, así que antes de comprar un proxy para esa tarea hay que comprobarlo aparte.
Contraseña sin cifrado
El usuario y la contraseña en SOCKS5 (método RFC 1929) se transmiten en texto plano, igual que en HTTP Basic. El canal hasta el proxy no está protegido en ninguno de los dos casos; solo TLS dentro de la conexión hace que el tráfico sea seguro. Si el proveedor ofrece autorización por IP, es igual de fiable y no deja la contraseña en los registros de los programas.
Las diferencias principales en una tabla
| Criterio | Proxy HTTP | SOCKS5 |
|---|---|---|
| Nivel | De aplicación (entiende HTTP) | De sesión (transmite bytes) |
| Tráfico | HTTP, HTTPS mediante CONNECT | Cualquier TCP, opcionalmente UDP |
| Ve el contenido | Sí para HTTP, solo el host para HTTPS | Solo la dirección de destino |
| Puede modificar la petición | Sí (encabezados, caché, filtros) | No |
| Resolución DNS | En el proxy | En el proxy (socks5h) o localmente (socks5) |
| Cifrado | No (solo el de HTTPS interno) | No (solo el del protocolo interno) |
| Autenticación | Proxy-Authorization, Basic | Usuario y contraseña (RFC 1929), GSS-API, sin autenticación |
| Compatibilidad con programas | Casi en todas partes | Amplia, pero no universal |
| Sobrecarga | Análisis de encabezados | Mínima |
Velocidad: por qué la diferencia no está donde se busca
SOCKS5 no analiza encabezados ni almacena respuestas en búfer, así que en teoría ahorra microsegundos en cada petición. Frente a la latencia de red hasta el proxy y desde el proxy hasta el servidor, eso es indistinguible. La velocidad real la determinan cuatro cosas: la distancia hasta el servidor proxy y desde él hasta el objetivo, el tipo de dirección IP (los canales móviles y residenciales son más lentos que los de datacenter; más detalles en el artículo sobre tipos de proxy), la carga de ese servidor concreto y el número de conexiones que abres en paralelo. El protocolo no está en esa lista.
El único caso en que un proxy HTTP es claramente más rápido es un proxy con caché sobre contenido repetido. El único caso en que SOCKS5 es claramente más rápido es el tráfico que por un proxy HTTP no habría pasado en absoluto.
Anonimato y fugas
La fuga de la dirección a través de un proxy no ocurre «por el protocolo», sino por mecanismos concretos, y cada uno tiene su causa.
- Encabezados. Un proxy HTTP transparente entrega tu IP en
X-Forwarded-For. Se soluciona eligiendo un proxy elite. SOCKS5 no tiene ese canal de fuga. - DNS. Si el nombre se resuelve localmente, tu proveedor ve a dónde vas. El proxy HTTP y
socks5hresuelven de su lado;socks5, no. - WebRTC. El navegador puede revelar la dirección local y la externa a través de STUN saltándose cualquier proxy. Es una característica del navegador, no del proxy; se cierra con ajustes o una extensión.
- Tráfico fuera del proxy. El proxy se configura en una aplicación. Todo lo que no hayas configurado —actualizaciones del sistema, otro navegador, un mensajero— sale directamente. Si hace falta cubrir el dispositivo entero, eso es tarea de una VPN; consulta proxy frente a VPN y Tor.
Compatibilidad con programas
- Navegadores. Chrome y Edge toman el proxy de la configuración del sistema y entienden ambos tipos; Firefox tiene su propia configuración y sabe «proxificar DNS con SOCKS5» con una casilla aparte.
- curl.
curl -x http://user:pass@host:portpara HTTP,curl -x socks5h://user:pass@host:portpara SOCKS5 con DNS remoto. - Python. En
requestsyhttpxlos proxies HTTP funcionan de serie; SOCKS5, tras instalar un paquete adicional; el esquemasocks5h://también traslada la resolución al proxy. - Telegram, Discord, clientes de torrent, juegos. Por norma general, solo SOCKS5: su tráfico no es HTTP.
- Navegadores antidetect y scrapers. Admiten ambos; los proveedores de proxies móviles y residenciales suelen ofrecer el mismo puerto en los dos protocolos.
- SSH.
ssh -D 1080 user@serverlevanta un proxy SOCKS5 local a través de cualquier servidor al que tengas acceso: una forma cómoda de comprobar cómo se comporta un programa con SOCKS5.
Cuándo elegir cada uno
| Tarea | Elección | Por qué |
|---|---|---|
| Navegador, trabajo con webs | Cualquiera; HTTP con más frecuencia | Todo el tráfico es HTTP(S), compatibilidad universal |
| Scraping mediante una librería HTTP | HTTP o socks5h | Lo importante es resolver el DNS en el proxy y no enviar encabezados de más |
| Mensajeros, juegos, torrents, correo | SOCKS5 | Tráfico no HTTP, a veces UDP |
| Muchas cuentas en un navegador antidetect | Cualquiera; fijarse en la IP, no en el protocolo | El antifraude evalúa la dirección y el fingerprint, no la forma de conexión |
| Red corporativa, control y caché | HTTP | Hacen falta filtrado y registro por URL |
| Privacidad total del dispositivo | Ninguno de los dos | Es tarea de una VPN o de Tor |
Regla: si el programa tiene un campo «proxy HTTP» y solo va por HTTP(S), elige HTTP. Si el programa no es web o solo tiene «SOCKS5», elige SOCKS5 con DNS remoto. Discutir sobre la velocidad no tiene sentido.
Errores típicos
- Esperar que el proxy cifre. Ni HTTP ni SOCKS5 protegen el tráfico hasta el proxy; solo lo protege TLS dentro de la conexión.
- Usar
socks5://en lugar desocks5h://y luego buscar de dónde «se fuga» el DNS. - Configurar un proxy HTTP en un programa que no va por HTTP y achacar su silencio a un «proxy malo».
- Elegir el protocolo por velocidad. La velocidad la determinan la dirección y la ruta, y comprobarlas lleva un minuto; consulta cómo comprobar un proxy en cuanto a anonimato, fugas y velocidad.
- Considerar que un proxy HTTP elite es «más anónimo» que SOCKS5. Ninguno de los dos revela la dirección; la diferencia es solo que SOCKS5 no tiene ni la capacidad técnica de añadirla.
Preguntas y respuestas
¿Qué es más rápido, SOCKS5 o un proxy HTTP?
En el mismo servidor, la diferencia es inmedible frente a la latencia de red. La velocidad la marcan el tipo de IP, la distancia y la carga del servidor, no el protocolo.
¿SOCKS5 cifra el tráfico?
No. SOCKS5 transmite los bytes tal cual; el usuario y la contraseña también van en texto plano. Lo que hace seguro el tráfico es TLS dentro de la conexión, por ejemplo HTTPS.
¿Se puede usar un proxy HTTP para Telegram o torrents?
Por norma general, no: su tráfico no es HTTP, y la mayoría de los proxies HTTP prohíben el túnel mediante CONNECT hacia puertos arbitrarios. Para esos programas hace falta SOCKS5.
¿En qué se diferencia socks5h de socks5?
La letra h significa que el nombre de dominio lo resuelve el servidor proxy. Sin ella, la consulta DNS sale de tu ordenador a través de tu proveedor, y este ve la dirección de destino.
¿Qué protocolo es más anónimo?
Un proxy HTTP elite y SOCKS5 no revelan tu dirección por igual. Un proxy HTTP transparente la revela a través de los encabezados; SOCKS5 no tiene ese mecanismo. Las demás fugas —DNS, WebRTC, tráfico fuera del proxy— no dependen del protocolo.