Error 429 al analizar: 6 razones además del proxy.

¿Cambia proxies, compra un nuevo grupo de direcciones IP, pero el analizador sigue fallando con el error 429 Too Many Requests? Esta es una situación clásica: el 70% de los casos de bloqueo no están relacionados con la dirección IP, sino con la forma en que se ve la solicitud. Analizamos seis razones reales por las que el sitio sigue bloqueándote incluso después de cambiar el proxy — y qué hacer en cada caso.

Qué significa el error 429 y por qué el proxy no es una panacea

El código HTTP 429 Too Many Requests significa formalmente "se ha superado el límite de solicitudes". Pero en la práctica, los sitios — especialmente Wildberries, Ozon, Avito, Yandex.Market — utilizan este código como una señal universal de "creemos que eres un bot". La razón puede estar en la frecuencia de las solicitudes, pero con la misma probabilidad puede estar en los encabezados, la huella del navegador, la falta de sesión de cookies o en los límites que no están vinculados a la IP, sino a tu cuenta.

Es por eso que cambiar el proxy a menudo no ayuda: si el sistema bloquea no la IP, sino el patrón de la solicitud (huella, encabezados, velocidad de clics), entonces desde una nueva dirección IP recibirás el mismo 429 en un par de minutos. Analizaremos cada razón en detalle y mostraremos cómo verificarla y solucionarla sin comprar un nuevo grupo de proxies.

Importante: los proxies siguen siendo una herramienta necesaria — pero solo como parte de un sistema, y no como la única solución. Las IP residenciales y móviles reducen la probabilidad de ser incluidos en listas negras por reputación de IP, pero no salvan de bloqueos por comportamiento o encabezados.

Razón 1: Frecuencia de solicitudes demasiado alta

La razón más obvia, pero también la más mal diagnosticada. Muchos piensan: "ya que cambio el proxy en cada solicitud, la frecuencia no importa". Esto es incorrecto. Los sistemas modernos de anti-bots (por ejemplo, Wildberries y Ozon utilizan soluciones de nivel Cloudflare o sus propios WAF) analizan no solo la frecuencia desde una IP, sino también la carga total en un endpoint API o en la página del producto en un período de tiempo desde todas las fuentes en conjunto con señales de comportamiento.

Si tu analizador hace 50-100 solicitudes por segundo a la misma sección del catálogo, el sistema ve un aumento anómalo de tráfico independientemente de cuántas IP diferentes estés utilizando. La solución no es cambiar el proxy, sino implementar retrasos artificiales (throttling) entre las solicitudes: 1-3 segundos de retraso aleatorio en lugar de un intervalo fijo, más un backoff exponencial al recibir un 429 (aumento de la pausa al doble después de cada bloqueo).

import time, random

def safe_request(session, url):
    for attempt in range(5):
        response = session.get(url)
        if response.status_code == 429:
            wait = (2 ** attempt) + random.uniform(0, 1)
            time.sleep(wait)
            continue
        return response
    return None

Si utilizas un analizador listo sin código (por ejemplo, un servicio en la nube para monitorear precios), verifica la configuración del intervalo entre solicitudes — en la mayoría de estas herramientas hay un control deslizante "velocidad de escaneo". Reducir la velocidad en un 30-40% a menudo elimina completamente el 429, incluso sin cambiar el proxy.

Razón 2: Encabezados incorrectos o faltantes

Muchos analizadores envían solicitudes con un conjunto mínimo de encabezados o utilizan la cadena User-Agent de la biblioteca por defecto (por ejemplo, "python-requests/2.28.1"). Tal encabezado revela instantáneamente un bot — un navegador real envía decenas de encabezados: Accept, Accept-Language, Accept-Encoding, Sec-Fetch-*, Referer y otros en un orden específico.

Wildberries y Ozon comparan el conjunto de encabezados con la "huella" esperada de un navegador real como Chrome o Safari. Si hay muy pocos encabezados, no están en el orden correcto o el User-Agent no coincide con los demás parámetros (por ejemplo, se declara Chrome en Windows, pero la huella TLS es similar a Python) — la solicitud se bloquea en 429 independientemente de la IP.

