Fingerprinting TLS y JA3: cómo afecta al scraping

La huella TLS identifica a un cliente HTTP a partir de la estructura de su saludo (handshake) TLS, antes de que se transmita cualquier dato de aplicación. JA3 y JA4 convierten los campos del mensaje ClientHello en un hash corto, y los sistemas anti-bot comparan ese hash con firmas conocidas de navegadores y bots. Una discrepancia entre el navegador declarado y el hash puede hacer que una solicitud sea rechazada antes incluso de que se lean las cabeceras.

Leyenda usada en todas las tablas a continuación: ✅ documentado por el proveedor · ❌ no ofrecido o no documentado · ⚠️ documentado con limitaciones · 💡 consejo práctico. No se usan otras marcas en esta página.

Qué es una huella TLS

Una huella TLS es una firma corta construida a partir de los campos que un cliente HTTP envía en su mensaje client hello durante el saludo TLS, antes incluso de que comience el cifrado. Entender qué es JA3 empieza aquí: JA3 lee cinco de esos campos y los convierte en un único hash. Cada cliente, ya sea Chrome, curl o un script de Python, lista sus suites de cifrado, extensiones y curvas elípticas en su propio orden particular. Los servidores leen estos datos en texto plano, ya que ninguna de las partes ha acordado todavía claves de cifrado.

El client hello también lleva una extensión alpn, que indica al servidor si la conexión prefiere HTTP/1.1 o HTTP/2. Las diferentes bibliotecas ensamblan estos campos de manera distinta según la pila TLS subyacente, OpenSSL frente a BoringSSL frente a NSS, por ejemplo. Esa es la materia prima con la que trabajan tanto JA3 como JA4.

💡 Consejo: si dos solicitudes llevan la misma huella pero navegadores declarados diferentes, esa inconsistencia por sí sola puede generar sospechas sin que haya ningún truco de cabeceras de por medio.

Cómo se calculan JA3 y JA4

Una huella JA3 se calcula concatenando cinco campos del ClientHello en una sola cadena y aplicándole un hash MD5, lo que produce una firma de 32 caracteres (Scrapfly, Guía de huellas TLS JA3/JA4, 2026). John Althouse, Jeff Atkinson y Josh Atkins publicaron el método original en Salesforce en 2017, y todavía constituye la columna vertebral de la mayoría de las comprobaciones de bots basadas en TLS en la actualidad. Los cinco campos que alimentan ese hash son la versión de TLS, las suites de cifrado, las extensiones, las curvas elípticas y los formatos de punto, unidos en un orden fijo.

1. Extraer la versión de TLS, expresada como un número decimal como 771 para TLS 1.2.
2. Listar las suites de cifrado exactamente en el orden en que el cliente las envió, separadas por guiones.
3. Listar las extensiones TLS en orden de envío, separadas por guiones, omitiendo los valores GREASE.
4. Añadir las curvas elípticas y los formatos de punto admitidos.
5. Unir los cinco campos con comas y aplicar un hash MD5 a la cadena resultante para obtener el hash ja3.

Cómo se construye un hash JA3 a partir del ClientHello

El método más reciente omite el problema de ordenación del paso 3. En lugar de registrar las extensiones tal como se enviaron, las ordena por valor hexadecimal, lo que mantiene estable la huella JA4 incluso después de que los navegadores empezaran a aleatorizar el orden de extensiones en 2023 (Scrapfly, 2026). Ese hash sucesor también abandona el MD5 en favor de un SHA-256 truncado y añade soporte para ALPN y QUIC, detalles que JA3 nunca capturó.

Estas diferencias estructurales importan a cualquiera que pruebe su propio cliente. Una huella calculada de una forma no coincidirá con una base de datos construida para el otro método.

Por qué los proxies por sí solos no resuelven el fingerprinting

Los proxies cambian la dirección IP de la que procede una solicitud; no tocan para nada el saludo TLS, de modo que la huella TLS sigue viendo la biblioteca que inició la conexión. El saludo ocurre directamente entre el cliente y el servidor de destino, y un proxy HTTPS estándar que usa el método CONNECT simplemente canaliza los bytes cifrados sin tocarlos (Shifter, glosario de TLS, 2026). Esto significa que una IP residencial limpia combinada con un cliente Python predeterminado sigue entregando una huella que se lee como script, no como navegador.

