Los equipos que se defienden contra los bots y los equipos que los construyen llevan unos quince años inmersos en una carrera armamentística a cámara lenta. La frontera se desplazó cada pocos años, y cada cambio obligó a los equipos de datos a realizar un tipo diferente de inversión. Vale la pena conocer la cronología aproximada porque el estado actual de las cosas no resulta obvio desde fuera, y gran parte de los consejos que circulan por internet llevan dos generaciones anti-bot de retraso.
Generación 1: listas de bloqueo de IP y límites de velocidad
Las primeras defensas eran procedimentales. Llegaba una solicitud, el servidor registraba la IP y, si esa IP hacía algo claramente propio de una máquina, demasiadas solicitudes por minuto, una secuencia demasiado predecible, un User-Agent demasiado pequeño, se le aplicaba un límite de velocidad o se la bloqueaba directamente. Circulaban listas de rangos de IP de centros de datos conocidos. Cualquier cosa procedente de AWS o DigitalOcean se trataba con sospecha.
Esta fue la época en que la respuesta a “cómo hago scraping de X” era casi siempre “usa un proxy”. En concreto, un proxy de centro de datos. Compra un /24, rótalo, problema resuelto.
Funcionaba porque los defensores no tenían mucho más.
Generación 2: CAPTCHAs y el impuesto de fricción al usuario
Cuando las defensas a nivel de IP empezaron a fallar, los defensores trasladaron la fricción al usuario. Los CAPTCHAs se volvieron universales: primero los de coincidencia de imágenes, luego reCAPTCHA, después el reCAPTCHA invisible, y más tarde hCaptcha, Turnstile y Arkose.
Los CAPTCHAs funcionan, en el sentido de que rompen los scrapers más básicos. También funcionan en el sentido de que molestan lo suficiente a los usuarios reales como para reducir de forma medible la tasa de conversión. La mayoría de los sitios que usaron capas agresivas de CAPTCHA entre 2017 y 2020 las han retirado desde entonces, porque el coste de la fricción superaba al coste de los bots.
Desde el lado del scraping, los CAPTCHAs generaron toda una industria de servicios de resolución con intervención humana. Paga unos céntimos por resolución, envía tus CAPTCHAs a un panel de trabajadores en geografías de bajo coste, recibe el token de vuelta y continúa haciendo scraping. No es elegante, pero funcionaba.
Generación 3: fingerprinting de navegador y comportamiento
La tercera generación subió en la pila. Los sitios empezaron a hacer fingerprinting del propio cliente, no solo de la IP, sino del navegador. Canvas fingerprinting, firmas WebGL, listas de fuentes, contexto de audio, zona horaria, preferencias de idioma, dimensiones de pantalla, plugins disponibles, el orden en que se proponían los cifrados TLS en el handshake (fingerprints JA3 / JA4), el tiempo de los movimientos del ratón, la cadencia de las pulsaciones de teclas.
Headless Chromium sin un endurecimiento específico filtra docenas de estas señales. Los defensores construyeron bibliotecas (Fingerprint.js y sus equivalentes comerciales) que puntuaban las solicitudes a lo largo de esta superficie y rechazaban cualquier cosa que pareciera demasiado limpia, demasiado mecánica o demasiado diferente al navegador de un usuario real.
Aquí fue cuando el scraping se volvió difícil. Una IP residencial ya no era suficiente por sí sola. Necesitabas manejar un navegador real, o uno headless suficientemente bueno con fingerprints parcheados, y necesitabas que su comportamiento pareciera natural. El proxy seguía siendo esencial, pero se había convertido en un componente más de una pila en lugar de ser la solución completa.
Generación 4: reputación a nivel de red
La frontera actual es la más costosa para todos. Los defensores compran ahora datos de reputación a proveedores de red como Cloudflare, Akamai y una docena de especialistas más pequeños. Cada IP recibe una puntuación de reputación que agrega señales de millones de sitios: ¿se ha visto esta IP iniciando sesión en cuentas bancarias, completando flujos de compra, abriendo Gmail con normalidad? ¿O se la ha visto atacando endpoints de inicio de sesión con patrones que sugieren credential stuffing, publicando comentarios a cadencias de máquina, haciendo scraping de páginas de precios de la competencia a las 3 de la madrugada del martes?
Una IP de centro de datos tiene, casi por definición, un historial de red escaso o negativo. No ha realizado cosas humanas normales. Una IP residencial, en cambio, tiene años de tráfico mundano detrás: el hogar al que sirve la usa para Netflix, Steam, Zoom y navegación habitual. Esa reputación es lo que protege a los scrapers hoy en día.
Los proxies ISP ocupan un lugar intermedio interesante: los emiten ISPs residenciales reales (por lo que el proveedor upstream coincide con un bloque de IP doméstico), pero se asignan a centros de datos y se mantienen de forma estática. Son más difíciles de detectar que las IP puras de centro de datos, pero más fáciles que las residenciales rotativas, y su precio refleja esa diferencia.
Qué significa esto para los equipos de datos en 2026
Algunas cosas han permanecido constantes a lo largo de las cuatro generaciones y seguirán siéndolo:
El proxy adecuado es necesario pero no suficiente. Una IP residencial real te permite superar la barrera a nivel de red. A partir de ahí, tu cliente, tus cabeceras, tu fingerprint TLS y tus patrones de comportamiento todavía necesitan ser plausibles.
La tasa de bloqueo es la única métrica que importa. No el tamaño del pool, no el número de países, no las funcionalidades anunciadas. Si tus scrapes devuelven HTML limpio a un coste aceptable, la infraestructura funciona. Si no lo hacen, ninguna afirmación de marketing te ayudará.
El proxy adecuado depende del flujo de trabajo. La rotación por solicitud a través de un gran pool residencial es la opción correcta para trabajos de monitorización de precios en abanico. Las sesiones fijas en una única IP residencial durante diez minutos son la opción correcta para flujos de varias páginas. Las IP ISP fijas son la opción correcta para la gestión de cuentas y cualquier flujo de trabajo que necesite la misma identidad durante semanas o meses. No elijas una sola herramienta para todos los trabajos.
El anti-bot seguirá subiendo en la pila. La siguiente capa probablemente sea un análisis de comportamiento más agresivo en el edge, clasificadores basados en aprendizaje automático que examinen la forma de sesiones de varios minutos, no las características de una sola solicitud. Esto ya está en producción en los sitios más grandes. La carrera armamentística de los defensores se acumula, y también lo hace el coste de mantenerse en ella.
La conclusión honesta: nadie que te diga que el scraping está “resuelto” tiene razón. Es un problema de operaciones, y las operaciones son lo que pagas. Los proxies residenciales siguen siendo la base porque son el único lugar donde la IP upstream lleva el tipo de historial adecuado. Todo lo demás se construye sobre eso.