Consultas paralelas y secuenciales a través de proxy: cómo elegir el método sin bloqueos

Al hacer scraping en marketplaces, automatizar el trabajo en redes sociales o recopilar datos a través de API, es crucial elegir la estrategia de envío de solicitudes correcta. Una configuración incorrecta puede llevar a bloqueos de IP, captchas y pérdida de tiempo. En esta guía, analizaremos cuándo utilizar consultas paralelas para la máxima velocidad y cuándo consultas secuenciales para mayor seguridad.

Diferencias entre consultas paralelas y secuenciales

Consultas secuenciales son aquellas en las que tu script o programa envía solicitudes una tras otra: espera la respuesta de la primera solicitud antes de enviar la segunda. Esto es lento, pero seguro y parece lo más natural para el sitio web objetivo.

Consultas paralelas son aquellas en las que se envían varias solicitudes al mismo tiempo (5, 10, 50 o incluso cientos), sin esperar las respuestas de las anteriores. Esto es mucho más rápido, pero crea carga en el servidor y puede levantar sospechas de los sistemas antifraude.

Imagina hacer scraping de precios de 10,000 productos en Wildberries. De manera secuencial con un retraso de 2 segundos entre solicitudes, eso toma 20,000 segundos o 5.5 horas. Si lanzas 20 flujos paralelos, solo toma 16 minutos. La diferencia es obvia, pero hay matices.

Comparación de métodos

Cuándo usar consultas paralelas

Las consultas paralelas son la elección cuando la velocidad es crítica y el volumen de datos es grande. Pero es importante entender: esto solo funciona con la configuración correcta de proxies y control de carga.

Escenarios ideales para consultas paralelas

1. Scraping de marketplaces con un gran catálogo
Si necesitas recopilar precios de 50,000 productos en Wildberries o Ozon, el scraping secuencial tomará días. Con 20-30 flujos paralelos y proxies de centros de datos, la tarea se resuelve en unas pocas horas.

Configuración: 20-30 flujos, cada uno con una IP separada, retraso de 1-3 segundos entre solicitudes dentro del flujo. Rotación de IP cada 100-200 solicitudes.

2. Recopilación de datos de API públicas
Muchas API (por ejemplo, servicios meteorológicos, bases de datos de empresas, servicios de geolocalización) tienen límites en las solicitudes desde una IP: 100-1000 al día. Las consultas paralelas a través de un pool de proxies permiten eludir estos límites.

Ejemplo: Necesitas recopilar datos de 10,000 empresas a través de una API. El límite es de 500 solicitudes/día por IP. Usas 20 proxies en paralelo = 10,000 solicitudes en un día en lugar de 20 días.

3. Verificación de disponibilidad de recursos
Si estás verificando la disponibilidad de sitios web, el funcionamiento de espejos o monitoreando el estado de servidores, las consultas paralelas ahorran horas. Aquí no se necesita simular el comportamiento humano, solo importa la velocidad.

4. Verificación masiva de proxies
Al comprar grandes pools de proxies (1000+ IP), necesitas verificar rápidamente su funcionalidad, velocidad, geolocalización. La verificación secuencial tomará horas, la paralela minutos.

Requisitos clave para consultas paralelas

• Gran pool de proxies (mínimo 10-20 IP, mejor 50-100+)
• Rotación automática de IP en caso de errores
• Control del número de flujos simultáneos (no más de 50-100)
• Retrasos entre solicitudes incluso dentro de los flujos (0.5-2 seg)
• Registro de errores para analizar las causas de bloqueos
• Sistema de reintentos (retry) en caso de timeouts

Cuándo usar consultas secuenciales

Las consultas secuenciales son la elección de seguridad y fiabilidad sobre la velocidad. Imitan el comportamiento de un usuario real y minimizan el riesgo de bloqueos en plataformas protegidas.

Escenarios obligatorios para consultas secuenciales

1. Trabajo con cuentas publicitarias
Facebook Ads, TikTok Ads, Google Ads no solo rastrean IP, sino también patrones de comportamiento. Las consultas paralelas desde una cuenta levantarán sospechas de inmediato. Una cuenta = un flujo = acciones secuenciales con retrasos de 5-15 segundos.

Ejemplo: Manejas 20 cuentas publicitarias de Facebook a través de un navegador anti-detección Dolphin Anty. Cada cuenta funciona en un perfil separado con proxy móvil, las acciones son estrictamente secuenciales: ingreso → verificación de estadísticas → ajuste de ofertas → salida. Retrasos de 7-12 segundos entre acciones.

