← Todos los artículos

Dentro del perfil del navegador: qué hace realmente `unblocker: true`

Un flag activa tres elementos: headers reales de navegador, una firma de conexión que coincide y autodescompresión para gzip y brotli. Esto es lo que hace y el porqué.

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

El servidor analiza la firma a nivel de conexión que tu cliente envía por la red y decide si eres un navegador o una librería cliente simulando serlo. Python requests, net/http de Go, curl simple: todos entregan una huella digital distintiva en el momento en que inician la conexión. Los sitios que controlan esto (Datadome, Akamai, Imperva, la parte administrada de Cloudflare) cierran la conexión o te muestran una página de desafío antes de que tu User-Agent llegue a importar.

Eso es lo que unblocker: true resuelve en FourA. En el último mes, ajustamos los componentes necesarios para que funcione de forma confiable.

Novedades

unblocker: true es un flag único en cualquier llamada a /api/single. Al activarlo, hacemos tres cosas: inyectamos el conjunto de headers del navegador, enviamos el request a través de un transporte que coincide con lo que un navegador real envía por la red y descomprimimos lo que el servidor devuelva (gzip, brotli, deflate). Las dos primeras opciones están disponibles desde la fase beta. La tercera (autodescompresión de brotli) se lanzó el 25 de marzo, y el ajuste de versiones se implementó al día siguiente para mantener los headers y el transporte sincronizados.

Cómo funciona

Así es como se ve un 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 paquete 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 verifican esto.

Firma de conexión. Nuestro transporte replica la estructura a nivel de bytes de una sesión de navegador actualizada: el mismo orden de extensiones, las mismas preferencias de cifrado, las mismas particularidades en el handshake. Las herramientas estándar como curl, Python requests y net/http de Go generan firmas que la infraestructura protegida detecta automáticamente en milisegundos.

Descompresión automática. Cuando unblocker está activado, configuramos Accept-Encoding en gzip, deflate, br y el transporte descomprime el cuerpo. Recibes un string decodificado (o un Buffer si pasas returnBuffer: true). Sin gestión manual de brotli y sin discrepancias entre headers y cuerpo cuando un sitio elige deflate en lugar de gzip.

Por qué importa fijar las versiones

Las firmas de conexión están ligadas a versiones específicas. Los detalles a nivel de red de un navegador este mes no son los mismos del mes pasado, y un sitio que analiza fingerprints con precisión notará la discrepancia. Fijamos las partes móviles en conjunto para que los headers, los objetos navigator y la firma de conexión reporten exactamente la misma versión del navegador.

Si esto parece tedioso, es porque lo es. Tuvimos problemas por un desajuste durante la migración del monorepo en marzo, cuando un componente se actualizó automáticamente y el resto quedó desincronizado. La solución requirió dos commits: fijar la pieza móvil y no confiar nunca en que el gestor de paquetes mantenga todo alineado por ti.

Impacto

En pruebas internas contra sitios que verifican el origen de la solicitud (finanzas, viajes, grandes plataformas de e-commerce), la diferencia entre unblocker: false y unblocker: true es la diferencia entre una página de verificación y un 200. Un cliente HTTP convencional suele recibir un 403 al primer intento. La misma URL con unblocker: true obtiene la página, porque la solicitud coincide con el navegador que describe.

Sin embargo, para sitios que no analizan fingerprints (la mayoría de las APIs públicas, plantillas CMS antiguas, cualquier servicio protegido solo por rate limits de IP), dejar unblocker desactivado funciona bien y ahorra unos milisegundos de negociación. Úsalo donde lo necesites.

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 junto con una firma de conexión perfecta siguen alertando a los sistemas en ASNs que el sitio tiene en listas negras. Nuestro endpoint de proxy (/api/proxy) rota según el dominio de destino, por lo que añadir "proxy": "residential" a la solicitud suele ser suficiente.

Omite unblocker cuando llames a APIs JSON que no esperan navegadores. Los headers adicionales pueden parecer sospechosos para una API diseñada para clientes programáticos, como un backend que consume su propio microservicio.

Si el sitio verifica al visitante con JavaScript antes de mostrar la página, unblocker por sí solo no será suficiente. Necesitas el endpoint de navegador, que ejecuta el JavaScript de la página en un navegador completo. Ese es un producto diferente con otro precio en créditos, y lo explicamos en Tareas de navegador: cómo extraer datos de sitios con alto uso de JavaScript.

Y puedes combinar unblocker con el bloque validate para rechazar respuestas que técnicamente devuelven 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 fundamental 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. Actualizamos nuestro stack para mantenernos al día. No tienes que modificar nada por tu parte: unblocker: true sigue apuntando a la versión de navegador que hayamos verificado de extremo a extremo.

El trabajo más complejo está por delante. Las comprobaciones de HTTP/3 ya están apareciendo en sitios más grandes, el transporte QUIC es más difícil de emular que el transporte anterior, y la migración desde paquetes de headers estáticos hacia una emulación verdaderamente dinámica está comenzando. Los sitios protegidos han empezado a verificar el orden de los frames de HTTP/2, y la brecha entre una "biblioteca que parece un navegador" y "un navegador" se irá reduciendo por ambos lados. Escribiremos sobre esto cuando lo lancemos.