Referencia de errores proxy · Códigos de estado HTTP

429 Too Many Requests al hacer scraping: qué significa y cómo solucionarlo

Q: ¿Cuánto tiempo debo esperar tras un 429?

Espera los segundos indicados en el encabezado Retry-After o hasta la fecha especificada. Sin encabezado, empieza con uno o dos segundos y duplica el retraso tras cada 429, con extra aleatorio y tope de un minuto. Reanuda a menor tasa, no a la que causó el 429.

Código de estado HTTP (4xx, error del cliente): el mensaje exacto en cada herramienta, las causas probables en orden y la solución que funciona.

Última actualización: 13 de octubre de 2026 · 5 minutos de lectura

Respuesta rápida

¿Qué significa 429 Too Many Requests con un proxy?

429 Too Many Requests significa que el sitio te limita la tasa: enviaste más solicitudes que las aceptadas en un intervalo. La solución es enviar menos, no esconder más. Con proxies residenciales de CrawlRelay, respeta el encabezado Retry-After, limita concurrencia por host y haz backoff exponencial con jitter aleatorio. Rotar IPs para superar límite publicado viola la mayoría de términos de uso.

429 Too Many Requests en pocas palabras

Error	429 Too Many Requests
Tipo	Código de estado HTTP (4xx, error del cliente)
Enviado por	El sitio destino o su gateway de API
Definido en	RFC 6585, section 4 (Retry-After: RFC 9110, section 10.2.3)
¿Reintentar?	Sí, después del retraso Retry-After o un backoff exponencial
Primera comprobación	Lee el encabezado Retry-After y tus solicitudes por segundo por host

¿Qué significa 429 Too Many Requests?

RFC 6585 introdujo el 429 para limitar tasa. El servidor puede añadir un encabezado Retry-After, ya sea segundos o fecha HTTP, para indicar cuándo volver. Las APIs a menudo añaden encabezados propios, como X-RateLimit-Remaining.

Un 429 es la respuesta más amable que un sitio puede dar a un scraper. Dice que el contenido está disponible, pero no a tu ritmo actual. Si los sitios ven que ignoran sus 429, suelen escalar a 403, CAPTCHAs o bloqueos permanentes.

¿Cómo se ve a 429 en Python, curl, Node.js y navegadores?

El mismo fallo se muestra de forma diferente en cada herramienta. Estos son los mensajes que debes buscar en tus registros:

Python requests / httpx: status_code == 429, frecuentemente con Retry-After: 30
Scrapy: manejado por RetryMiddleware, ya que 429 está en RETRY_HTTP_CODES por defecto
curl: HTTP/2 429 seguido de retry-after: en los encabezados de respuesta
APIs: un cuerpo JSON como {"error": "rate_limited"}

¿Qué causa a 429?

Lo más probable al principio:

Demasiada concurrencia por host. Cincuenta trabajadores paralelos en un dominio parecen un ataque para la mayoría de sitios.
Sin retrasos entre solicitudes, o retraso fijo que sincroniza varios trabajadores a la vez.
Reintentos sin backoff. Una tormenta de reintentos tras el primer 429 multiplica la carga.
Límites compartidos. Algunos sitios cuentan solicitudes por cuenta, clave API o cookie de sesión, no por IP.
Endpoints pesados. URLs de búsqueda o filtros suelen tener límites más estrictos que páginas estáticas.

¿Cómo diagnostico a 429 paso a paso?

Registra el valor Retry-After y cualquier encabezado de límite de tasa al primer 429.
Mide tu tasa real de solicitudes por host, no la tasa total.
Verifica si el límite sigue IP, cookie o clave API: cambia uno a la vez.
Lee la API del sitio o documentación robots.txt; una línea Crawl-delay indica el ritmo que piden.

Prueba la URL que falla con curl (puerto HTTP, modo detallado)

# Use the URL that fails; with https://api.ipify.org instead, you test the gateway alone.
# "HTTP/1.1 200 Connection established" first, then the site's own status: the site answered.
curl -v -x http://USERNAME:[email protected]:7777 https://TARGET_URL

# Same test through the SOCKS5 port, with DNS resolved at the exit
curl -v --socks5-hostname gw.crawlrelay.com:7778 --proxy-user USERNAME:PASSWORD https://TARGET_URL