2. Automatización de acciones en redes sociales
Instagram, TikTok, VK tienen límites estrictos en acciones: likes, suscripciones, comentarios. Superar los límites o realizar acciones demasiado rápidas = shadowban o bloqueo total. Solo consultas secuenciales con retrasos aleatorios de 20-60 segundos.

Configuración para Instagram: Una cuenta puede hacer un máximo de 60 likes/hora. Esto es 1 like por minuto con retrasos de 45-75 segundos (¡la aleatorización es importante!). Usas un proxy separado para cada cuenta.

3. Autenticación y trabajo con cuentas personales
Cualquier acción que requiera iniciar sesión en una cuenta (servicios de email, bancos, marketplaces como vendedor) debe realizarse de forma secuencial. Intentos paralelos de inicio de sesión desde diferentes IP en una cuenta son un camino directo hacia el bloqueo.

4. Sitios con protección anti-bot estricta
Plataformas con Cloudflare, Akamai, PerimeterX analizan no solo la frecuencia de solicitudes, sino también sus patrones. Si desde una IP o User-Agent llegan 10 solicitudes al mismo tiempo, es una señal clara de un bot. Las consultas secuenciales con retrasos de 3-10 segundos parecen naturales.

5. Bajo volumen de datos
Si necesitas hacer scraping de 50-100 páginas, la diferencia de tiempo entre el scraping secuencial y el paralelo no es significativa (5 minutos frente a 1 minuto). Sin embargo, el método secuencial garantiza la ausencia de problemas.

Retrasos correctos para consultas secuenciales

Riesgos de bloqueos con diferentes métodos

Comprender los riesgos ayuda a elegir la estrategia correcta y configurar la protección. Los bloqueos ocurren no solo debido a la frecuencia de las solicitudes, sino también a sus patrones.

Qué rastrean los sistemas antifraude

1. Frecuencia de solicitudes desde una IP
Si desde una IP llegan 100 solicitudes por minuto, es un bot obvio. Los límites varían: los sitios normales toleran 10-30 solicitudes/minuto, las plataformas protegidas — 2-5 solicitudes/minuto.

Solución para consultas paralelas: Distribuye las solicitudes en un gran pool de IP. Por ejemplo, 1000 solicitudes/minuto = 50 IP con 20 solicitudes cada una. Esto parece como 50 usuarios normales.

2. Intervalos idénticos entre solicitudes
Solicitudes exactamente cada 2.00 segundos son un signo de automatización. Un humano hace clic con diferentes intervalos: 1.8 seg, 3.2 seg, 2.1 seg.

Solución: Añade aleatorización ±30-50% del retraso base. En lugar de 5 segundos fijos, usa random(3.5, 7.5).

3. Ausencia de comportamiento típico del usuario
Un usuario real no va directamente a la página del producto; primero entra a la página principal, busca la categoría, hace clic en el producto. Un bot solicita directamente una URL específica.

Solución para plataformas críticas: Simula el recorrido completo del usuario. Antes de hacer scraping del producto, haz 2-3 solicitudes: principal → categoría → producto. Esto ralentiza el trabajo, pero reduce el riesgo de bloqueo en un 70-80%.

4. User-Agent y encabezados sospechosos
User-Agent obsoletos (por ejemplo, Chrome 95 en 2024), ausencia de encabezados Accept-Language, Referer — son señales de un bot.

Solución: Usa User-Agent actualizados (Chrome 120+, Firefox 120+), añade un conjunto completo de encabezados como un navegador real. Rota el User-Agent junto con la IP.

Comparación de riesgos de bloqueos

Qué proxies son adecuados para cada método

El tipo de proxy influye directamente en la posibilidad de usar consultas paralelas o secuenciales. Una elección incorrecta puede llevar a bloqueos o sobrecostos.

Proxies para consultas paralelas

Proxies de centros de datos son la opción óptima para scraping masivo y consultas paralelas. Son baratos (desde $1-3 por IP/mes), rápidos (ping de 20-50 ms) y están disponibles en grandes volúmenes. Desventaja: se identifican fácilmente como proxies, por lo que no son adecuados para plataformas protegidas.

Cuándo usar: Scraping de marketplaces, recopilación de datos de fuentes públicas, verificación de disponibilidad de recursos, solicitudes masivas a APIs de servicios sin protección estricta.

