429 demasiadas solicitudes: soluciones para web scraping y APIs de IA

Imagina un scraper recopilando páginas públicas de productos a través de proxies de CyberYozh App, luego enviando el texto extraído a una API de IA para su análisis. A mitad del trabajo, se detiene con «429 demasiadas solicitudes». La respuesta tentadora es reintentar, pero primero necesitas averiguar dónde falló la solicitud.

¿Devolvió el error el sitio web, un servicio intermediario o la API de IA? Cada uno puede aplicar límites diferentes, por lo que cambiar la configuración incorrecta puede dejar el problema sin resolver.

Durante la recopilación, verifica el ritmo de las solicitudes, las conexiones concurrentes y si el límite se aplica a una IP o sesión. CyberYozh App te permite controlar los cambios de IP del proxy y el comportamiento de la sesión en esta etapa. Durante el procesamiento de IA, verifica en su lugar las asignaciones de solicitudes y tokens del proveedor. Esta guía recorre ambas etapas para que puedas identificar la restricción, aplicar la solución correcta y evitar repetir trabajo que ya tuvo éxito.

TL;DR

• 429 demasiadas solicitudes significa que un servicio está aplicando un límite de tasa o uso. No significa automáticamente que tu proxy esté defectuoso o permanentemente bloqueado.

• Encuentra primero la fuente: el sitio web de destino, un servicio intermediario o la API de IA. Inspecciona el cuerpo de la respuesta y los encabezados.

• Reduce la velocidad y reintenta con cuidado. Respeta Retry-After, coordina los workers, reduce la concurrencia y usa backoff con jitter y un conteo máximo de intentos.

• Guarda el trabajo completado. Reintenta el paso de recopilación o análisis fallido sin reiniciar todo el flujo de trabajo.

• Verifica los límites de solicitudes de IA, asignaciones de tokens y cuotas por separado. Cambiar IPs no aumenta las asignaciones de cuenta.

• Ajusta la infraestructura de proxies a los requisitos de recopilación. CyberYozh App proporciona geotargeting, sesiones sticky de hasta 24 horas y tráfico ilimitado.

¿Qué significa 429 demasiadas solicitudes?

Un error 429 demasiadas solicitudes significa que un servicio está limitando solicitudes adicionales porque has alcanzado uno de sus umbrales de uso. Por lo general, esto implica enviar demasiadas solicitudes dentro de una ventana de tiempo particular. La respuesta por sí sola no te dice qué límite se alcanzó o cuánto durará la restricción.

Para entender qué significa «429 demasiadas solicitudes» para tu flujo de trabajo, verifica cómo el servicio cuenta la actividad. Como la documentación 429 de MDN explica, los límites pueden aplicarse a través de un servidor, a un recurso particular, o según una dirección IP, usuario autenticado o aplicación. Varios workers pueden por lo tanto compartir una asignación incluso cuando cada uno envía relativamente pocas solicitudes.

Un 429 no establece, por sí mismo, un bloqueo permanente ni prueba que tu proxy esté defectuoso. La conexión puede estar funcionando mientras el destino rechaza solicitudes adicionales. Cambiar IPs no restablecerá un límite vinculado a la misma cuenta autenticada.

Inspecciona el cuerpo de la respuesta y los encabezados para obtener detalles sobre la restricción, incluyendo cualquier instrucción Retry-After, antes de elegir tu próxima acción.

Descubre qué servicio está devolviendo el error

Volvamos al ejemplo de la página de producto: ¿falló la recopilación antes de que el texto llegara a la API de IA, o se detuvo el análisis después de que se guardaran las páginas?

En un navegador, abre las herramientas de desarrollador, selecciona el panel Network e inspecciona la solicitud con estado 429. En Postman, revisa el estado de la respuesta, los encabezados y el cuerpo. En los registros de la aplicación, relaciona el fallo con su marca de tiempo y paso del flujo de trabajo.

Registra el nombre de host, el cuerpo de la respuesta, los encabezados relevantes, la marca de tiempo y el ID de solicitud cuando estén disponibles. Elimina contraseñas, claves de API, valores de autorización y cookies de sesión antes de compartir registros de diagnóstico.

Cómo solucionar el error 429 too many requests

Una vez que identifiques el servicio que devuelve el 429, deja que los detalles de la respuesta guíen la solución. Sigue estos pasos antes de reiniciar el trabajo completo.