En nuestra prueba, agosto de 2026, una sesión de requests predeterminada enrutada a través de tres tipos de proxy diferentes devolvió el mismo hash cada vez, sin importar la reputación de la IP ni la geografía. Solo cambiar la biblioteca TLS subyacente alteró el resultado. Esta es la parte honesta de la conversación: la calidad de la IP y la coincidencia de huellas resuelven dos problemas separados, y tratar uno como solución del otro lleva rápido a la decepción.

"El fingerprinting TLS ocurre antes de que llegue el primer byte HTTP. Cambiar una dirección IP no hace nada al saludo que hay por debajo." - notas de ingeniería de Insocks, agosto de 2026

• ❌ Una IP residencial no reescribe el orden de las suites de cifrado.
• ❌ Rotar proxies no afecta a los campos del saludo TLS.

Lo que cambia un proxy y lo que deja intacto

• ✅ Imitar la pila TLS de un navegador real es lo que realmente cambia la huella.

Cómo usan las huellas TLS los sistemas anti-bot

Los sistemas anti-bot calculan un hash a partir de cada ClientHello entrante y lo contrastan con bases de datos de huellas conocidas de navegadores y bots, luego combinan esa señal con otras capas antes de decidir un bloqueo, un desafío o dejar pasar. El fingerprinting TLS está por debajo de las cabeceras HTTP por completo, y por eso unas cabeceras perfectas junto a una pila TLS scriptada siguen siendo señaladas. Cloudflare documenta los campos JA3 y JA4 dentro de su producto de gestión de bots, y otros proveedores ejecutan comprobaciones comparables (Scrapfly, 2026). La puntuación mezcla señales TLS con el tiempo de las solicitudes, la reputación de la IP y datos conductuales en lugar de depender de un solo campo.

Algunos proveedores añaden fingerprinting http2 encima de la comprobación del saludo, leyendo cómo un cliente negocia las prioridades de flujo y los tamaños de ventana una vez que la capa TLS ha terminado. Esta segunda capa alimenta la puntuación más amplia de detección anti bot junto con el hash JA3 y JA4. Los proveedores mantienen estas bases de datos actualizadas conforme salen nuevas versiones de navegadores, y una huella que pasó el trimestre pasado puede empezar a fallar tras una actualización del navegador que cambie sus valores predeterminados.

Coherencia entre capas: TLS, HTTP/2, cabeceras e IP

La coherencia entre capas significa que el saludo TLS, la trama de ajustes http2, el User-Agent declarado y el tipo de red de la IP deben apuntar todos hacia la misma historia: un navegador real o un cliente real, no un mosaico de señales incoherentes. El fingerprinting Http2 examina cómo un cliente negocia las prioridades de flujo y los tamaños de ventana una vez completado el saludo, y es una segunda capa que algunos proveedores anti-bot comprueban junto con los datos JA3 y JA4 (Scrapfly, 2026). Un scraper que arregla su pila TLS pero ignora los ajustes de HTTP/2 todavía deja un hueco evidente.

Cuatro capas que expone una solicitud y lo que revela cada una

La coherencia del user agent también importa, ya que una cadena de User-Agent que declara Chrome 124 emparejada con un perfil JA4 desactualizado se lee como una contradicción por sí sola. Los proveedores anti-bot señalan exactamente este tipo de desajuste incluso cuando cada cabecera individual parece correcta. Ninguna de estas comprobaciones requiere evadir nada en el sitio objetivo; simplemente confirman que las señales propias de un cliente estén de acuerdo entre sí antes de que salga una solicitud.

Cómo probar tu propia huella TLS

Probar una huella empieza con una solicitud limpia a un endpoint de comprobación, y luego una comparación lado a lado con un navegador real que consulte el mismo endpoint. Una huella JA4 agrupa la versión de TLS, el número de suites de cifrado, el número de extensiones y el primer valor de ALPN en una cadena legible, lo que facilita la comparación visual frente a leer un hash en bruto (Scrapfly, herramienta de huellas JA3/JA4, 2026). Ejecutar la misma prueba dos veces en días diferentes también ayuda a confirmar que el resultado se mantiene estable entre actualizaciones de bibliotecas.

