Cómo detectan anti-bot tu scraper: las 6 señales

En pocas palabras: Los sistemas anti-bot como Cloudflare detectan tu scraper con seis señales por request: reputación de IP, huella TLS, ritmo de navegación, coherencia de sesión, consistencia de headers e histórico de conducta. Cada una suma puntaje de riesgo; al cruzar el umbral aplican degradación progresiva: lentitud, CAPTCHA y bloqueo 403.

Los sistemas anti-bot no bloquean tu scraper por un error puntual: acumulan un puntaje de riesgo en cada request y, al cruzar el umbral, pasan de respuestas lentas a CAPTCHA y de ahí a 403. DEV publicó una guía técnica que explica cómo los sistemas anti-bot detectan tu scraper mediante seis señales concretas, ordenadas por velocidad de delación.

Un sistema anti-bot es una plataforma de protección web (Cloudflare, Akamai, DataDome y PerimeterX son los principales jugadores) que analiza cada request entrante, le asigna un puntaje de riesgo y decide si mostrar la página, un desafío o un bloqueo. Según la guía de DEV, ese puntaje se arma con seis señales: reputación de IP, huella TLS, ritmo de navegación, coherencia de sesión, consistencia de headers e histórico de conducta.

Cloudflare es una empresa estadounidense de infraestructura web fundada en 2009 por Matthew Prince, Lee Holloway y Michelle Zatlyn, que ofrece servicios de red de distribución de contenidos (CDN), protección contra ataques DDoS y gestión de tráfico mediante sistemas anti-bot y cortafuegos de aplicaciones web.

¿Cómo funcionan los sistemas anti-bot de detección?

Funcionan por scoring acumulativo, no por firma única. Cada request suma o resta puntos en un tablero invisible: el tipo de IP, la huella TLS, los headers, el ritmo, la forma de la sesión y el historial. Cuando el puntaje cruza cierto umbral, la respuesta se degrada en silencio: primero va más lenta, después te sirven un CAPTCHA y, si insistís, llega el 403.

Pensemos el escenario típico: le pegás al listado de productos y responde bárbaro, seguís un par de horas y sigue respondiendo, duplicás la frecuencia y de golpe todo se cae, aparece un CAPTCHA que no pediste, después un 403, y vos mirando tu código sin entender qué rompiste, porque la verdad es que no rompiste nada: cruzaste un umbral en un sistema que ni siquiera podés inspeccionar.

Las capas clásicas de detección son reputación de IP, fingerprinting TLS, fingerprinting HTTP (headers), fingerprinting JavaScript y análisis conductual. Ojo con un detalle: ninguno de los cuatro grandes publica los pesos de su fórmula. Lo poco que sabemos sale de ingeniería inversa.

Suena injusto. También es eficaz.

¿Cómo detectan anti-bot tu scraper? Las seis señales, una por una

Mediante seis señales ordenadas por rapidez de delación: la IP te quema en el primer request, el histórico tarda días. Vamos de la más veloz a la más lenta, con el detalle práctico de cada una.

¿Por qué tu IP de datacenter es la primera señal que te delata?

Porque es el chequeo más barato que existe: el vendor clasifica tu dirección antes de parsear una sola línea del request. Los rangos de AWS, Hetzner u OVH arrancan sospechosos, porque humanos reales no navegan desde racks. Las IPs residenciales de ISPs reales parten neutras, y las residenciales marcadas por abuso previo quedan en el medio.

Ejemplo concreto: corrés un scraper en una instancia de Virginia contra un e-commerce alemán. Doble mismatch, según la nota: tipo equivocado (datacenter) y geografía equivocada (EE.UU. contra tienda alemana). Al revés, una IP residencial alemana con locale coherente es casi indistinguible de un cliente local. Por eso los proxies residenciales con geo-targeting sostienen cualquier pipeline serio.

¿Querés comprobarlo? Tirale un request a httpbin.org/ip sin proxy, después por uno de datacenter y por uno residencial. Mismo código, distinto score inicial.

¿Qué es el TLS fingerprint (JA3/JA4) y cómo delata a tu cliente?

Es la huella que deja tu handshake TLS antes de intercambiar un solo byte de HTTP. El ClientHello revela qué cipher suites ofrecés, en qué orden y qué extensiones mandás, y esa combinación identifica al cliente: Python requests, curl, Chrome y Firefox firman distinto. Los sistemas comparan ese fingerprint (los estándares de facto son JA3 y JA4) contra lo que declara tu User-Agent.

Ahí está la trampa. Si tus headers dicen Chrome 151 pero negociás TLS como Python, tenés una contradicción directa, y los scoring systems existen justo para cazar contradicciones. Ya lo cubrimos antes en problemas de resolución DNS y cómo evitarlos.

Opciones, de menor a mayor esfuerzo:

• Headers honestos: asumís el mismatch, pero mantenés coherencia en todo lo demás para no sumar contradicciones extra.
• Librerías que imitan el TLS de Chrome: del estilo curl-impersonate, replican la firma del navegador en el handshake.
• Navegador real vía Playwright: caro en recursos, pero verdadero; para targets estrictos suele ser el único camino.