1. Pausar los intentos repetidos
   Pause el trabajo afectado y luego verifique los workers en segundo plano, las tareas programadas y las ejecuciones duplicadas. Si comparten la misma cuota, coordine también su pausa; detener un script puede dejar la mayor parte del tráfico sin cambios.

2. Respetar el encabezado Retry-After
   Retry-After: 60 significa esperar al menos 60 segundos. Una fecha HTTP especifica cuándo volver a intentarlo. La documentación de Retry-After de MDN explica ambos formatos. Cuando el encabezado está ausente, consulte los límites documentados del servicio y use retrasos de reintento crecientes en lugar de asumir un período de espera universal.

3. Reducir la frecuencia de solicitudes y la concurrencia
   Frecuencia significa solicitudes enviadas a lo largo del tiempo; concurrencia significa solicitudes ejecutándose simultáneamente. Controle ambas. Los workers que comparten una cuota necesitan un ritmo coordinado, como una cola compartida con un limitador de velocidad, porque los retrasos individuales no controlan su tráfico combinado.

4. Usar backoff exponencial con jitter
   Aumente los retrasos después de fallos repetidos y agregue jitter, una pequeña variación aleatoria que ayuda a los workers a evitar reintentar juntos. Establezca un recuento máximo de intentos y verifique el comportamiento de reintento existente del cliente o SDK antes de agregar otro bucle. Nunca acorte la espera solicitada por el servidor.

5. Eliminar solicitudes innecesarias
   Deduplique las URL en cola, almacene en caché las respuestas exitosas cuando esté permitido y reduzca el polling cuando los datos frescos sean innecesarios. Guarde las páginas completadas para que una solicitud fallida no reinicie todo el trabajo de recopilación.

Este ejemplo GET de Python maneja ambos formatos de encabezado, recurre al backoff para valores faltantes o mal formados, y se detiene después de cinco intentos fallidos:

import random
import time
from datetime import timezone
from email.utils import parsedate_to_datetime

import requests


def get_with_backoff(url):
    for attempt in range(5):
        response = requests.get(url, timeout=30)
        if response.status_code != 429:
            response.raise_for_status()
            return response
        if attempt == 4:
            response.raise_for_status()

        value = response.headers.get("Retry-After", "").strip()
        delay = 2 ** attempt
        try:
            if value.isascii() and value.isdigit():
                delay = max(delay, int(value))
            elif value:
                retry_at = parsedate_to_datetime(value)
                if retry_at.tzinfo is None:
                    retry_at = retry_at.replace(tzinfo=timezone.utc)
                delay = max(delay, retry_at.timestamp() - time.time())
        except (ValueError, TypeError, OverflowError):
            pass  # Invalid header: keep the backoff delay.

        response.close()
        time.sleep(delay + random.uniform(0, 1))

Corregir errores 429 recurrentes en web scraping

Los errores 429 recurrentes requieren una revisión del cronograma general del trabajo de recopilación. Cuente las solicitudes en todos los workers dirigidos al mismo sitio web, especialmente cuando comparten una dirección IP, cuenta o credencial de API. Coordine los workers que comparten un límite a través de un limitador de velocidad común y aplique períodos de enfriamiento en todo el grupo afectado cuando ocurra la limitación.

La automatización del navegador puede generar más tráfico del que sugiere su script. Abrir una página de producto puede desencadenar solicitudes de imágenes, scripts, recomendaciones y actualizaciones en segundo plano. Inspeccione el panel Network del navegador para ver qué llega realmente al objetivo. Omita recursos innecesarios solo cuando hacerlo preserve el comportamiento de la página y los datos que necesita.

Deduplique las URL en cola mientras preserva las diferencias intencionadas, como tiendas regionales o variantes de productos. Guarde las respuestas exitosas y registre qué elementos han finalizado. En el ejemplo de la página de producto inicial, si la recopilación se detiene a mitad del catálogo, reanude desde el elemento fallido después de la espera requerida. Las páginas ya recopiladas deben permanecer disponibles para el procesamiento de IA sin ser descargadas nuevamente.

Preserve la continuidad de sesión cuando las solicitudes relacionadas dependan de las mismas cookies, cuenta o dirección IP. Base la rotación de proxy en los requisitos de conexión de la tarea y el límite identificado; un 429 por sí solo no es una razón para cambiar direcciones. Programe la recopilación en torno a las cuotas documentadas del objetivo y reduzca el polling cuando la información del producto no necesite actualizaciones frecuentes.