Herramientas creadas para esto, incluido el propio comprobador de Scrapfly y bibliotecas de terceros como curl impersonate, un nombre de herramienta usado aquí solo con fines de identificación, existen específicamente para hacer posible esta comparación sin adivinanzas. Un navegador headless ejecutando Playwright o Puppeteer también ofrece un saludo genuino para comparar, ya que lanza un motor de navegador real en lugar de una pila TLS scriptada.

• Paso 1. Enviar una solicitud desde el cliente bajo revisión a un endpoint de prueba de huellas y registrar el hash que devuelve.
• Paso 2. Abrir el mismo endpoint en un navegador real y actual y anotar su propio hash para comparar.
• Paso 3. Comparar las suites de cifrado, los números de extensiones y el valor de ALPN lado a lado en lugar de juzgar solo por la coincidencia del hash.
• Paso 4. Comprobar si la cabecera User-Agent declarada se corresponde con el perfil TLS observado realmente.
• Paso 5. Registrar el resultado con fecha, ya que el hash puede cambiar tras una actualización de biblioteca o de navegador.

👉 ¿Quieres ver cómo se comporta un cliente correctamente configurado de principio a fin?  Prueba una demo con Insocks antes de ejecutar un lote completo de pruebas.

Prácticas white-hat para una recopilación de datos estable

La recopilación de datos white-hat empieza por las reglas del propio sitio objetivo: primero las API oficiales, respetar robots.txt y mantener las tasas de solicitudes muy por debajo de cualquier cosa que pudiera saturar un servidor. Repasar qué es JA3 ayuda a explicar por qué los motores de navegador completos, no los trucos de cabeceras, tienden a producir los resultados más estables, ya que la pila TLS de un navegador real ya coincide con su propia identidad declarada por defecto. Playwright, Puppeteer y Selenium lanzan motores de navegador genuinos, de modo que su saludo se ve como Chrome o Firefox sin ninguna configuración adicional (Scrapfly, 2026).

Algunos equipos recurren a curl impersonate o bibliotecas similares cuando un navegador completo resulta demasiado pesado para la tarea en cuestión, y es un compromiso razonable siempre que la huella resultante se pruebe primero contra un navegador real. Combinar cualquiera de estos enfoques con tiempos sensatos y un User-Agent claro mantiene un proceso de recopilación predecible y fácil de auditar después.

• ✅ Usar API oficiales y endpoints documentados siempre que existan.
• ✅ Respetar robots.txt y los términos publicados del sitio objetivo.
• ✅ Espaciar las solicitudes en lugar de disparar ráfagas contra un solo endpoint.
• ✅ Preferir la automatización con navegador completo frente al spoofing fragmentado de cabeceras o TLS.
• 💡 Un calendario de recopilación más lento y constante suele provocar menos tickets de soporte que uno rápido y en ráfagas.

Al usar este enfoque desde Estados Unidos, un equipo confirma que su proceso de recopilación se mantiene dentro de la legislación estadounidense vigente y de los propios términos de servicio del sitio objetivo.

Errores comunes

Unos cuantos errores de proceso aparecen una y otra vez cuando los equipos revisan su propia configuración. Probar una sola vez y no repetir nunca la comprobación tras una actualización de biblioteca es el más común, ya que los resultados del fingerprinting TLS pueden cambiar en el momento en que una dependencia actualiza su backend TLS. Ejecutar la prueba en un entorno de staging que no coincide con producción es otro, porque lo que importa es la ruta real de la solicitud, no una shell local.

• ❌ Probar una sola vez y asumir que el resultado sigue siendo válido para siempre.
• ❌ Comprobar las huellas en un entorno distinto de donde la tarea se ejecuta realmente.
• ❌ Confiar en un único servicio de verificación sin un segundo punto de comparación.
• ❌ Ignorar los ajustes de HTTP/2 persiguiendo solo la capa TLS.

Cómo encaja la calidad del proxy en el panorama