Encabezado	Error típico	Solución
User-Agent	Versión obsoleta o cadena claramente de biblioteca	UA actual de Chrome/Safari real, rotación desde el grupo
Accept-Language	Faltante o no coincide con la geolocalización de la IP	ru-RU para marketplaces rusos
Referer	Vacío, aunque la transición real siempre tiene Referer	Especificar la página anterior del catálogo
Sec-Fetch-*	Completamente ausentes (no cliente de navegador)	Copiar el conjunto completo desde DevTools de un navegador real

Lo más sencillo es copiar el conjunto completo de encabezados desde la pestaña Network en DevTools de un navegador real, abriendo la página deseada manualmente, y usar precisamente ese conjunto en el analizador — teniendo en cuenta el orden de los encabezados, si la biblioteca lo permite (por ejemplo, curl_cffi o httpx con orden explícito).

Razón 3: Falta de rotación de sesiones y cookies

Un error que a menudo se pasa por alto: el analizador cambia la IP en cada solicitud, pero utiliza la misma sesión de cookies o no guarda cookies en absoluto. Un usuario real recibe un conjunto de cookies en su primera visita (tokens de sesión, identificadores de dispositivo, etiquetas de protección antibot tipo Cloudflare __cf_bm o similares en Ozon/WB) y las utiliza en todas las solicitudes posteriores dentro de la sesión.

Si envías una solicitud sin cookies obtenidas en una página "calentada", el sistema anti-bots ve una sesión "nula" — y esto es inmediatamente sospechoso, especialmente al acceder a endpoints API directamente, omitiendo la página principal. La solución es emular el escenario completo: primero cargar la página principal o la página de categoría, obtener cookies, esperar 1-2 segundos, y solo después hacer la solicitud a la API o a la tarjeta del producto, manteniendo las cookies en la misma sesión a lo largo de la cadena de solicitudes.

import requests

session = requests.Session()
session.headers.update({
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
    "Accept-Language": "ru-RU,ru;q=0.9"
})

# Calentando la sesión
session.get("https://www.wildberries.ru/catalog/0/search.aspx")
time.sleep(1.5)

# Solicitud principal ya con cookies
response = session.get(target_url)

Si utilizas un navegador anti-detección como Dolphin Anty o AdsPower para monitorear manualmente las tarjetas de productos o a través de automatización integrada, asegúrate de que el perfil guarde cookies entre sesiones y no se inicie cada vez "desde cero" — esto también activa la sospecha del sistema.

Razón 4: Comportamiento similar al de un bot

Incluso con encabezados y cookies perfectos, el analizador puede delatarse por patrones de comportamiento: un orden estrictamente lineal al acceder a los productos (en orden ascendente de ID), el mismo intervalo entre solicitudes hasta el milisegundo, la ausencia de solicitudes "basura" a recursos estáticos (imágenes, CSS, JS), que un navegador normal carga automáticamente.

Los sistemas de protección avanzados de Wildberries y Ozon analizan no solo las solicitudes HTTP, sino también si se ha ejecutado JavaScript en la página (a través de detección sin cabeza), si se ha movido el "ratón", si ha habido desplazamiento. Si realizas solicitudes HTTP limpias sin renderizar JS, y el sitio espera la ejecución de un script para obtener un token (por ejemplo, un desafío de JavaScript anti-bot), la solicitud sin la ejecución de este script automáticamente recibe 429 o 403.

La solución depende de la escala: para volúmenes pequeños, es adecuado utilizar un navegador sin cabeza (Playwright, Puppeteer) con emulación de movimientos del ratón y retrasos aleatorios. Para el análisis industrial — aleatorización del orden de navegación de productos, adición de "ruido" en forma de solicitudes a recursos secundarios, variabilidad de intervalos de tiempo según una distribución normal, y no en pasos fijos.

