Huella TLS (JA3)
Una firma derivada de cómo un cliente negocia un handshake TLS, usada para identificar el software que hace la solicitud - a menudo mediante el hash JA3.
Una huella TLS identifica el software detrás de una conexión por la forma específica en que negocia el handshake TLS (HTTPS). La lista de suites de cifrado, extensiones y parámetros que ofrece un cliente es característica de la librería o el navegador que usa. JA3 es un método popular que hashea esos valores en una firma corta que representa al cliente.
Es potente para detectar bots porque opera por debajo de la capa de aplicación. Puedes poner un user-agent de navegador perfecto y cabeceras limpias, pero si tu librería HTTP negocia el TLS de forma distinta a un Chrome real, la huella JA3 te delata. Chrome, Firefox y Safari reales tienen huellas TLS reconocibles; requests de Python y net/http de Go tienen las suyas, obviamente no de navegador.
Los sistemas antibot mantienen bases de datos de huellas de navegador conocidas como buenas y huellas de automatización conocidas como malas. Una solicitud cuya huella TLS no coincide con su user-agent declarado -cabecera de Chrome, handshake no-Chrome- se marca como falsificada, a menudo antes de que el sitio devuelva contenido.
Vencer el fingerprinting TLS requiere herramientas que imiten el handshake de un navegador real - curl-impersonate, librerías TLS especializadas o navegadores completos. Combinado con proxies residenciales y cabeceras coincidentes, una huella TLS precisa de navegador es a menudo lo que separa a los scrapers que pasan de los que se bloquean.
A hash of how your client says hello
Every TLS connection opens with a Client Hello, and that message carries a lot more than the hostname. It lists the cipher suites the client supports, the extensions it offers, the elliptic curves it knows and the formats it accepts, all in a specific order. That order is decided by the library, not by the user.
JA3 takes those fields, concatenates them and hashes the result. The output is a short string that identifies the client software rather than the person using it. Chrome on Windows produces one value, Firefox another, Python requests another, Go another. Two people using the same Chrome build produce the same JA3, which is the point: it identifies software, not identity.
For a defender this is close to free. It requires no JavaScript, no cookies and no waiting: the hash is available from the first packet, before your request is even parsed. That is why so many blocks land instantly on a client that has done nothing yet.
JA4 is the newer version of the same idea, harder to spoof by shuffling and more granular. The practical consequence is unchanged: your HTTP library announces what it is before it says what it wants.
What a proxy can and cannot do here
Our proxies move your traffic. They do not rewrite your TLS handshake, and no honest provider can claim otherwise:
Where the fingerprint comes from
requests / httpx / aiohttp -> Python TLS fingerprint, easily spotted
Go net/http -> Go fingerprint
curl -> curl fingerprint
curl-impersonate -> imitates a real browser build
Playwright / Puppeteer -> a real browser, so a real fingerprint
antidetect browsers -> real browser plus profile isolation- If a site blocks you instantly on a residential address but a browser on the same address works, the address was never the problem.
- For scraping protected targets, run a real browser or an impersonation library. Changing the User-Agent on a Python client does nothing about the handshake.
- Fingerprints follow browser versions. An impersonation library pinned to an old Chrome release becomes conspicuous once that build disappears from the wild.
- For account work use an antidetect browser. It gives you a genuine handshake plus separated cookies and storage, which the proxy alone cannot provide.
What JA3 does not tell a site
It does not identify you
Millions of people share a Chrome fingerprint. It identifies the software, which is exactly why an unusual one stands out.
It is not fixed by a proxy
The handshake is made by your client and passes through us unchanged. Any provider promising to hide it is describing something else.
It is not defeated by rotating addresses
The same fingerprint arriving from a hundred addresses looks like one tool with a hundred addresses, which is worse than one address.
Matching a browser is not enough on its own
Header order, HTTP/2 settings and behaviour have to agree with the handshake, or you have simply moved the contradiction one layer up.
Términos relacionados
Ver esto en práctica
¿Listo para usar huella tls (ja3)?
SotaProxy te da acceso a proxies residenciales rotativos, móviles, de centro de datos e ISP. Sin compromiso mínimo.
Empezar