Configuración: Compra un pool de 50-100 IP, configura 20-30 flujos paralelos, cada flujo utiliza su propia IP. Rotación cada 100-200 solicitudes o en caso de error.

Proxies residenciales son más caros (desde $3-7 por 1 GB de tráfico), pero parecen usuarios reales. Son adecuados para consultas paralelas a plataformas protegidas, si necesitas velocidad, pero con precaución.

Cuándo usar: Scraping de redes sociales (sin autenticación), recopilación de datos de sitios con Cloudflare, trabajo con plataformas que bloquean centros de datos. Para consultas paralelas, necesitas un gran pool de IP con rotación automática.

Importante: Al hacer consultas paralelas a través de proxies residenciales, controla el consumo de tráfico. 10,000 solicitudes pueden "consumir" 5-10 GB, lo que costará entre $20-50. Los centros de datos son más baratos: tráfico ilimitado por $100-200/mes por 100 IP.

Proxies para consultas secuenciales

Proxies móviles son el tipo más confiable para trabajar con plataformas protegidas. Las IP parecen dispositivos móviles reales (operadores 4G/5G), lo que minimiza el riesgo de bloqueos. Desventaja: son caros (desde $50-150 por IP/mes).

Cuándo usar: Facebook Ads, Instagram, TikTok, Google Ads — todo donde se necesita máxima seguridad y simulación de un usuario real. Una cuenta = un proxy móvil = acciones secuenciales.

Configuración: Cada cuenta publicitaria o cuenta de red social está vinculada a una IP móvil separada. Las acciones son estrictamente secuenciales con retrasos de 10-60 segundos. La IP no se rota (una cuenta siempre trabaja desde una IP).

Proxies residenciales son una buena alternativa a los móviles si el presupuesto es limitado. Son adecuados para tareas menos críticas: scraping con autenticación, automatización de SMM, trabajo con marketplaces como vendedor.

Cuándo usar: Gestión de cuentas en marketplaces (Wildberries, Ozon como vendedor), automatización de publicaciones en redes sociales (no masiva), scraping de datos que requieren autenticación.

Recomendaciones para elegir proxies

Configuraciones óptimas: retrasos, flujos, timeouts

La configuración correcta de los parámetros es crítica para equilibrar velocidad y seguridad. Configuraciones demasiado agresivas llevarán a bloqueos, mientras que las demasiado cautelosas resultarán en pérdida de tiempo.

Configuración de consultas paralelas

Cantidad de flujos simultáneos (concurrency)
Este es un parámetro clave. Demasiados flujos = sobrecarga de proxies y del servidor objetivo. Demasiado pocos = baja velocidad.

Recomendaciones:

• Scraping de marketplaces: 20-50 flujos con un pool de 50+ proxies
• APIs públicas: 10-30 flujos, orientarse a los límites de la API
• Sitios con protección: 5-15 flujos, más = riesgo de bloqueo
• Verificación de proxies: 50-100 flujos (aquí la velocidad es más importante)

Retrasos dentro de los flujos
Incluso al trabajar en paralelo, cada flujo debe hacer pausas entre sus solicitudes. Esto reduce la carga en una IP y disminuye el riesgo de bloqueo.

Recomendaciones:

• Sitios simples: 0.5-2 segundos entre solicitudes en un flujo
• Marketplaces: 1-3 segundos con aleatorización ±30%
• Sitios con Cloudflare: 2-5 segundos con aleatorización ±40%
• APIs con límites: calcular según el límite (por ejemplo, 100 solicitudes/minuto = 0.6 seg/solicitud, hacer 1 seg para margen)

Timeouts (timeout)
Tiempo de espera para la respuesta del servidor. Un timeout demasiado corto = pérdida de datos debido a respuestas lentas. Uno demasiado largo = cuelgue de flujos.

Recomendaciones:

• Sitios rápidos: 10-15 segundos
• Sitios/API lentos: 20-30 segundos
• A través de proxies residenciales: +5-10 segundos (son más lentos que los de centros de datos)
• Connection timeout: 5-10 segundos (tiempo para establecer conexión)

Retry (reintentos)
En caso de errores (timeout, 503, bloqueo de proxy) es necesario repetir la solicitud con otra IP. Sin reintentos, perderás parte de los datos.

Configuración: 2-3 intentos por solicitud, cambio de proxy después de cada intento fallido, pausa de 3-5 segundos antes del retry.