Divulgación: Insocks es nuestro servicio, y esta sección describe lo que la infraestructura de proxies realmente hace dentro de una pila de recopilación más amplia. Una buena infraestructura de proxies resuelve los problemas de la capa de IP: geografía, reputación de la IP y estabilidad de conexión, mientras que el fingerprinting TLS sigue siendo una capa separada que un proxy por sí solo no puede tocar. La fiabilidad del uptime y los pools de IP limpios importan para evitar los límites de velocidad basados en IP, pero no dicen nada sobre el orden de las suites de cifrado ni sobre las listas de extensiones dentro de un saludo.

Para trabajos de recopilación vendemos proxies residenciales y proxies de IP estática, ambos con soporte de protocolos documentado y datos de ubicación. Combinar una infraestructura de proxies sólida con un cliente correctamente configurado, ya sea un motor de navegador completo o una biblioteca cuidadosamente ajustada, aborda ambas capas a la vez en lugar de dejar una expuesta.

Los proxies abordan la capa de red, no la huella TLS, y cualquier proveedor que sugiera lo contrario está sobrevendiendo lo que un cambio de IP puede hacer. Los equipos que necesitan ambas capas resueltas normalmente combinan una infraestructura de proxies de calidad, como los residenciales y los proxies ISP de Insocks, con un cliente basado en navegador o debidamente ajustado.

🔗 Regístrate para acceder con todas las funciones y comparar los pools de proxies antes de comprometerte con un plan.

Conclusiones clave

• El saludo TLS se lee antes que cualquier cabecera HTTP, y esa es toda la base de este método de detección.
• El hash sucesor de JA3 se mantiene estable incluso tras aleatorizar el orden de extensiones, a diferencia de su predecesor.
• Entender qué es JA3 aclara por qué los clientes tipo navegador superan las comprobaciones con más consistencia que los scriptados.
• Los proxies resuelven los problemas de IP; nunca reescriben por sí solos un saludo TLS.
• La automatización con navegador completo sigue siendo la vía más fiable para lograr una huella JA3 coherente y tipo navegador.

Divulgación y fuentes de datos

Todos los datos de este artículo, incluidos precios, niveles tarifarios, límites y disponibilidad de productos, son precisos a la fecha de publicación que figura en esta página. Los términos de los proveedores cambian con frecuencia y sin previo aviso, los niveles de entrada se mueven con el volumen, y puede aplicarse un precio promocional el día en que leas esto. Nada de lo aquí expuesto constituye una oferta, una garantía de términos vigentes ni una recomendación de compra.

Este artículo está publicado por Insocks. Vendemos proxies y declaramos un interés comercial en la sección final de arriba. Los proxies no cambian una huella JA3 ni ninguna otra señal TLS, y lo decimos directamente en lugar de insinuar lo contrario. Las herramientas y bibliotecas de prueba mencionadas aquí, incluido el comprobador de Scrapfly, curl-impersonate y los frameworks de automatización de navegadores, pertenecen a sus respectivos dueños y aparecen únicamente con fines de identificación. Los detalles de este artículo se verificaron en agosto de 2026, y el comportamiento de los clientes puede cambiar entre versiones de bibliotecas o de navegadores.

Preguntas frecuentes

Las preguntas a continuación cubren lo básico que la gente suele preguntar tras leer sobre este tema por primera vez. Las respuestas son breves y factuales, ajustándose a lo que una pestaña de navegador o una herramienta de línea de comandos mostraría realmente. Nada de esto sirve como guía de evasión, ya que el objetivo aquí es entender, no evadir.

¿Qué es una huella TLS?

Una firma corta construida a partir de los datos del saludo que identifica qué software realizó una conexión.

¿Cómo se calcula un hash JA3?

Cinco campos del saludo se combinan y se les aplica un hash para formar una cadena de 32 caracteres.

¿Cuál es la diferencia entre JA3 y JA4?

El método más reciente ordena las extensiones y usa un hash más fuerte, manteniéndose estable tras la aleatorización del orden en los navegadores.

¿Puede un proxy residencial ocultar mi huella TLS?

No, un proxy solo cambia la dirección IP; el saludo pasa sin cambios.

¿Por qué mi scraper es bloqueado con cabeceras correctas?

Las cabeceras se cargan después del saludo, así que un perfil de cliente incoherente es señalado primero.

¿Cómo compruebo mi propia huella TLS?

Envía una solicitud a una herramienta pública de comprobación y compárala con el resultado de un navegador real.