← Volver al blog
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

Error "Demasiadas Solicitudes" 429: cómo eludir los límites mediante proxies y rotación de IP

Analizamos las causas del error 429 Too Many Requests y mostramos 5 formas de eludir los límites a través de proxies: desde la rotación de IP hasta la configuración del User-Agent y los retrasos entre solicitudes.

📅31 de diciembre de 2025
```html

Si te dedicas a raspar marketplaces, monitorear precios de competidores o automatizar el trabajo en redes sociales, seguramente te has encontrado con el error 429 Too Many Requests. El sitio bloquea tus solicitudes, considerándolas sospechosas, y toda la automatización se detiene. En este artículo, analizaremos por qué surge este problema y cómo resolverlo mediante la configuración adecuada de proxies, rotación de IP y una distribución inteligente de la carga.

Te mostraremos soluciones concretas para diferentes tareas: raspado de Wildberries y Ozon, monitoreo de competidores, trabajo con API de redes sociales, recolección masiva de datos. Todas las recomendaciones se basan en la experiencia práctica y funcionan en proyectos reales.

Qué es el error 429 Too Many Requests y por qué ocurre

El error 429 Too Many Requests es un código de respuesta HTTP que el servidor devuelve cuando superas el número permitido de solicitudes en un período de tiempo determinado. Es un mecanismo de protección de los sitios contra la sobrecarga y la recolección automatizada de datos.

Situaciones típicas en las que ocurre el 429:

  • Raspado de marketplaces — estás recolectando precios de Wildberries, Ozon o Avito, haciendo cientos de solicitudes por minuto. El sitio detecta actividad anómala desde una sola IP y la bloquea.
  • Monitoreo de competidores — recolección automática de datos sobre productos, precios, disponibilidad. Con verificaciones frecuentes se activa el límite.
  • Trabajo con API — muchas API tienen restricciones estrictas: por ejemplo, la API de Instagram permite 200 solicitudes por hora, Twitter — 300 solicitudes en 15 minutos.
  • Registro masivo o acciones — creación de cuentas, envío de mensajes, likes. Las plataformas detectan rápidamente la automatización y bloquean la IP.

Es importante entender: el error 429 no es solo una limitación técnica. Es una señal de que el sitio ha reconocido tu actividad como sospechosa. Si continúas atacando desde la misma IP, puedes recibir un baneo permanente.

Importante: Algunos sitios en lugar de 429 devuelven 403 Forbidden o simplemente muestran un captcha. La esencia es la misma: has superado los límites y te han bloqueado.

Cómo los sitios determinan la actividad sospechosa

Para eludir bloqueos de manera efectiva, es necesario entender cómo exactamente los sitios te detectan. Los sistemas de protección modernos analizan muchos parámetros:

1. Dirección IP y frecuencia de solicitudes

El parámetro más obvio. Si desde una sola IP llegan 100 solicitudes por minuto, mientras que un usuario normal hace 5-10 — eso es una clara automatización. Los sitios establecen límites:

  • Wildberries: aproximadamente 60 solicitudes por minuto desde una IP
  • Ozon: alrededor de 30-40 solicitudes por minuto
  • Avito: límites estrictos, especialmente para consultas de búsqueda
  • API de Instagram: 200 solicitudes por hora por aplicación

2. User-Agent y encabezados del navegador

Si envías solicitudes a través de un script sin un User-Agent adecuado, el sitio entiende de inmediato que no se trata de un navegador real. También se analizan los encabezados: Accept, Accept-Language, Referer. La ausencia de estos encabezados o valores atípicos — es una señal de alerta.

3. Patrones de comportamiento

Un usuario real no hace solicitudes con una periodicidad perfecta cada 2 segundos. Él desplaza, hace clics, toma pausas. Si tu parser funciona como un metrónomo — eso es sospechoso.

4. Tipo de dirección IP

Muchas plataformas mantienen listas negras de IP de centros de datos. Si usas proxies baratos de AWS o Google Cloud, la probabilidad de bloqueo es mayor. Las IP residenciales de proveedores reales generan menos sospechas.

Rotación de proxies: la principal forma de eludir los límites

La principal solución al problema 429 es la rotación de direcciones IP. En lugar de hacer todas las solicitudes desde una sola IP, distribuyes la carga entre múltiples direcciones. Cada IP realiza una pequeña cantidad de solicitudes y no supera los límites.

Tipos de rotación de proxies

Tipo de rotación Cómo funciona Cuándo usar
Rotación por solicitud Cada solicitud proviene de una nueva IP. El proveedor de proxies cambia la dirección automáticamente. Raspado masivo, cuando necesitas recolectar muchos datos rápidamente
Rotación por temporizador La IP cambia cada 5-30 minutos. Usas una dirección para una serie de solicitudes. Trabajo con sitios que requieren sesiones (carrito, autorización)
Grupo de proxies estáticos Tienes una lista de 100-1000 IP. El script elige aleatoriamente una dirección para cada solicitud. Cuando necesitas control total sobre la rotación y distribución de la carga

Ejemplo práctico: raspado de Wildberries

Supongamos que necesitas raspar precios de 10,000 productos. Wildberries bloquea después de 60 solicitudes por minuto desde una IP. Cómo resolver:

  1. Usa rotación por solicitud — cada solicitud proviene de una nueva IP. Necesitas aproximadamente 167 IP diferentes (10,000 solicitudes / 60 por minuto = 167 minutos con una IP, pero con rotación lo haces en 10-15 minutos).
  2. Configura retrasos — incluso con rotación, no debes hacer 1000 solicitudes por segundo. Óptimo: 5-10 solicitudes por segundo con diferentes IP.
  3. Agrega aleatorización — los retrasos deben ser aleatorios: de 0.5 a 2 segundos entre solicitudes.

Para tales tareas, los proxies residenciales con rotación automática son ideales: tienen grupos de millones de IP y cambian las direcciones en cada solicitud sin tu intervención.

Configuración de retrasos entre solicitudes

Incluso con rotación de proxies, no se puede bombardear el sitio con solicitudes a la máxima velocidad. Los sistemas de protección modernos analizan la carga total en el servidor y pueden bloquear todo el rango de IP si ven actividad similar a un DDoS.

Reglas para configurar retrasos

Regla básica: imita a un usuario real

  • Retraso mínimo: 0.5-1 segundo entre solicitudes
  • Recomendado: 1-3 segundos con dispersión aleatoria
  • Para sitios complejos (marketplaces, redes sociales): 2-5 segundos
  • Usa retraso exponencial en caso de errores

Retraso exponencial (exponential backoff)

Si aún así recibes el error 429, no continúes atacando el sitio. Usa la estrategia de retraso exponencial:

  • Primer intento fallido → espera 1 segundo
  • Segundo intento fallido → espera 2 segundos
  • Tercer intento fallido → espera 4 segundos
  • Cuarto intento fallido → espera 8 segundos
  • Y así sucesivamente, hasta un máximo (por ejemplo, 60 segundos)

Esta estrategia le da al servidor tiempo para "enfriarse" y reduce la probabilidad de un baneo permanente. Muchas API (Google, Twitter) recomiendan este enfoque en su documentación.

Ejemplo de configuración para diferentes tareas

Tarea Retraso entre solicitudes Comentario
Raspado de Wildberries 1-3 segundos Con rotación de proxies se puede acelerar a 0.5-1 seg
Raspado de Ozon 2-4 segundos Ozon es más sensible a la automatización
API de Instagram 18 segundos Límite de 200 solicitudes/hora = 1 solicitud cada 18 seg
Raspado de Google Search 5-10 segundos Google banea rápidamente, se necesitan pausas largas
Monitoreo de Avito 3-6 segundos Protección estricta, especialmente para búsquedas

User-Agent y encabezados: imitación de un navegador real

La rotación de proxies y los retrasos resuelven el problema de la frecuencia de solicitudes, pero eso no es suficiente. Los sitios analizan cómo envías las solicitudes. Si los encabezados parecen sospechosos, el bloqueo es inevitable.

Encabezados obligatorios para imitar un navegador

El conjunto mínimo de encabezados que debe estar presente en cada solicitud: 

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: es-ES,es;q=0.9,en-US;q=0.8,en;q=0.7
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Cache-Control: max-age=0

Rotación de User-Agent

No uses el mismo User-Agent para todas las solicitudes. Crea una lista de 10-20 versiones actuales de navegadores y cámbialas aleatoriamente:

  • Chrome (Windows, macOS, Linux)
  • Firefox (diferentes versiones)
  • Safari (macOS, iOS)
  • Edge (Windows)

Error común: Uso de User-Agents obsoletos (por ejemplo, Chrome 90 en 2024) o User-Agents móviles para sitios de escritorio. Esto revela instantáneamente la automatización.

Referer y Origin

Muchos sitios verifican de dónde proviene la solicitud. Si estás raspando una página de producto, en el encabezado Referer debe haber un enlace al catálogo o búsqueda. Si raspas una API, debe haber un Origin correcto.

Ejemplo para raspado de Wildberries: 

Referer: https://www.wildberries.ru/catalog/0/search.aspx?search=portátil
Origin: https://www.wildberries.ru

Qué proxies elegir para eludir el 429

La elección del tipo de proxy es críticamente importante. Los proxies baratos de centros de datos a menudo ya están en listas negras, y recibirás 429 incluso con una baja frecuencia de solicitudes.

Comparación de tipos de proxies para eludir límites

Tipo de proxy Ventajas Desventajas Para qué tareas
Centros de datos Alta velocidad, bajo precio A menudo baneados, fáciles de detectar Sitios simples sin protección
Residenciales IP reales de proveedores, difíciles de detectar, gran grupo de direcciones Más caros, a veces más lentos Marketplaces, redes sociales, sitios complejos
Móviles IP de operadores móviles, máxima confianza Caros, grupo limitado Instagram, TikTok, Facebook Ads

Recomendaciones para la elección

Para el raspado de marketplaces (Wildberries, Ozon, Avito): Usa proxies residenciales con rotación por solicitud. El grupo debe ser grande — al menos 10,000 IP. Esto garantiza que cada IP haga pocas solicitudes y no caiga bajo los límites.

Para trabajar con API de redes sociales: Los proxies móviles son la mejor opción. Instagram y TikTok confían más en las IP de operadores móviles que en las residenciales. Una IP móvil puede atender de 5 a 10 cuentas sin problemas.

Para el monitoreo de precios de competidores: Proxies residenciales con rotación por temporizador (cada 10-15 minutos). Esto permite hacer una serie de solicitudes desde una IP, manteniendo la sesión, pero sin exceder los límites.

Para tareas simples (raspado de noticias, blogs): Los proxies de centros de datos pueden funcionar si el sitio no tiene una protección seria. Pero prepárate para bloqueos periódicos.

Casos reales: raspado de marketplaces y API

Caso 1: Monitoreo de precios en Wildberries (10,000 productos diariamente)

Tarea: Un vendedor de marketplace rastrea los precios de competidores en 10,000 posiciones. Necesita recolectar datos 2 veces al día.

Problema: Al usar una sola IP, recibía un baneo después de 50-60 solicitudes. Raspando 10,000 productos tomaba varias horas con bloqueos constantes.

Solución:

  1. Conecté proxies residenciales con un grupo de 50,000 IP y rotación por solicitud
  2. Configuré retrasos aleatorios de 0.5 a 2 segundos entre solicitudes
  3. Agregué rotación de User-Agent (20 variantes de Chrome y Firefox)
  4. Configuré los encabezados Referer y Accept correctamente

Resultado: Raspado de 10,000 productos toma 15-20 minutos sin un solo bloqueo. Cada IP hace un máximo de 1-2 solicitudes, lo que es imposible de detectar como automatización.

Caso 2: Automatización de Instagram (50 cuentas de clientes)

Tarea: Una agencia de SMM gestiona 50 cuentas de clientes en Instagram. Necesita publicar contenido, responder a comentarios, recolectar estadísticas.

Problema: La API de Instagram tiene un límite de 200 solicitudes por hora por aplicación. Al trabajar con 50 cuentas, los límites se agotaban en 10 minutos.

Solución:

  1. Crearon 10 aplicaciones diferentes de la API de Instagram (5 cuentas por aplicación)
  2. Cada aplicación utiliza un proxy móvil separado
  3. Configuraron un retraso de 18 segundos entre solicitudes (200 solicitudes/hora = 1 solicitud cada 18 seg)
  4. Agregaron retraso exponencial al recibir 429

Resultado: Todas las 50 cuentas funcionan de manera estable. Los errores 429 ocurren muy raramente (1-2 veces a la semana) y se manejan automáticamente a través de reintentos.

Caso 3: Raspado de Avito (anuncios en toda Rusia)

Tarea: Un agregador de bienes raíces recolecta anuncios de Avito en todas las ciudades de Rusia para su base de datos.

Problema: Avito tiene una de las protecciones más estrictas entre los sitios rusos. Los bloqueos comenzaban después de 10-15 solicitudes incluso desde diferentes IP de centros de datos.

Solución:

  1. Cambio a proxies residenciales con geolocalización (IP de la misma ciudad que el raspado)
  2. Aumento de los retrasos a 3-5 segundos entre solicitudes
  3. Uso de un navegador sin cabeza (Puppeteer) en lugar de simples solicitudes HTTP
  4. Emulación de acciones del usuario: desplazamiento, clics, movimientos del mouse

Resultado: Raspado exitoso de más de 50,000 anuncios al día. Los bloqueos se redujeron en un 95%. El 5% restante se maneja a través de reintentos con una nueva IP.

Caso 4: Monitoreo de API de competidores (e-commerce)

Tarea: Una tienda en línea rastrea la disponibilidad de productos y precios de 20 competidores a través de sus API.

Problema: La mayoría de las API de competidores tienen límites públicos (100-500 solicitudes por hora). Al exceder, devuelven 429.

Solución:

  1. Creación de una cola de solicitudes con prioridades (los productos más importantes se verifican con más frecuencia)
  2. Monitoreo de límites a través de encabezados de respuesta (X-RateLimit-Remaining)
  3. Pausa automática al alcanzar el 80% del límite
  4. Uso de múltiples claves API para cada competidor (donde sea posible)

Resultado: El sistema distribuye automáticamente las solicitudes de manera que nunca se superen los límites. Los datos se actualizan con la máxima frecuencia posible sin bloqueos.

Lección general de todos los casos:

El error 429 se resuelve de manera integral: rotación de proxies + retrasos adecuados + imitación de comportamiento real. No se puede confiar solo en un método. Incluso con un millón de IP, te bloquearán si haces 1000 solicitudes por segundo con encabezados sospechosos.

Conclusión

El error 429 Too Many Requests es un mecanismo de protección de los sitios que se puede eludir con el enfoque correcto. Los principios clave para resolver el problema son:

  • Rotación de direcciones IP — distribuye la carga entre múltiples proxies, de modo que cada dirección haga el mínimo de solicitudes
  • Retrasos adecuados — imita a un usuario real con pausas aleatorias de 1 a 5 segundos
  • Encabezados correctos — usa User-Agent actual y un conjunto completo de encabezados de navegador
  • Elección del tipo de proxy — para sitios complejos (marketplaces, redes sociales) usa proxies residenciales o móviles
  • Gestión de errores — aplica retraso exponencial al recibir 429, no ataques al sitio nuevamente

Recuerda: el objetivo no es engañar a la protección a toda costa, sino que tu automatización parezca lo más natural posible. Los sistemas de protección modernos se vuelven cada vez más inteligentes, y la fuerza bruta deja de funcionar.

Si planeas trabajar con raspado de marketplaces, monitoreo de competidores o automatización en redes sociales, te recomendamos probar proxies residenciales — proporcionan un gran grupo de direcciones IP, rotación automática y un riesgo mínimo de bloqueos. Para trabajar con Instagram, TikTok y otras plataformas móviles, los proxies móviles con IP de operadores reales son más adecuados.

```