Configuración de consultas secuenciales

Retraso base entre solicitudes
Depende de la plataforma y el tipo de acciones. La regla principal: simular un usuario real.

Recomendaciones por plataformas:

• Facebook Ads (transiciones entre secciones de la cuenta): 7-15 segundos
• Instagram (likes): 45-90 segundos, máximo 60 likes/hora
• Instagram (suscripciones): 60-120 segundos, máximo 30 suscripciones/hora
• TikTok (vistas): 30-60 segundos
• Scraping con autenticación: 3-7 segundos
• Marketplaces (acciones en la cuenta de vendedor): 5-10 segundos

Aleatorización
Es obligatoria para todas las consultas secuenciales. Usa una desviación ±30-50% del retraso base.

Ejemplo: Retraso base de 10 segundos, aleatorización ±40% → los retrasos reales serán de 6-14 segundos (valor aleatorio cada vez).

Timeouts
Para consultas secuenciales se pueden usar timeouts más largos, ya que no hay riesgo de bloqueo de todos los flujos.

Recomendaciones: 30-60 segundos para plataformas protegidas (Facebook, Instagram), 15-30 segundos para sitios normales.

Herramientas para implementar ambos métodos

La elección de la herramienta depende de tu tarea y habilidades técnicas. Para tareas empresariales (arbitraje, SMM, e-commerce) utiliza soluciones listas sin código. Para tareas técnicas — bibliotecas y frameworks.

Soluciones listas sin código (para negocios)

Navegadores anti-detección para multi-cuentas
Si trabajas con cuentas publicitarias o redes sociales, los navegadores anti-detección son el estándar de la industria. Gestionan automáticamente proxies, huellas del navegador y aíslan cuentas.

Soluciones populares:

• Dolphin Anty: líder para arbitrajistas de Facebook/TikTok, tarifa gratuita para 10 perfiles, fácil configuración de proxies
• AdsPower: bueno para e-commerce (Amazon, eBay), tiene automatización a través de RPA (sin código)
• Multilogin: el más caro ($100+/mes), pero máxima protección para arbitraje serio
• GoLogin: alternativa económica ($25/mes), adecuada para SMM y equipos pequeños

Cómo funcionan con proxies: Creas un perfil de navegador → vinculas proxies → todas las acciones en este perfil pasan por esta IP. Un perfil = una cuenta = acciones secuenciales. Para trabajar en paralelo, abres varios perfiles al mismo tiempo (cada uno con su proxy).

Scrapers y parsers (listos)
Para recopilar datos de marketplaces y sitios existen herramientas listas con GUI que no requieren programación.

• Octoparse: constructor visual de parsers, soporte para proxies, se pueden configurar flujos paralelos a través de la interfaz
• ParseHub: análogo de Octoparse, tarifa gratuita para 200 páginas, configuración de retrasos a través de GUI
• Scrapy Cloud: servicio en la nube para ejecutar spiders de Scrapy (requiere conocimientos mínimos de Python)

Automatización de SMM (sin código)
Para gestionar redes sociales hay servicios con automatización a través de la interfaz.

• Jarvee: automatización de Instagram, TikTok, Twitter, soporte integrado para proxies, configuración de retrasos a través de GUI (cuidado: automatización agresiva lleva a bloqueos)
• Ingramer (Inflact): automatización segura de Instagram, funciona a través de sus proxies
• Combin: suscripciones/likes dirigidos en Instagram, soporte para proxies externos

Herramientas técnicas (para desarrolladores)

Si escribes tus propios scripts para scraping o automatización, utiliza bibliotecas confiables.

Python (el más popular para scraping):

• Requests + threading/asyncio: para solicitudes paralelas simples, fácil de configurar proxies
• aiohttp: biblioteca asíncrona para solicitudes de alta paralelidad (1000+ al mismo tiempo)
• Scrapy: framework para scraping, soporte integrado para rotación de proxies, middleware para retrasos
• Selenium: para sitios con JavaScript, más lento, pero elude muchas protecciones
• Playwright: alternativa moderna a Selenium, más rápida y conveniente

JavaScript/Node.js:

• Axios: biblioteca popular para solicitudes HTTP, configuración simple de proxies
• Puppeteer: biblioteca para controlar Chrome, ideal para scraping de sitios con JavaScript
• Node-fetch: para solicitudes HTTP, fácil de usar con proxies