Razón 5: Huella TLS/JA3 y HTTP/2

Esta es la razón técnica más "invisible", de la que el 90% de las personas que realizan análisis sin una preparación técnica profunda no son conscientes. Cada cliente TLS (biblioteca requests, curl, urllib) deja una huella única al establecer una conexión HTTPS — un conjunto de cifrados soportados, versiones de protocolo, extensiones TLS. Esta huella se llama huella JA3/JA4.

Los sistemas anti-bots de nivel Cloudflare, Akamai y las propias soluciones de grandes marketplaces comparan la huella JA3 con una base de datos de bots y bibliotecas conocidas. La biblioteca estándar de Python requests o el módulo https de Node.js tienen una huella fácilmente detectable, completamente diferente de la huella de un Chrome real. Incluso con encabezados y cookies perfectos, la solicitud se bloquea precisamente a nivel de TLS-handshake, antes de que el servidor vea los encabezados HTTP.

Además, muchos marketplaces requieren HTTP/2 con ciertos parámetros (orden de tramas SETTINGS, priorización de flujos) — las bibliotecas basadas en HTTP/1.1 se destacan automáticamente en este contexto. La solución es utilizar bibliotecas que emulen la huella de un navegador real: curl_cffi (emula la huella TLS de Chrome), tls-client, o navegadores sin cabeza completos basados en Chromium, que proporcionan una huella "real" por definición.

pip install curl_cffi

Ejemplo: curl_cffi.requests.get(url, impersonate="chrome120") — la biblioteca automáticamente inserta la huella TLS, idéntica a la de Chrome 120 real.

Razón 6: Límite a nivel de cuenta o clave API

Si trabajas a través de una API oficial o semi-oficial del marketplace (por ejemplo, la API del vendedor de Wildberries o la API del vendedor de Ozon), el 429 puede estar vinculado no a la IP, sino a la cuenta del vendedor o al token API. En este caso, cambiar el proxy es completamente inútil — el límite se almacena en el servidor vinculado a tu identificador de cuenta, y cualquier IP de esa cuenta recibirá la misma restricción.

Esta situación es típica para los vendedores que monitorean simultáneamente los precios de los competidores a través de su panel personal y hacen llamadas a la API para descargar existencias — ambos flujos de solicitudes se suman al límite total de la cuenta. La solución es distribuir la carga a lo largo del tiempo, utilizar las cuotas API oficiales de manera más económica (almacenar en caché datos que no cambian cada minuto), y para el monitoreo puro de precios de competidores, utilizar un flujo de solicitudes no autorizado separado, no vinculado a la cuenta del vendedor.

Verificar esto es sencillo: si el 429 continúa incluso al hacer una solicitud desde una nueva IP limpia y sin una sola cookie de sesiones anteriores, pero estás logueado en el panel en una pestaña adyacente — lo más probable es que el límite sea a nivel de cuenta.

Cómo diagnosticar la verdadera razón

Antes de cambiar la infraestructura, realiza un diagnóstico siguiendo el siguiente algoritmo. Primero, abre la página manualmente en un navegador normal y asegúrate de que no aparece el 429 con un comportamiento real — esto confirmará que el problema está del lado del analizador, y no es un bloqueo global de la región.

Luego, compara los encabezados de tu analizador con los encabezados de un navegador real a través de DevTools (pestaña Network → Copy as cURL). Si la diferencia es mínima, verifica la huella TLS a través de servicios como tls.peet.ws — envía una solicitud con tu biblioteca y compara el hash JA3 con el de un navegador de referencia. Si la solicitud falla en la etapa de TLS-handshake (la conexión se rompe antes de recibir la respuesta HTTP) — la razón está en la huella, no en la frecuencia o los encabezados.

A continuación, verifica si el límite está vinculado a la IP o a la cuenta: haz una solicitud desde una nueva IP limpia sin autorización. Si el 429 desaparece — el problema estaba en la reputación de la IP anterior o en la frecuencia desde esa dirección. Si el 429 persiste — busca la razón en los encabezados, TLS o comportamiento, y no en el proxy.

