Un sistema anti-bot es un software que se sitúa delante de un sitio web y estima, para cada solicitud, la probabilidad de que provenga de automatización en lugar de una persona, y actúa en consecuencia: la deja pasar, la ralentiza, la desafía o la bloquea. La estimación no se basa en un único dato. Es una puntuación compuesta por cuatro capas: de dónde proviene la solicitud (IP), cómo se estableció la conexión (huellas TLS y HTTP), qué revela el navegador sobre sí mismo (huella de JavaScript) y qué hace el visitante a lo largo del tiempo (comportamiento). Entender las capas explica las dos cosas que más confunden a los usuarios de proxies: por qué una IP residencial "perfecta" sigue siendo desafiada, y por qué la misma configuración funciona en un sitio y falla en otro.

Los proveedores y los productos

La mayoría de los sitios protegidos utilizan uno de estos productos: Cloudflare Bot Management (y su desafío Turnstile), DataDome, Akamai Bot Manager, HUMAN (antes PerimeterX), Imperva (Incapsula), Kasada y AWS WAF Bot Control. Difieren en su énfasis y en lo agresivos que son sus valores predeterminados, pero se basan en las mismas cuatro capas, y las capas son el tema de este artículo. Todo lo siguiente se aplica a todos ellos en alguna proporción.

Capa 1: Reputación de IP

La primera y más económica comprobación. Antes de que la solicitud se analice, se consulta la IP:

  • ASN y tipo — ¿es una empresa de hosting (centro de datos), un ISP de consumo (residencial) o un operador móvil? Los ASN de hosting comienzan con una penalización en la mayoría de los sitios; el razonamiento se explica en Residencial vs centro de datos vs móvil.
  • Inteligencia de amenazas — ¿está la IP en listas de abuso, se sabe que es una salida de VPN/proxy, o se ha visto atacando a otros clientes del mismo proveedor? Los proveedores agrupan señales de toda su base de clientes, por lo que una IP quemada en un sitio protegido por DataDome es sospechosa en todos ellos.
  • Velocidad — ¿cuántas solicitudes ha hecho esta IP a este sitio recientemente, y a cuántas rutas diferentes? Un contador por IP es la señal de bot más antigua que existe y sigue siendo una de las más efectivas.
  • Geografía — ¿coincide el país con la audiencia del sitio? ¿Coincide con el idioma y la zona horaria que el navegador informará más tarde?

Esta es la única capa que un proxy controla directamente. Una IP residencial o móvil sin historial en el objetivo la supera. Pero pasar la capa 1 solo significa que la solicitud procede a las capas 2–4 con una puntuación neutral, no buena.

Capa 2: Huellas de red (TLS, HTTP/2, TCP)

Antes de que se sirva cualquier contenido de página, el servidor ya ha visto cómo se abrió la conexión, y la forma en que se abrió identifica el software del cliente:

  • Huella TLS (JA3/JA4) — el ClientHello revela la biblioteca TLS: Chrome, Firefox, OpenSSL-en-Python, Go. Explicado en Huella TLS.
  • Huella HTTP/2 — los valores del marco SETTINGS, el tamaño inicial de la ventana, los marcos de prioridad y el orden de los encabezados y pseudo-encabezados. Los navegadores tienen patrones característicos y estables; las bibliotecas HTTP tienen otros diferentes. La investigación de Akamai hizo famosa esta técnica.
  • Huella TCP/IP — tamaño de ventana, TTL, opciones; distingue sistemas operativos, y un User-Agent de "Windows" con una pila TCP de Linux es una discrepancia.

La lógica de puntuación aquí es la coherencia: ¿la identidad a nivel de red coincide con lo que afirman los encabezados HTTP? Un proxy no toca estas huellas — las reenvía — por lo que un script detrás de una IP residencial es identificado como script en esta capa independientemente de la calidad de la IP. Aquí es donde se responden la mayoría de las preguntas de "¿por qué mi proxy limpio está bloqueado?".

Capa 3: Huella del navegador y desafíos de JavaScript

Si la solicitud llega al punto de servir HTML, el JavaScript del proveedor se ejecuta en el navegador del visitante y reporta. Suceden dos tipos de cosas.