Corregir errores 429 en APIs de IA y flujos de trabajo de agentes

Su scraper puede recopilar cada página de producto con éxito, y luego encontrar un 429 cuando envía los resultados para análisis. Finalizar un lote de recopilación puede desencadenar una ráfaga de llamadas al modelo, cada una consumiendo parte de la cuota de solicitudes o tokens del proveedor de IA.

Verifique qué cuota alcanzó. La documentación de límites de velocidad de Claude distingue solicitudes por minuto, tokens de entrada por minuto y tokens de salida por minuto. Los tokens son las unidades que el modelo usa para procesar texto. Algunas entradas grandes pueden por lo tanto alcanzar un límite de tokens incluso cuando el número de solicitudes parece modesto. Verifique los límites aplicables a su cuenta y modelo.

Ponga en cola los trabajos de análisis y libérelos a un ritmo controlado. Si varios agentes comparten una cuota de organización o proyecto, coordine su uso combinado. Reducir la entrada innecesaria y solicitar salida concisa también puede reducir el consumo de tokens, mientras que el ritmo evita que los lotes de scraping completados abrumen la etapa de procesamiento.

Una entrada de registro como last status: 429 too many requests registra el estado HTTP final; el diagnóstico aún depende de la respuesta subyacente. Inspeccione el tipo de error del proveedor, el mensaje, el ID de solicitud y los encabezados de límite, luego compárelos con la información de uso y facturación. Un límite de velocidad temporal y una cuota agotada requieren acciones diferentes. Claude, por ejemplo, documenta una respuesta de límite de gasto de nivel mensual que continúa fallando hasta que se reanuda el acceso.

Mantenga las páginas recopiladas guardadas independientemente del trabajo de análisis. Cuando falla una solicitud de IA, reintente solo ese paso de procesamiento después de abordar la restricción. Verifique el comportamiento de reintento existente del SDK para que un flujo de trabajo externo no reinicie repetidamente llamadas que el cliente ya está reintentando.

Si la respuesta entra en conflicto con el uso observado, verifique la página de estado del servicio del proveedor e investigue otras cargas de trabajo que compartan la cuota. Conserve la marca de tiempo y el ID de solicitud para soporte. Cambiar la IP del proxy del scraper no aumentará los límites de solicitudes o tokens de la cuenta de IA.

Dónde encaja CyberYozh App en el flujo de trabajo de scraping

Una vez que el diagnóstico identifica una necesidad de acceso regional, continuidad de sesión o mejor control sobre las conexiones de recopilación, CyberYozh App proporciona varias opciones de infraestructura. Haga coincidir la conexión con la tarea, incluido cuánto tiempo las solicitudes relacionadas necesitan mantener la misma IP.

• Proxies móviles: Tráfico ilimitado en planes reales LTE/4G/5G mantiene los costos de ancho de banda predecibles para la recopilación continua. Los planes dedicados reservan el canal móvil para tu carga de trabajo, mientras que los planes compartidos usan un canal junto con otros clientes. Las conexiones dedicadas ofrecen cambios de IP manuales y basados en API, permitiéndote programar cambios según los límites de las tareas. 

• Proxies residenciales rotativos: Usa segmentación regional para recopilar listados o precios dependientes de la ubicación. Elige rotación para tareas de recopilación independientes o sesiones persistentes de hasta 24 horas cuando las solicitudes relacionadas necesiten consistencia temporal de IP. El tráfico se factura por uso, con tráfico no utilizado que se transfiere al siguiente mes de facturación.

• Proxies ISP estáticos: Una dirección fija durante el período de alquiler se adapta a sesiones de recopilación recurrentes que requieren la misma IP. Esto proporciona continuidad entre ejecuciones separadas sin depender de una sesión persistente temporal.

• Proxies de datacenter dedicados: Estos proporcionan una conexión de datacenter fija para cargas de trabajo donde el objetivo acepta ese tipo de red. Pueden adaptarse a trabajos de recopilación rutinarios que no requieren una conexión residencial o móvil.

CyberYozh App admite conexiones proxy en Scrapy, Postman, Playwright, Puppeteery Selenium. El acceso completo a la API permite que los scripts gestionen las operaciones de proxy compatibles junto con tu código de recopilación existente.