¿Cómo soluciono a 429?

Respeta Retry-After. Espera al menos el tiempo indicado por el servidor.
Limita concurrencia por host, no solo globalmente. Scrapy tiene CONCURRENT_REQUESTS_PER_DOMAIN y AUTOTHROTTLE_ENABLED.
Haz backoff exponencial con jitter: 1 s, 2 s, 4 s, etc., más fracción aleatoria, con un tope máximo.
Consulta menos. Cachea respuestas, envía If-Modified-Since o If-None-Match, y salta páginas sin cambios.
Usa la API oficial cuando el sitio la ofrece; sus límites suelen estar documentados.

Python: reintentar con Retry-After, backoff exponencial y jitter

import random
import time

import requests

PROXY = "http://USERNAME:[email protected]:7777"
PROXIES = {"http": PROXY, "https": PROXY}
RETRY_STATUSES = {429, 502, 503, 504}


def fetch(url, attempts=5, timeout=(10, 30)):
    for attempt in range(attempts):
        try:
            r = requests.get(url, proxies=PROXIES, timeout=timeout)
        except (requests.exceptions.ConnectionError, requests.exceptions.Timeout):
            r = None  # dropped exit, reset or timeout: a new connection gets a new exit
        if r is not None and r.status_code not in RETRY_STATUSES:
            return r
        retry_after = r.headers.get("Retry-After", "") if r is not None else ""
        if retry_after.isdigit():
            wait = int(retry_after)
        else:
            wait = min(60, 2 ** attempt) + random.uniform(0, 1)
        time.sleep(wait)
    raise RuntimeError("giving up on %s after %d attempts" % (url, attempts))

¿Debo reintentar después de a 429?

Sí, un 429 se debe reintentar después. Espera el retraso Retry-After si el servidor lo envía; si no usa backoff exponencial con jitter y límite. Cuenta 429 consecutivos por host y reduce la concurrencia al crecer. La función Python siguiente hace lo básico.

¿Cómo se aplica 429 Too Many Requests a CrawlRelay?

Un 429 que recibes vía CrawlRelay trae encabezados y cuerpo del objetivo: el límite es del sitio y el ritmo por host es tu responsabilidad. Usa sesiones persistentes cuando el sitio cuente solicitudes por sesión, así tu ritmo es medible; consulta la guía de concurrencia para números iniciales.

Gateway: gw.crawlrelay.com, puerto 7777 (HTTP, HTTPS a través de CONNECT) y puerto 7778 (SOCKS5). Formato de usuario: USERNAME-country-{cc}-state-{state}-city-{city}-zip-{zip}-asn-{asn}-session-{id}-ttl-{minutes}. Relacionado: 403 Forbidden · 503 Service Unavailable · Guía de concurrencia.

429 Too Many Requests: preguntas que hacen los desarrolladores

¿Debo rotar IPs para evitar errores 429?

No. Un 429 es la solicitud del sitio para frenar. Distribuir tu tasa en más IPs para evitar límite por IP es evasión y casi todos los términos de uso lo prohíben. Rotar sirve para repartir carga y ubicación, no para sobrepasar un límite publicado. Reduce tu tasa y cachea.

¿Cuánto tiempo debo esperar tras un 429?

Espera los segundos indicados en el encabezado Retry-After o hasta la fecha especificada. Sin encabezado, empieza con uno o dos segundos y duplica el retraso tras cada 429, con extra aleatorio y tope de un minuto. Reanuda a menor tasa, no a la que causó el 429.

¿Por qué recibo 429 con pocas solicitudes por minuto?

El límite puede ser por cuenta, cookie o clave API, no por IP; o el endpoint es caro, como búsqueda. Algunos sitios también ponen límites bajos a clientes que clasifican como bots. Revisa los encabezados y la API del sitio, y solicita acceso si necesitas más.

Otros errores de proxy en esta referencia

Códigos de estado HTTP

Errores de navegador y cliente

Errores de conexión y TLS

Proxies residenciales con documentación que cubre los casos de fallo

CrawlRelay proxies residenciales de 0,50 US$/GB, tráfico que nunca expira.

Ver precios Inicio rápido