¿Alcanza con Selenium o Puppeteer solos? Ayudan con el TLS, pero en páginas renderizadas también miran eventos de scroll y pointer. Un headless quieto como estatua suma puntos igual.

¿Por qué los bots tienen ritmo perfecto y los humanos no?

Porque los humanos somos irregulares y los bots son metrónomos. Un intervalo clavado de 1,0 segundo entre requests, actividad 24/7 sin noches ni fines de semana, cero eventos de puntero en páginas renderizadas: cada patrón es un input del score.

Fijate tu cron: corre cada minuto en el segundo cero, feriados incluidos (sí, a las 3 de la mañana de Navidad también). Ningún ser humano navega así. El jitter aleatorio en los intervalos es el arreglo más barato de toda esta lista, y aun así veo pipelines productivos sin él.

¿Cómo tu sesión inconsistente te termina delatando?

Porque una sesión humana tiene forma: llegás, mirás un par de páginas, quizás te logueás, hacés clic hacia adentro. La sesión típica de un scraper es otra cosa: login, 500 fichas de producto una detrás de otra, logout. Nadie hace eso. Y si el login es parte de tu flujo, cuidá las credenciales: lo cubrimos en gestionar secretos y credenciales de forma segura.

Dos delatores clásicos. Primero, rotar IP a mitad de sesión: te logueás bien, cambiás a una IP fresca y te echan, porque para el sitio la IP del usuario cambió en pleno login, algo que en personas reales no pasa jamás. Las sticky sessions (misma IP durante la vida de la sesión, típicamente hasta 30 minutos) resuelven esto. Segundo, la falta de prólogo: aterrizar directo en la página 47 de resultados sin referer ni vistas previas. Un request inofensivo al homepage antes del target profundo le da forma a la sesión por un request adicional. Cubrimos ese tema en detalle en comparativa de rendimiento entre contenedores y microVMs.

¿Cuántas veces cambiaste de IP mientras comprabas zapatillas online? Cero. Eso.

¿Tus headers HTTP y tu TLS cuentan la misma historia?

Deberían, porque la coherencia importa más que cada valor individual. Un navegador manda decenas de headers en combinaciones específicas; el scraper promedio manda cuatro y un User-Agent copiado de algún post de 2021 (esa “configuración” sagrada que circula en todos los tutoriales).

Un set de Chrome 151 sobre Windows incluye, entre otros, Accept con los pesos q correctos, Upgrade-Insecure-Requests, Connection keep-alive y la familia Sec-Fetch. Acordate de alinear el Accept-Language con la geografía de tu IP: fr-FR saliendo de Tokio es un mismatch, salvo que estés testeando mismatches a propósito (cosa rara, pero bueno).

¿Por qué una IP nueva siempre rinde mejor que una reutilizada?

Porque el tiempo también puntúa. Aunque tu request sea perfecto, el sistema revisa el prontuario: cuántos requests hizo esta IP hoy, cuántas sesiones distintas abrió, si este fingerprint ya fue visto siendo bloqueado. Una IP fresca de un pool grande arranca con prontuario limpio en cada request.

Esto explica el ciclo de vida estándar de la IP de datacenter: funciona una semana y muere. El prontuario acumula hasta colapsar. Matemática del scoring, sin misterio.

Señal	Qué mira	Delator típico	Mitigación rápida
Reputación de IP	Tipo y geografía del origen	IP de AWS/Hetzner/OVH contra un shop local	Residenciales con geo-matching
Huella TLS (JA3/JA4)	Cipher suites y extensiones del ClientHello	UA Chrome con handshake de Python	curl-impersonate o navegador real
Timing	Intervalos y horarios de request	1,0 segundo exacto, 24/7	Jitter aleatorio
Consistencia de sesión	Forma de la sesión y estabilidad de IP	Rotar IP tras el login	Sticky sessions (hasta 30 min)
Coherencia de headers	Combinación completa contra el UA declarado	Cuatro headers y un UA de 2021	Set completo acorde a navegador y geografía
Histórico	Prontuario de la IP y del fingerprint	Semana de uso intenso y muerte súbita	Pool fresco, IP descartable

¿Cómo lograr más de 99% de éxito sin jugar al gato y al ratón?

Dejando de contradecirte. Cuando todas las capas del request cuentan la misma historia, queda muy poco para puntuar en tu contra. La receta del autor, tal cual la resume en la nota: IPs residenciales con geo-matching, sticky sessions, timing con jitter, headers coherentes y prólogo de sesión antes del target. Más contexto en almacenar los datos extraídos sin costo de egreso.

¿Resultado? Éxito sostenido por encima del 99% en sus pipelines de producción, y él mismo lo atribuye a la ausencia de anything suspicious que detectar. Tomalo con pinzas: es su propio dato, no un benchmark auditado. Como referencia de mercado, el artículo cita (con declaración de intereses incluida) proxies residenciales desde 0,65 dólares por GB rotante y 0,75 dólares por IP estática. Precios de entrada razonables si tu operación depende de esto.