Huella digital

El script recopila las mismas propiedades que un navegador antidetect está diseñado para controlar: hashes de canvas y WebGL, fuentes, dimensiones de pantalla y ventana, concurrencia de hardware, zona horaria, idiomas, contexto de audio, IPs visibles por WebRTC, listas de plugins y docenas de señales más pequeñas. También sondea artefactos de automatización: navigator.webdriver establecido en true, objetos específicos de Chrome faltantes o inconsistentes, peculiaridades del modo headless en el renderizado, un número inusual de ciertas APIs anuladas (una señal de plugins de sigilo que parchean el navegador). Y verifica la coherencia: ¿la plataforma reportada por JavaScript coincide con el SO de la huella TCP? ¿La zona horaria coincide con el país de la IP? Ver lo que controla un navegador antidetect.

Desafíos

Los proveedores también emiten tareas de prueba de trabajo o prueba de humanidad. El Turnstile de Cloudflare y el intersticial de "comprobando su navegador" ejecutan una carga de trabajo de JavaScript cuyo resultado debe enviarse de vuelta; un cliente que no puede ejecutar JavaScript en absoluto — cada biblioteca HTTP simple — simplemente falla y nunca ve la página. Los CAPTCHA visibles son el último recurso, mostrados cuando la puntuación es mala pero no lo suficientemente mala como para bloquear directamente. Pasar un desafío típicamente produce una cookie o token válido por un período; la automatización que borra cookies en cada solicitud enfrenta el desafío cada vez, lo que en sí mismo es una señal.

Capa 4: Comportamiento

A lo largo de una sesión — y entre sesiones que el proveedor puede vincular por huella o IP — el sistema observa lo que hace el visitante:

  • Patrones de solicitud: páginas por minuto, si se obtienen las imágenes y scripts referenciados por una página (los navegadores humanos los obtienen; los scrapers ingenuos no), si la navegación sigue enlaces o salta directamente a URLs profundas, si las mismas rutas se visitan en el mismo orden cada sesión.
  • Tiempos: intervalos uniformes entre solicitudes son de máquina; los humanos son ráfagas e irregulares.
  • Interacción: movimiento del ratón, scroll, eventos de teclado — su presencia y su forma (las trayectorias reales del ratón curvan y sobrepasan; las scripteadas son líneas rectas o arcos perfectos).
  • Forma de la sesión: un inicio de sesión seguido inmediatamente de una acción masiva; un checkout sin navegación; creación de cuentas desde una huella que creó cinco cuentas ayer.

El comportamiento es la razón por la que una configuración técnicamente perfecta — navegador real, proxy coincidente, huella limpia — puede ser detectada si actúa como una máquina. También es la capa donde reside la reputación acumulada: una identidad que se ha comportado normalmente durante semanas gana tolerancia que una nueva no tiene. Eso es lo que significa "calentamiento" en la práctica.

Cómo se combinan las capas: la puntuación

Cada capa contribuye con evidencia; el producto la combina en una puntuación de bot (Cloudflare expone la suya como 1–99; otros la mantienen interna) y el propietario del sitio configura umbrales: por encima de X, permitir; entre X e Y, desafiar; por debajo de Y, bloquear o servir un señuelo. Dos propiedades de este diseño importan para cualquiera que use proxies:

  1. Las capas deben coincidir. La puntuación no es la suma de marcas buenas independientes; las contradicciones se ponderan fuertemente. Una IP residencial (buena) más una huella TLS de Python (mala) más un User-Agent de Chrome (contradicción) puntúa peor que una IP de centro de datos con un UA honesto de python-requests, porque el segundo es al menos coherente.
  2. Nada se verifica de forma aislada. Pasar la reputación de IP te compra la entrada a la siguiente verificación, no un pase. Cada afirmación que haces — por IP, por handshake, por encabezado, por JavaScript, por comportamiento — se contrasta con todas las demás.

Qué significa esto para la elección de proxy

