Error 429 Too Many Requests en scraping: límite por IP, espera y cuándo lo resuelve un proxy

Una recogida de datos que funcionaba bien empieza a devolver 429 Too Many Requests. Es el servidor diciendo, sin ambigüedad, que has superado el ritmo aceptado. La reacción instintiva (reintentar al instante o cambiar de IP) a veces empeora la situación. El primer paso es averiguar qué se está limitando.

Qué quiere decir el 429

El código 429 indica que el cliente ha enviado demasiadas peticiones en un intervalo de tiempo. No es un error de tu código ni una caída del sitio: es un control de ritmo.

Muchos servidores envían junto con él la cabecera Retry-After, con el tiempo de espera antes del siguiente intento, en segundos o como una fecha. Cuando viene, es la información más valiosa de la respuesta.

Primero: ¿el límite es por qué?

Una prueba rápida: lanza la misma petición, en el mismo momento, desde otra red. Si allí pasa y desde aquí no, el límite probablemente es por dirección.

Espera progresiva: qué hacer en cualquier caso

Sea cual sea la causa, la recogida tiene que reaccionar al 429 sin machacar el servidor:

import time, random, requests

def obtener(url, proxies, intentos=5):
    espera = 2
    for _ in range(intentos):
        r = requests.get(url, proxies=proxies, timeout=30)
        if r.status_code != 429:
            return r
        retry = r.headers.get("Retry-After")
        pausa = int(retry) if retry and retry.isdigit() else espera
        time.sleep(pausa + random.uniform(0, 1))
        espera *= 2
    return r

Lo que hace el código:

1. Respeta el Retry-After cuando el servidor lo indica.
2. Sin Retry-After, duplica la espera en cada intento.
3. Añade una pequeña variación aleatoria, para que varias tareas no vuelvan todas en el mismo instante.
4. Se detiene tras unos cuantos intentos, en lugar de insistir para siempre.

Cuándo resuelve repartir entre varias IP

Si el límite es por dirección, concentrar toda la recogida en una sola IP es lo que genera el 429. Repartir las peticiones entre muchas direcciones reduce la tasa en cada una:

• Páginas públicas, sin inicio de sesión → residencial rotativo por GB, que cambia la dirección por petición o por sesión (en ProxyBox, con IP de Brasil).
• Destino que acepta IPv6 → lote de IPv6, con la rotación hecha por tu aplicación.
• Destino que acepta datacenter y volumen alto → lote de MIX IPv4.

Aunque repartas, mantén la espera progresiva: protege la recogida cuando se limita una dirección concreta.

Cuándo no cambiar de IP

• Rutinas con sesión iniciada. Cambiar de IP en mitad de la sesión hace que la cuenta parezca saltar de un sitio a otro. Aquí la respuesta es cola y espera con IP fija.
• API con clave. El límite es de la clave. Más IP solo generan más 429.
• Términos del servicio. Si el sitio limita la recogida en sus términos de uso o en el robots.txt, repartir IP para esquivarlo no es un ajuste técnico. Respeta el robots.txt, los términos y la ley, y nuestra política de uso aceptable.

Tampoco es cosa del proxy resolver captchas ni bloqueos que el sitio pone a propósito: si aparecen, es la señal de que el ritmo o el método no son aceptables para ese destino.

Cuidado con el consumo

En el residencial se cobra por GB. Una recogida que repite peticiones por culpa del 429 paga el tráfico de los reintentos. Una espera bien hecha y peticiones más ligeras reducen el coste; los ajustes están en consumo de GB en scraping con proxy.

El 429 en sitios concretos

Los grandes sitios combinan límites por IP, por cuenta y por comportamiento, y cada uno tiene sus propios términos. Lo que permiten y dónde encaja un proxy lo vemos caso a caso en scraping de Amazon y en scraping de Google Maps.

Resumen

1. Lee el Retry-After e implementa una espera progresiva.
2. Averigua si el límite es por IP, por cuenta, por clave o global.
3. Solo con límite por IP, reparte entre direcciones.
4. En una rutina con sesión iniciada, IP fija con cola.

Qué producto usar para cada tipo de recogida, y cómo elegir entre residencial, IPv6 y datacenter, está en proxy para web scraping.