Qué significa para equipos en Latinoamérica

Doble mismatch, edición regional: si scrapeás e-commerce o travel de la región desde IPs de EE.UU., combinás tipo y geografía equivocadas, el peor escenario del punto uno. Para monitoreo de precios o competencia, invertir en residenciales geo-matcheadas de la región rinde más que cualquier truco de headers.

Del otro lado del mostrador también hay lectura: si tu sitio empieza a servir lentitud y CAPTCHAs en ráfagas, puede haber falsos positivos con usuarios legítimos detrás de VPNs o proxies corporativos. Y si buscás alojar tus propios proyectos con soporte y facturación locales, donweb.com sigue siendo una opción argentina de confianza para hosting y dominios.

Qué está confirmado (y qué todavía no)

• Confirmado por la fuente primaria: las seis señales, la degradación progresiva (lento, CAPTCHA, 403), las sticky sessions de hasta 30 minutos y el scoring acumulativo en Cloudflare, Akamai, DataDome y PerimeterX.
• Confirmado con atribución: los precios de referencia del mercado residencial (desde USD 0,65/GB rotante y USD 0,75 por IP estática) los aporta el propio autor con su declaración de intereses a la vista.
• Sin verificación independiente: el éxito sostenido superior al 99%; es el dato de producción del autor, no un test reproducible público.
• Pendiente: los pesos exactos de cada señal; ningún vendor publica su fórmula.

Errores comunes que te delatan en minutos

Los vi todos en producción. Corregilos y tu tasa de bloqueo baja sola:

• Rotar IP en cada request: sobre todo tras un login; usá sticky sessions y guardá la rotación para sesiones nuevas.
• Mentir en el User-Agent: declarar Chrome y handshakear como Python es la contradicción más cara; o sos honesto o imitás el TLS completo.
• Cron metronómico: requests cada 60 segundos clavados; metele jitter aleatorio, aunque sea de más/menos unos segundos.
• Sesión sin prólogo: aterrizar directo en la URL profunda; calentá con el homepage y seguí una ruta creíble.
• Reusar la misma IP de datacenter durante semanas: el prontuario acumula; renová el pool antes de que el score te alcance.

Preguntas Frecuentes

¿Cómo funcionan los sistemas anti-bot de detección?

Acumulan un puntaje de riesgo por request usando seis señales: reputación de IP, huella TLS, timing, consistencia de sesión, coherencia de headers e histórico. Al cruzar un umbral, degradan la respuesta en escalones: primero lentitud, después CAPTCHA, finalmente 403. Nunca bloquean por un error aislado.

¿Qué es el TLS fingerprint y cómo delata a mi scraper?

Es la huella de tu handshake TLS (estandarizada en hashes tipo JA3/JA4), que revela cipher suites, orden y extensiones antes del primer byte HTTP. Si tu User-Agent dice Chrome pero el ClientHello corresponde a Python, el sistema marca una contradicción directa y suma riesgo al score.

¿Por qué rotar IP a mitad de sesión no funciona contra los anti-bots?

Porque ninguna persona real cambia de IP entre el login y la página siguiente. El sistema interpreta ese cambio como toma de control de cuenta o automatización y corta la sesión. La solución son las sticky sessions: misma IP durante toda la sesión, típicamente hasta 30 minutos.

¿Qué headers debo enviar para parecer un usuario humano?

Un set completo y coherente con el navegador declarado: Accept con pesos q, Accept-Language alineada con la geografía de tu IP, Upgrade-Insecure-Requests, Connection keep-alive y la familia Sec-Fetch. La coherencia entre todos los valores pesa más que cada header individual.

¿Cómo lograr más de 99% de éxito en scraping sin ser detectado?

Haciendo que cada capa cuente la misma historia: IPs residenciales geo-matcheadas, sticky sessions, timing con jitter, headers coherentes y un prólogo de sesión antes del target. Con esa combinación, el autor de la guía reporta éxito sostenido superior al 99% en producción, aunque el dato carece de auditoría independiente.

Conclusión

Lo que cambió: la detección moderna dejó de ser una lista negra y es scoring acumulativo con seis capas. Lo que implica: tu scraper que muere a los 1.000 requests no tiene un bug, cruzó un umbral. Lo que hacés ahora: auditá las seis señales de tu pipeline, corregí contradicciones entre IP, TLS, timing, sesión, headers e historial, y medí de nuevo. La verdad es que me gusta este marco porque saca la conversación del terreno místico de “evadir al firewall” y la lleva a ingeniería de consistencia: si tu request cuenta una historia creíble de punta a punta, casi no queda nada que puntuar en tu contra. Y eso, en 2026, vale más que cualquier truco de turno.

Fuentes

• How Anti-Bot Systems Actually Detect Your Scraper (Cómo los sistemas anti-bot detectan realmente tu scraper) – nota original en DEV