Lo has hecho todo bien. Una IP residencial limpia, un User-Agent de Chrome real, cabeceras creíbles, límites de ritmo sensatos. Y un destino fuertemente protegido aún te bloquea al instante, a veces antes de enviar un solo byte de la página real. Es tentador culpar a la IP y rotar, pero rotar no ayuda, y ese es el indicio. Te están haciendo fingerprint en una capa en la que la mayoría de los scrapers nunca piensa: el propio cliente HTTP, en el handshake TLS y la conexión HTTP/2, antes de que tu petición siquiera se lea.
Esta es la tercera capa de identidad, separada de tu IP y separada de la huella de navegador y dispositivo que un navegador antidetección maneja. Entenderla es lo que separa un scraper que funciona en sitios fáciles de uno que funciona en los difíciles.
Tres capas, no una
Cuando un sitio decide si eres un usuario real, mira tres cosas independientes:
- La capa de red: tu dirección IP y su reputación. Una IP de datacenter o una marcada falla aquí.
- La capa de cliente: cómo tu cliente HTTP abre la conexión, su handshake TLS y su comportamiento HTTP/2. Una librería de scripting falla aquí incluso desde una IP perfecta.
- La capa de dispositivo: la huella de navegador, canvas, fuentes,
navigator, etc. Un navegador automatizado puede fallar aquí.
Una IP residencial limpia resuelve la primera capa y nada más. Si tu handshake TLS anuncia “soy Python”, ninguna IP del mundo te hace parecer humano. Por eso los destinos más difíciles te bloquean antes de que la página cargue: rechazan la conexión en la capa de cliente, y la IP nunca llega a importar.
Fingerprinting de TLS, o JA3
Toda conexión HTTPS empieza con un handshake TLS, y el primer mensaje, el ClientHello, es sorprendentemente revelador. En él, el cliente lista las suites de cifrado exactas que soporta, en un orden específico, junto con sus extensiones TLS, curvas elípticas soportadas, algoritmos de firma, y más. Esa combinación es característica del software que hace la conexión, y es notablemente estable.
Chrome produce un ClientHello distintivo. Firefox produce otro. El requests de Python, que usa el OpenSSL del sistema, produce uno que no se parece a ninguno. El net/http de Go produce el suyo. Los proveedores anti-bot hashean estos valores en una huella compacta, los formatos conocidos son JA3 y su sucesor JA4, y mantienen una imagen de a qué se parecen los navegadores reales. Cuando tu ClientHello hashea a algo que es obviamente una librería de scripting y no un navegador, quedas marcado en el handshake, antes de haber enviado una línea de petición, una cabecera, o una cookie.
La parte cruel es la contradicción que expone. Pones User-Agent: Chrome, pero tu huella TLS dice OpenSSL-vía-Python. Un Chrome real nunca produciría esa combinación, así que el desajuste no es solo un disfraz fallido, es una señal positiva de que algo está fingiendo. Estás peor que si no hubieras enviado ningún User-Agent.
Fingerprinting de HTTP/2
Supón que tu huella TLS es convincente. Hay otra capa justo detrás. Los navegadores reales hablan HTTP/2, y cómo lo hablan también es una huella. Cuando se abre una conexión HTTP/2, el cliente envía un frame SETTINGS con valores particulares (tamaño de la tabla de cabeceras, máx. de streams concurrentes, tamaño de ventana inicial), anuncia una actualización de ventana específica, y ordena sus pseudo-cabeceras (:method, :authority, :scheme, :path) de forma característica. Los navegadores incluso envían información de prioridad de stream en un patrón reconocible.
Las librerías de cliente HTTP se equivocan en estos detalles de formas reveladoras, o caen a HTTP/1.1 por completo, lo cual en un sitio moderno es de por sí sospechoso. Así que un scraper puede pasar el chequeo de TLS y aun así ser pillado una capa más arriba, porque sus SETTINGS de HTTP/2 y su orden de cabeceras no coinciden con ningún navegador real. Y en HTTP/1.1 plano, el orden y las mayúsculas de tus cabeceras son una huella más: los navegadores envían las cabeceras en un orden consistente que la mayoría de las librerías no reproduce.
Por qué poner cabeceras no lo arregla
La razón por la que esto es tan persistente es que nada de ello vive en los valores que puedes fijar. Puedes falsear un User-Agent, añadir un Accept-Language, copiar la lista de cabeceras de un navegador exactamente, y aun así ser pillado, porque la huella es una propiedad de cómo se hace la conexión, no de qué pones en la petición. El orden de cifrados en tu ClientHello, los SETTINGS de HTTP/2 que tu librería emite, la secuencia en que las cabeceras llegan al cable, esto lo decide tu stack de TLS y HTTP, no tu código. No puedes salir de un desajuste de JA3 a base de cabeceras.
Cómo parecer un navegador real en la capa de red
Hay dos formas honestas de presentar una huella de cliente a nivel de navegador.
Usa un navegador real. Playwright, Puppeteer o Selenium manejan Chromium real, así que sus huellas TLS y HTTP/2 son, por definición, las de un navegador real. Para los destinos protegidos de forma más agresiva esta es la ruta más robusta, a costa de correr un navegador por worker.
Usa un cliente HTTP que impersona TLS. Cuando quieres seguir ligero, existe una clase de clientes específicamente para imitar el ClientHello y los settings HTTP/2 de un navegador manteniéndose como una simple llamada HTTP. Herramientas como curl-impersonate y su binding de Python curl_cffi, tls-client, y el utls de Go te dejan enviar una petición que hace fingerprint como Chrome o Firefox sin lanzar uno.
from curl_cffi import requests
# Presenta una huella TLS + HTTP/2 de Chrome real, no la de python-requests.r = requests.get( "https://example.com", impersonate="chrome", proxies={"https": "http://customer-USER-country-us:PASS@p.shifter.io:443"},)print(r.status_code)Ese único argumento impersonate es la diferencia entre un ClientHello que dice Chrome y uno que dice OpenSSL. Emparejado con una IP residencial limpia, pasa la capa de red y la de cliente a la vez, que es lo que los destinos difíciles están comprobando.
Mantén cada capa consistente
El hilo conductor es la consistencia. Tu historia tiene que concordar a través de las tres capas: un User-Agent de Chrome necesita una huella TLS de Chrome, settings HTTP/2 de Chrome, y orden de cabeceras de Chrome, saliendo por una IP cuya geografía coincida con el locale que reclamas. Los sistemas anti-bot cada vez puntúan más el acuerdo entre estas señales, no cada una en aislamiento, así que una sola contradicción, un UA de navegador sobre un handshake de librería, una persona de EE. UU. sobre una IP extranjera, es una señal más ruidosa que cualquier capa estando ligeramente mal. Este es el mismo principio de coherencia detrás de los errores que disparan la detección: cada capa tiene que contar la misma historia.
Diagnosticar un bloqueo de huella de cliente
Normalmente puedes distinguir un bloqueo de capa de cliente de uno de capa de IP por cómo se comporta. Si te bloquean al instante, en un sitio conocido por su protección agresiva, y rotar IPs no cambia nada pero cambiar a un navegador real de repente funciona, eso es un bloqueo de huella de cliente, no un problema de IP. A la inversa, si un cliente HTTP plano funciona bien la mayor parte del tiempo y solo algunas IPs reciben desafíos, eso apunta de vuelta a la reputación de IP. Saber qué capa falló te dice qué palanca tirar, en lugar de rotar IPs contra un problema que no tiene nada que ver con la IP. Esta es la misma disciplina de “lee bien el fallo” que diagnosticar por qué las peticiones hacen timeout y detectar un bloqueo silencioso.
En resumen
Los sitios fuertemente protegidos te juzgan en tres capas, y una IP limpia solo responde una de ellas. La capa de cliente, tu handshake TLS y tu comportamiento HTTP/2, hace que las librerías de scripting queden bloqueadas antes de que sus peticiones siquiera se lean, y ninguna cantidad de falseo de cabeceras lo arregla, porque la huella está en cómo se hace la conexión. Para scrapear los destinos difíciles con una tasa de éxito alta, presenta una huella de cliente a nivel de navegador, ya sea manejando un navegador real o usando un cliente que impersona TLS, y mantenla consistente con tus cabeceras y la geografía de tu IP.
Una IP residencial limpia sigue siendo necesaria, es la capa que te pasa la reputación, pero en los sitios más duros no es suficiente por sí sola. Emparéjala con una huella de navegador real en la capa de red y cada señal alineada, y el bloqueo que solía golpear antes de que la página siquiera cargara deja de ocurrir. El precio por GB te deja probar esa combinación contra tus propios destinos más duros sin un medidor por petición peleando contigo.