Elegir un proxy para hacer scraping es en realidad una cuestión sobre el objetivo, no sobre el proxy. Un sitio sin defensas y un sitio protegido por DataDome necesitan configuraciones completamente distintas, y pagar tarifas residenciales para el primero desperdicia dinero mientras que usar IPs de datacenter contra el segundo desperdicia tiempo.
Esta guía cubre qué tipo de proxy conviene a cada tarea de scraping, cómo ejecutarlos sin que te bloqueen, y cuándo una API de scraping es mejor respuesta que los proxies en bruto.
Los Cuatro Tipos, para Scraping
| Tipo | Origen de la IP | Velocidad | Tasa de bloqueo | Coste | Tarea de scraping más adecuada |
|---|---|---|---|---|---|
| Datacenter | Proveedores de hosting | La más alta | Alta en sitios defendidos | La más baja | Sitios sin protección, APIs, extracción masiva |
| Residencial | ISPs de consumo, hogares reales | Moderada | Baja | Media, por GB | Retail, viajes, búsquedas, cualquier cosa defendida |
| ISP | ISPs de consumo, alojadas en datacenter | Alta | Baja a moderada | Por IP al mes | Sesiones con inicio de sesión, tareas de larga duración |
| Móvil | Operadores móviles | Moderada a baja | La más baja | La más alta | Los objetivos más difíciles, APIs de apps |
Vale la pena hacer una corrección, porque lo contrario está ampliamente publicado y este artículo lo repetía anteriormente: las IPs de datacenter no son entregadas por ISPs. Están registradas a nombre de proveedores de hosting y de nube y nunca pasan por un proveedor de internet de consumo. Por eso precisamente son identificables: los rangos son públicos, así que un sitio puede clasificarlas a simple vista.
Los proxies ISP y móviles importan ambos para el scraping y suelen quedar fuera de comparaciones como esta. Los proxies ISP son la respuesta siempre que un scrape tenga un inicio de sesión detrás, porque la dirección permanece fija. Los proxies móviles son el último recurso para objetivos que vencen a todo lo demás.
Rotación y Gestión de Sesiones
La estrategia de rotación importa más que el tipo de proxy para evitar bloqueos.
La rotación por solicitud entrega una IP nueva en cada petición. Es la opción correcta por defecto para recopilar páginas independientes: listados de productos, resultados de búsqueda, entradas de directorios. Ninguna dirección acumula un patrón sospechoso.
Las sesiones persistentes (sticky sessions) mantienen una IP durante una duración determinada, normalmente de 1 a 30 minutos. Úsalas siempre que las solicitudes dependan unas de otras: paginación que lleva un cursor, cualquier cosa posterior a un inicio de sesión, flujos de compra en varios pasos. Una sesión que cambia de IP a mitad de camino parece un robo de cuenta y recibe un desafío.
La regla práctica: rota por solicitud a menos que algo en el flujo requiera continuidad, y en ese caso mantén la ventana persistente más corta que la cubra.
Tasa de Solicitudes y Concurrencia
La mayoría de los bloqueos los causa la tasa, no el tipo de proxy. Una IP residencial que golpea un sitio 20 veces por segundo resulta más obviamente automatizada que una IP de datacenter que lo hace una vez cada 10 segundos.
- Tasa por IP. En un sitio defendido, mantén cada dirección en aproximadamente una solicitud cada 2 a 5 segundos. En uno sin protección puedes ser mucho más agresivo.
- Concurrencia. El rendimiento total es direcciones concurrentes multiplicadas por la tasa por IP. Para conseguir 10 solicitudes por segundo con seguridad quieres del orden de 30 a 50 direcciones activas a la vez, no 10 direcciones yendo tres veces más rápido.
- Aleatoriza. Los intervalos fijos son en sí mismos una firma. Añade variación (jitter) para que los intervalos varíen.
- Retrocede ante fallos. Cuando las tasas de error suben, ralentiza en lugar de reintentar con más fuerza. Reintentar contra un bloqueo es como un límite de tasa suave se convierte en una prohibición permanente.
Cabeceras y Huellas Digitales
Una IP te lleva a la puerta. La solicitud tiene que parecer correcta una vez allí.
- Envía un conjunto de cabeceras completo y coherente. Los navegadores reales envían
Accept,Accept-Language,Accept-Encoding,User-AgentySec-Ch-Uaen una combinación consistente. UnUser-Agentsolitario en una solicitud por lo demás desnuda es una fuerte señal de bot. - Mantén el relato de las cabeceras coherente con la IP. Una IP alemana enviando
Accept-Language: en-USes una discrepancia que conviene evitar cuando estás segmentando por geolocalización. - Haz que el comportamiento TLS y HTTP coincida con el cliente que dices ser. Los sistemas avanzados toman la huella del handshake TLS y del orden de los frames HTTP/2, así que un cliente Python que dice ser Chrome es detectable independientemente de las cabeceras.
- Usa un navegador real cuando la página lo necesite. Los sitios que renderizan contenido en JavaScript necesitan un navegador headless, y los navegadores headless tienen sus propias huellas digitales que hay que gestionar.
Sistemas Anti-Bot Modernos
Cloudflare, DataDome, PerimeterX y Akamai no son listas de bloqueo de IPs. Puntúan una combinación de reputación de la dirección, huella digital de la solicitud, comportamiento y resultados de desafíos JavaScript.
Eso tiene dos consecuencias. Rotar solo las IPs no los vencerá, porque tu huella digital permanece sin cambios. Y una IP residencial es necesaria pero no suficiente: elimina la señal más fácil, dejando las más difíciles.
Cuando te encuentres con uno:
- Lee la respuesta correctamente. Un 403 con una página de desafío es distinto de un límite de tasa 429 y necesita una solución diferente. Revisa el cuerpo, no solo el código de estado.
- Ralentiza primero. La tasa es lo más económico de cambiar y a menudo la causa real.
- Sube por la escalera de confianza. De datacenter a residencial, de residencial a móvil.
- Renderiza el desafío. Si el sitio requiere ejecución de JavaScript, un cliente HTTP sencillo nunca pasará sin importar qué IP use.
- Reconsidera el enfoque. Si un objetivo cuesta más en reintentos que lo que valen los datos, una API gestionada resulta más económica que seguir luchando contra él.
Coste, Volumen y Cuándo Usar una API
Estimar un proyecto empieza por el peso de la página. Una página HTML típica pesa de 0,5 a 2 MB, así que 100.000 páginas son aproximadamente 50 a 200 GB. Renderizar JavaScript multiplica eso varias veces, porque además estás descargando scripts, estilos e imágenes.
El número que en realidad decide tu factura es la tasa de bloqueo. Una configuración que falla en el 40% de las solicitudes y las reintenta paga ese ancho de banda dos veces. Los proxies baratos con una alta tasa de fallo con frecuencia cuestan más por página exitosa que los caros.
Los proxies en bruto son la opción correcta cuando controlas el scraper, el objetivo está bien entendido, y quieres el coste por unidad más bajo. Una API gestionada es la mejor opción cuando el objetivo se resiste con fuerza, cuando de lo contrario tendrías que mantener huellas digitales de navegador y solucionadores de desafíos, o cuando el tiempo de ingeniería es el recurso escaso en lugar del dinero.
La Web Scraping API de Shifter gestiona la rotación de proxies, el renderizado de JavaScript y los desafíos detrás de una única solicitud, y la SERP API hace lo mismo específicamente para resultados de búsqueda, que por lo demás es uno de los objetivos más complicados de mantener. Para proxies en bruto, los proxies residenciales y los proxies ISP cubren los dos extremos de la cuestión de las sesiones, y las tarifas actuales están en la página de precios.
Un Marco de Decisión Breve
- El objetivo no tiene protección anti-bot y necesitas volumen de forma económica: proxies de datacenter.
- El objetivo limita la tasa o te desafía, sin inicio de sesión involucrado: residencial rotativo.
- El scrape requiere una sesión con inicio de sesión o debe mantener una identidad: proxies ISP.
- El objetivo vence al residencial, o necesitas acceso a nivel de app: proxies móviles.
- El objetivo cuesta más en mantenimiento que lo que valen los datos: una API de scraping.
La mayoría de los proyectos reales mezclan estos enfoques. La recopilación se ejecuta con residencial rotativo, el puñado de paneles autenticados se ejecuta con ISP, y el único objetivo imposible pasa por la API.
Conclusión
No existe un único mejor proxy para el scraping. Ajusta el tipo a lo duro que se defiende el objetivo, ajusta la rotación a si tus solicitudes dependen unas de otras, y trata la tasa de solicitudes como lo primero que ajustar cuando aparezcan bloqueos.
Para la taxonomía más amplia, consulta tipos de proxies, y para el caso de uso completo, la descripción general de web scraping.