Todos los artículos

Dentro de Web Unblocker: Qué hace realmente el flag Unblocker

Un solo flag activa tres funciones: headers de navegador reales, un TLS fingerprint coincidente y descompresión automática para gzip y brotli. Esto es lo que cambió y por qué.

La mayoría de los scrapers fallan antes de que se lea un solo header.

El servidor analiza el TLS handshake (orden de cipher suites, orden de extensiones, preferencias de curvas) y decide si eres un navegador o una librería de cliente que intenta imitarlo. Python requests, net/http de Go, curl básico: todos ellos entregan un fingerprint distintivo en el momento en que saludan. Los sitios que se preocupan por esto (Datadome, Akamai, Imperva, la parte gestionada de Cloudflare) cortan la conexión o te muestran una página de desafío antes de que tu cadena User-Agent llegue a importar.

Eso es lo que resuelve unblocker: true en FourA. En el último mes, ajustamos las piezas que hacen que funcione de manera confiable.

Novedades

unblocker: true es un único flag en cualquier llamada a /api/single. Actívalo y haremos tres cosas: inyectar el conjunto de headers del navegador, enviar la request a través de curl-impersonate con un TLS fingerprint de un navegador real y descomprimir lo que devuelva el servidor (gzip, brotli, deflate). Las dos primeras han estado disponibles desde la beta. La tercera (descompresión automática de brotli) se lanzó el 25 de marzo, y el trabajo de pinning de la versión del navegador llegó al día siguiente para mantener los headers y TLS sincronizados.

Cómo funciona

Así es como se ve una request:

curl -X POST "https://api.foura.ai/api/single" \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "url": "https://example.com/products",
    "method": "GET",
    "unblocker": true
  }'

Tres capas se ejecutan por debajo.

Inyección de headers. Configuramos el conjunto completo de headers del navegador: User-Agent, Sec-Ch-Ua, Sec-Ch-Ua-Platform, Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Accept, Accept-Language y Accept-Encoding. El orden importa. Los navegadores reales los emiten en una secuencia específica, y las librerías de detección la verifican.

TLS fingerprint. curl-impersonate 0.8.2 compila libcurl contra BoringSSL y reordena las extensiones TLS para que coincidan con lo que la versión del navegador de destino realmente envía por la red. Tus hashes JA3 y JA4 resultan idénticos a los de una sesión de navegador real. curl estándar, Python requests y net/http de Go producen fingerprints que son detectados automáticamente en milisegundos en infraestructuras protegidas.

Descompresión automática. Cuando unblocker está activo, configuramos Accept-Encoding como gzip, deflate, br y dejamos que libcurl desempaquete el body. Recibes una cadena decodificada (o un Buffer si pasas returnBuffer: true). Sin gestión manual de brotli, sin discrepancias entre headers y body cuando un sitio elige deflate en lugar de gzip.

Por qué importa el pinning de versiones

Los TLS fingerprints están bloqueados por versión. El orden de cifrado de un navegador este mes no es el del mes pasado, y un sitio que analiza los fingerprints con cuidado notará la desviación. curl-impersonate distribuye perfiles para compilaciones de navegadores específicas, y nosotros vinculamos nuestro binario de navegador real a cualquier compilación a la que apunte actualmente curl-impersonate. Los headers, los objetos navigator y TLS reportan la misma versión.

Si eso suena complicado, lo es. Nos vimos afectados por una discrepancia durante la migración del monorepo en marzo, cuando el navegador se actualizó automáticamente y los headers se desincronizaron de curl-impersonate. La solución fueron dos commits: fijar el binario del navegador y nunca confiar en que el gestor de paquetes los mantenga alineados por ti.

Impacto

En pruebas internas contra objetivos con un fuerte análisis de fingerprints (finanzas, viajes, comercio electrónico protegido), la diferencia entre unblocker: false y unblocker: true es la diferencia entre una página de desafío y un 200. curl básico atacando a un Cloudflare gestionado termina en un 403 al primer intento. La misma URL con unblocker: true pasa porque el TLS hello parece un handshake de un navegador real.

But for sites that don't fingerprint (most public APIs, older CMS templates, anything gated only on IP rate limits), leaving unblocker off is fine and saves a few milliseconds of TLS negotiation. Use it where you need it.

Para usuarios avanzados

Algunos patrones que vale la pena conocer.

Combina unblocker con un proxy residencial cuando el objetivo también verifique la reputación de la IP. Las IPs de centros de datos sumadas a un TLS handshake perfecto seguirán siendo detectadas en los ASNs que el sitio tiene en su lista negra. Nuestro endpoint de proxy (/api/proxy) rota por dominio de destino, por lo que añadir "proxy": "residential" a la request suele ser suficiente.

Omite unblocker al llamar a APIs JSON que no se preocupan por los navegadores. Los headers adicionales pueden parecer sospechosos para una API que espera un cliente programático, por ejemplo, un backend que llama a su propio microservicio.

Si el sitio ejecuta medidas anti-bot de JavaScript (desafíos interactivos de Turnstile, Perimeter X en su modo más estricto, Akamai Bot Manager con la heurística al máximo), unblocker por sí solo no será suficiente. Necesitas el endpoint del navegador, que ejecuta Chromium real y puede resolver el desafío. Ese es un producto diferente con un precio de créditos distinto, y lo detallamos en Browser Tasks: Cómo scrapear sitios con alta carga de JavaScript.

Y puedes combinar unblocker con el bloque validate para rechazar responses que técnicamente devuelven un 200 pero contienen una página de desafío:

{
  "url": "https://example.com/products",
  "method": "GET",
  "unblocker": true,
  "validate": {
    "data": { "fail": ["captcha", "Access Denied"] }
  }
}

Eso convierte los fallos silenciosos en fallos clasificados, lo cual es importante para el seguimiento de tu tasa de éxito en el dashboard.

Próximos pasos

Los navegadores lanzan una nueva versión estable cada cuatro semanas. El mantenedor de curl-impersonate suele ponerse al día un mes después, y nosotros actualizamos nuestro stack cuando ellos lo hacen. No necesitas tocar nada por tu parte: unblocker: true sigue apuntando a cualquier versión de navegador que hayamos verificado de extremo a extremo.

El trabajo más difícil está por delante. El fingerprinting de HTTP/3 ya está apareciendo en sistemas anti-bot gestionados, el transporte QUIC es más difícil de suplantar que TLS 1.3 y la migración de conjuntos de headers estáticos hacia una emulación verdaderamente dinámica está comenzando. Los sitios protegidos han pasado a verificar el orden de los frames de HTTP/2 y las variantes de JA4+, y la brecha entre "un curl que parece un navegador" y "un navegador" se va a reducir por ambos extremos. Escribiremos sobre ello cuando lo lancemos.