SOCKS5 vs proxies HTTP: la diferencia que importa

Los proxies HTTP entienden las peticiones web. SOCKS5 es un túnel TCP genérico. Elige el protocolo que tu cliente realmente habla y luego compruébalo.

SOCKS5 vs proxies HTTP: la diferencia que importa

El protocolo no es el origen. Una IP residencial se puede vender como HTTP. El mismo pool se puede vender como SOCKS5. Las IPs de datacenter también existen en las dos formas. Los compradores tratan “SOCKS5” como un grado de calidad. Es un transporte.

La diferencia que importa es lo que tu cliente puede enviar por el túnel y cuánto entiende el proxy de la petición.

01Qué transporta un proxy HTTP#

Un proxy HTTP habla el protocolo de proxy HTTP. Para HTTPS suele usar CONNECT. Tu cliente pide al proxy que abra un túnel hacia un host y un puerto. Después, TLS corre entre tú y el destino. El proxy ve el host al que te conectaste. No ve la página descifrada si TLS está bien hecho.

El HTTP en claro es distinto. El proxy puede leer la petición. Puede inyectar cabeceras. Puede guardar en caché. La mayoría de los sitios públicos ahora redirigen a HTTPS, así que CONNECT es la ruta que realmente usas.

Los proxies HTTP bastan para navegadores, para muchos scrapers y para cualquier cosa que ya sepa configurar https_proxy. Encajan mal con TCP arbitrario. Un cliente de correo, un juego o un binario propio no hablan CONNECT salvo que alguien se lo haya enseñado.

Algunos proveedores añaden cabeceras extra en productos HTTP. Esas cabeceras pueden identificarte como usuario de proxy. Revisa una petición en crudo si el destino es sensible a eso.

02Qué transporta SOCKS5#

SOCKS5 es un túnel genérico para TCP y, de forma opcional, para UDP. No le importa que el payload sea HTTP. El cliente dice “conéctate a este host y puerto”. El proxy lo hace. El DNS se puede resolver en local o en remoto según cómo esté configurado el cliente.

El DNS remoto por SOCKS5 es la forma habitual de evitar una fuga de DNS en apps que lo soportan. El DNS local es la forma habitual de producir una fuga, porque la resolución de nombres sigue yendo a tu ISP. Pruébalo. Los pasos de cómo comprobar si un proxy funciona cubren DNS y WebRTC.

La autenticación SOCKS5 suele ser usuario y contraseña. Algunos clientes todavía esperan SOCKS4 sin auth. Esos clientes fallan contra un gateway moderno. Lee la documentación del cliente antes de culpar al proveedor.

UDP sobre SOCKS5 importa para parte del tráfico de voz y de juegos. No importa para scraping ordinario. Si el listado del proveedor menciona UDP y tú solo pides páginas HTTPS, ignora el extra.

03Qué deberían usar navegadores y scrapers#

Un navegador que solo carga sitios web funciona con HTTP CONNECT. SOCKS5 también funciona si el ajuste de proxy del navegador lo soporta. Elige el que el perfil ya conoce. Mezclar ambos en un perfil es cómo aparecen fugas por caminos distintos.

Un scraper en Python o Node debería usar el ajuste de librería que ya está probado en ese stack. Los proxies HTTP son el valor por defecto en muchos clientes HTTP. SOCKS5 a menudo necesita un paquete extra. Los paquetes extra fallan de formas sorprendentes. Prefiere el valor por defecto salvo que necesites TCP que no sea HTTP.

Los navegadores anti-detect y algunas apps móviles prefieren SOCKS5 porque el resto de la app no es un cliente HTTP. La misma regla vale en cualquier sitio donde el cliente oficial exponga un campo SOCKS y no un campo HTTP.

El origen datacenter o residencial sigue mandando en el éxito en un sitio que puntúa el tráfico. Pasar de HTTP a SOCKS5 no convierte un ASN de hosting en un ASN doméstico. Cambia el origen. Mira proxies residenciales vs datacenter.

04Cómo verificar el protocolo#

No confíes en el número de puerto. 8080, 3128, 1080 y 60000 se han reutilizado para ambos protocolos. Confía en una comprobación en vivo.

Apunta el comprobador de proxies al host, puerto, usuario y contraseña. Selecciona el protocolo que crees que compraste. Un acierto en HTTP y un fallo en SOCKS5 significa que compraste HTTP. Lo contrario también ocurre. Algunos gateways hablan ambos. Debes probar ambos si más adelante podrías cambiar de cliente.

Mira el DNS en la misma comprobación. Un cliente SOCKS5 con DNS local seguirá exponiendo tu resolvedor. Fuerza DNS remoto si el cliente lo ofrece.

Mira IPv6. Un túnel SOCKS5 en IPv4 no transporta un destino v6 salvo que el gateway lo soporte. Los listados dual-stack necesitan una prueba dual-stack.

El protocolo es una elección de compatibilidad del cliente. El origen es una elección de acceso. El modo de sesión es una elección de flujo. Cómpralos en ese orden y no pagarás SOCKS5 como si fuera una IP más limpia.