CapaQué la decide¿Puede un proxy arreglarla?
1. Reputación de IPTipo de IP, historial, velocidad, geoSí — este es el trabajo del proxy
2. Huellas de redTu cliente HTTP / navegadorNo — se reenvían sin cambios
3. Huella del navegador / desafío JSTu navegador y su configuraciónNo — pero la geo/zona horaria debe coincidir con el proxy
4. ComportamientoTu lógica de automatización y ritmoNo — aunque la rotación afecta la velocidad por IP

Entonces: elige el tipo de proxy que exija la política de capa 1 del objetivo (centro de datos donde se tolere, residencial o móvil donde no), y luego invierte tu esfuerzo en las capas 2–4, que ningún proxy toca. En la práctica, eso significa un navegador real o impersonado para objetivos protegidos, consistencia de huella por identidad, geo/zona horaria coincidente con la IP y un ritmo con forma humana. La estrategia de rotación interactúa con la velocidad de la capa 1 y la forma de sesión de la capa 4 a la vez — ver elegir un intervalo de rotación.

Cómo saber qué capa te está deteniendo

  • Bloqueado al instante, sin HTML, incluso desde un navegador real en la misma IP → capa 1: la IP o el ASN es el problema. Cambia el tipo de proxy o proveedor.
  • El navegador pasa, el script en la misma IP no → capa 2: huella TLS/HTTP. Muévete a un navegador real o a un cliente que imite.
  • Intersticial que nunca se resuelve, o un CAPTCHA en cada visita → capa 3: el desafío de JavaScript falla o la huella es inconsistente. Revisa los flags de automatización, WebRTC, zona horaria vs IP.
  • Funciona por un tiempo, luego se degrada; o las cuentas mueren después de acciones → capa 4: comportamiento o velocidad. Reduce la velocidad, varía los patrones, calienta las identidades.

Los proveedores devuelven respuestas distintivas (una página 403 de Cloudflare, los encabezados x-datadome de DataDome y su endpoint de CAPTCHA, la cookie _abck de Akamai), por lo que identificar qué producto usa un sitio suele ser cuestión de mirar encabezados y cookies — y saber qué producto te dice qué capas enfatiza.

Preguntas frecuentes

¿Qué es una puntuación de bot?

Una estimación por solicitud, producida combinando reputación de IP, huellas de red y navegador, y señales de comportamiento, de cuán probable es que la solicitud sea automatizada. Los propietarios de sitios establecen umbrales para permitir, desafiar o bloquear.

¿Por qué un proxy residencial aún recibe un CAPTCHA?

Porque la reputación de IP es solo una de cuatro capas. Si la huella TLS/HTTP dice "script", el navegador falla o carece del desafío de JavaScript, o el comportamiento es de máquina, la puntuación es pobre independientemente de la IP.

¿Los sistemas anti-bot comparten datos entre sitios web?

Dentro de un proveedor, sí: una IP o huella marcada en el sitio de un cliente aumenta su riesgo en los sitios de otros clientes. Por eso un pool de proxies muy utilizado contra un objetivo protegido por Cloudflare puede funcionar mal en objetivos protegidos por Cloudflare no relacionados.

¿Pueden las bibliotecas HTTP simples pasar los desafíos de JavaScript?

No. Los desafíos requieren ejecutar JavaScript en un entorno similar a un navegador. Las opciones son un navegador automatizado real, o un servicio de resolución que ejecute el desafío por ti y devuelva la cookie/token resultante — lo que tiene su propio costo y riesgo de detección.

¿Cuál es la diferencia entre un desafío y un CAPTCHA?

Un desafío suele ser invisible — una carga de trabajo de JavaScript o atestación que el navegador completa automáticamente. Un CAPTCHA es un rompecabezas visible para el humano, mostrado cuando la puntuación es lo suficientemente mala como para que el sistema quiera una prueba explícita.

¿Es posible ser completamente indetectable?

No como garantía. La detección es probabilística y los proveedores actualizan constantemente. Lo que se puede lograr es consistencia en las cuatro capas más un comportamiento con forma humana, lo que mantiene la puntuación en el rango de "permitir" la mayoría del tiempo. Quien prometa indetectabilidad solo con el proxy está vendiendo solo la capa 1.