Lista de verificación para solucionar el 429 sin cambiar el proxy

Agrega retrasos aleatorios de 1-4 segundos entre solicitudes en lugar de un intervalo fijo.
Copia el conjunto completo de encabezados de un navegador real, incluyendo Sec-Fetch-* y Accept-Language.
Guarda y pasa cookies dentro de una misma sesión, comenzando con el calentamiento de la página principal.
Verifica la huella TLS de tu biblioteca — utiliza curl_cffi o un navegador sin cabeza en lugar de un cliente HTTP puro.
Aleatoriza el orden de navegación de las páginas y agrega solicitudes "ruido" a recursos estáticos.
Separa la carga de la cuenta API y el monitoreo anónimo de precios en diferentes flujos.
Implementa un backoff exponencial al recibir un 429, y no una repetición instantánea de la solicitud.
Solo después de verificar todos los puntos anteriores — cambia el proxy o amplía el grupo de IP.

Cuándo se necesitan proxies y cuáles elegir

Después de eliminar todas las seis razones, los proxies siguen siendo un elemento importante de la infraestructura — pero ya como medio de escalamiento, y no como la única forma de combatir bloqueos. Si tu tarea es monitorear en paralelo miles de tarjetas de Wildberries y Ozon desde diferentes "usuarios virtuales", necesitas un grupo de IP con buena reputación, para no acumular un historial de bloqueos en una sola dirección.

Para el monitoreo masivo de precios y catálogos de marketplaces, los proxies residenciales son los más adecuados — utilizan IP reales de proveedores domésticos, por lo que los sistemas anti-bots perciben las solicitudes como tráfico de compradores normales, y no de centros de datos. Esto es crítico, ya que Wildberries y Ozon han mantenido listas negras de rangos de IP de centros de datos durante mucho tiempo.

Si la tarea está relacionada con la verificación de la versión móvil del sitio, el trabajo a través de la aplicación del marketplace o la prueba de publicidad en TikTok Ads y Facebook Ads con precisión geográfica hasta la ciudad, son relevantes los proxies móviles — tienen el nivel máximo de confianza en la mayoría de los sistemas de protección, ya que las IP pertenecen a operadores de telefonía móvil reales.

Para tareas menos sensibles — por ejemplo, análisis de catálogos abiertos sin autorización en volúmenes pequeños — se pueden utilizar proxies de centros de datos: son significativamente más baratos y rápidos, pero requieren una configuración más cuidadosa de los encabezados y la huella TLS, ya que por sí mismos conllevan un mayor riesgo de ser sospechosos.

Tipo de proxy	Cuándo resuelve el 429	Cuándo no ayudará
Residenciales	IP ya en lista negra por reputación	Bloqueo por huella TLS o encabezados
Móviles	Se necesita la máxima confianza de IP para escenarios sensibles	Límite vinculado a la cuenta, no a la IP
Centro de datos	Análisis simple de páginas abiertas sin autorización	Sistemas anti-bots estrictos con verificación de reputación de rangos

Conclusión

El error 429 al analizar rara vez se resuelve con un solo botón "cambiar proxy". En la mayoría de los casos, el problema radica en la frecuencia de solicitudes, encabezados incompletos, falta de sesión de cookies, huella TLS detectable, patrones de comportamiento o límites vinculados a la cuenta, no a la dirección IP. Realiza un diagnóstico en cada uno de los seis puntos de este artículo antes de gastar el presupuesto en ampliar el grupo de proxies.

Cuando la parte técnica está configurada correctamente — los encabezados coinciden con un navegador real, la huella TLS no revela la biblioteca, y las solicitudes imitan el comportamiento natural del usuario — los proxies se convierten en una herramienta realmente efectiva para escalar. Para el monitoreo de precios en Wildberries y Ozon a gran escala, recomendamos comenzar con proxies residenciales: ofrecen el mejor equilibrio entre costo y nivel de confianza de los sistemas anti-bots.