Dos presentaciones antes de que corra ningún script
Todo lo que se escribe sobre fingerprinting del navegador trata de cosas que una página puede medir: canvas, WebGL, fuentes, tamaño de pantalla. Todo eso ocurre una vez establecida la conexión.
A esas alturas tu cliente ya ha hecho dos declaraciones sobre sí mismo que no puede retirar. El ClientHello de TLS anuncia qué suites de cifrado, extensiones, curvas elípticas y protocolos ALPN admite, y en qué orden. El preámbulo de HTTP/2 anuncia los valores de su trama SETTINGS, su tamaño de actualización de ventana y el orden en que envía los pseudocampos de cabecera.
Ninguna de las dos es una afirmación de identidad. Ambas son consecuencia de qué biblioteca TLS y qué pila HTTP se compilaron en el binario. Y eso es justo lo que las hace útiles para un proveedor de detección: una cadena de user agent es una frase que cualquiera puede teclear; un ClientHello es una estructura de la que tienes que estar hecho de verdad.
JA3, y por qué Chrome lo rompió
JA3, publicado por Salesforce en 2017, toma cinco campos del ClientHello — versión TLS, suites de cifrado, extensiones, curvas elípticas y formatos de curva —, los concatena en el orden en que viajan y les aplica MD5. El resultado es un hash de 32 caracteres estable para una build de cliente dada.
Funcionó bien seis años, y entonces Chrome lo mató. En Chrome 110, lanzado en enero de 2023, Google empezó a aleatorizar el orden de las extensiones TLS en cada conexión, explícitamente como medida contra la osificación y contra el fingerprinting. Como JA3 hashea la lista de extensiones en el orden de envío, un orden aleatorio produce un hash distinto cada vez. Chrome pasó de un JA3 a JA3 prácticamente ilimitados de la noche a la mañana.
Eso tuvo una consecuencia que a nadie en el mundo antidetect le gustaba señalar: durante un tiempo, un JA3 estable era en sí mismo sospechoso, porque el Chrome de verdad ya no tenía uno.
JA4 y la familia JA4+
JA4, publicado por FoxIO en 2023, arregla el problema del orden de la forma obvia: ordena los cifrados y las extensiones antes de hashear. Aleatoriza el orden de envío cuanto quieras; la lista ordenada es la misma, así que el fingerprint vuelve a ser estable.
Además es legible en lugar de opaco. Un JA4 es una cadena de 36 caracteres en tres partes, y la primera se lee a simple vista: protocolo y versión TLS, presencia de SNI, número de cifrados y extensiones y el valor ALPN. Puedes mirar un JA4 y ver que un cliente ofreció 15 cifrados sobre TLS 1.3 con h2 negociado, antes siquiera de buscar el hash.
JA4 es el ancla de una familia más amplia, y dos parientes importan aquí:
- JA4H toma la huella de la propia petición HTTP: método, versión, nombres de cabecera en orden, presencia de cookies y el valor de
Accept-Language. Pilla al cliente cuyas cabeceras no cuadran con el navegador que dice ser. - JA4L mide la latencia entre pasos del handshake. Es el más difícil del conjunto de falsificar, porque no es un valor que emitas: es el tiempo físico que tarda tu pila en responder, y un intermediario que termina y rehace el TLS lo cambia quieras o no.
A fecha de 2026, JA4 está en producción en Cloudflare, Akamai y AWS WAF, entre otros. Trátalo como desplegado universalmente, no como una técnica emergente.
HTTP/2: el fingerprint de Akamai
HTTP/2 revela tanto como TLS, y quienes intentan pasar desapercibidos lo revisan menos.
El formato más usado es el de Akamai, y tiene cuatro partes unidas por barras verticales:
- Trama SETTINGS — los parámetros que envía el cliente y sus valores, en orden. Chrome, Firefox y Safari envían cada uno un conjunto distinto. Y cada biblioteca HTTP también.
- WINDOW_UPDATE — el incremento inicial de ventana a nivel de conexión.
- Tramas de prioridad — si el cliente las envía y cómo estructura el árbol.
- Orden de las pseudocabeceras — la secuencia de
:method,:authority,:scheme,:path. Chrome usam,a,s,p. Casi ninguna biblioteca lo hace.
Ese último punto es de una eficacia casi cómica. La especificación de HTTP/2 no impone un orden, así que cada implementación eligió el suyo y nunca lo cambió. Una petición que dice ser Chrome y manda sus pseudocabeceras en otra secuencia se ha contradicho antes de que el servidor lea una sola cabecera real.
Por qué no puedes arreglar esto desde la interfaz del navegador
Esta es la parte en la que conviene ser directo, porque va contra buena parte del marketing — incluido, para ser justos, el de este sector en general.
Los ajustes de fingerprint de tu navegador antidetect — modo canvas, fabricante de WebGL, zona horaria, fuentes — actúan dentro del renderizador. El handshake TLS ocurre en la pila de red, en otro proceso, antes de que el renderizador entre en juego. No hay ajuste que lo cambie, porque en el perfil no hay nada que cambiar: el handshake lo produce BoringSSL tal como está compilado en el binario.
Lo que lleva a la única noticia realmente buena de este artículo: si estás conduciendo una build real de Chromium, tus fingerprints de TLS y HTTP/2 ya son los de Chrome. Puppeteer sobre Chrome real, Playwright sobre Chrome real y cualquier navegador antidetect basado en Chromium presentan el mismo handshake que el Chrome de tu escritorio, porque es el mismo código. Los flags de automatización no lo cambian.
Los clientes que caen en esta capa son los que no son navegadores en absoluto: requests, axios, httpx, el net/http de Go, curl. Ponen un user agent de Chrome y luego entregan un ClientHello que ningún Chrome ha producido jamás. Ese es el desajuste que JA4 se construyó para pillar.
Qué le hacen los proxies al handshake
La elección de proxy importa aquí, y es una distinción que casi todas las guías se equivocan.
| Tipo de proxy | Efecto sobre el fingerprint TLS |
|---|---|
| SOCKS5 | Ninguno. Reenvía los bytes TCP sin tocarlos; tu ClientHello llega intacto al servidor. |
| HTTP CONNECT | Ninguno. Abre un túnel; TLS se negocia de extremo a extremo a través de él. |
| MITM / que termina TLS | Total. El proxy hace su propio handshake, así que el servidor ve su fingerprint, no el tuyo. |
El modo de fallo es la última fila, y no siempre es algo que hayas elegido. Los equipos corporativos de inspección, algunos servicios proxy «que optimizan SSL» y cualquier herramienta local de depuración de la familia Charles o Fiddler terminan TLS. Si el fingerprint de un navegador de pronto sale exótico, busca un interceptor antes que ninguna otra cosa.
Conviene añadir: JA4L hace parcialmente visible incluso a un proxy transparente, porque el salto extra cuesta tiempo. Eso no se configura y desaparece. Es un motivo para preferir un proxy geográficamente cercano a la salida que dices tener, en lugar de uno enrutado por tres continentes.
Flags que importan y flags que no
Una pregunta recurrente es si los flags de arranque de Chrome cambian el handshake. Casi nunca, y las excepciones conviene conocerlas.
Sin efecto sobre TLS: --headless, --no-sandbox, --disable-gpu, --disable-dev-shm-usage, el dimensionado de la ventana y toda la familia de flags del renderizador. Cambian cómo se dibujan las páginas y cómo se aísla el proceso, no cómo saluda BoringSSL a un servidor.
Efecto real: --disable-http2 fuerza una bajada a HTTP/1.1, lo que elimina el fingerprint de HTTP/2 y lo sustituye por algo más raro y por tanto más llamativo — un Chrome moderno que rechaza h2 es inusual. --ssl-version-min y afines alteran directamente lo que se ofrece en el ClientHello. Las opciones que desactivan QUIC cambian qué protocolos se intentan y en qué orden.
La regla general: si un flag suena a que toca la pila de red, asume que cambia tu fingerprint y verifícalo antes de ponerlo en producción.
Cómo comprobar el tuyo
Tres endpoints públicos te dicen dónde estás en menos de un minuto:
- tls.peet.ws/api/all — devuelve tu JA3, tu JA4, el fingerprint HTTP/2 completo en formato Akamai y el orden de tus cabeceras, en JSON. La vista única más completa.
- browserleaks.com/tls — el mismo terreno con una presentación más amable.
- scrapfly.io/web-scraping-tools/ja3-fingerprint — útil para comparar un cliente con firmas de navegador conocidas.
La prueba que de verdad importa requiere dos ventanas. Abre una de esas URLs en tu Chrome de escritorio de siempre, y luego ábrela otra vez con la herramienta que estás evaluando. Compara el JA4 y el fingerprint HTTP/2 campo por campo. Si coinciden, esta capa no es tu problema y deberías dedicar la atención a la superficie de CDP y a si tu fingerprint se sostiene. Si difieren, ninguna cantidad de ajustes de canvas te va a ayudar.