Corrección de errores · 2 min de lectura

Cómo solucionar 429 Demasiadas Solicitudes al hacer scraping

Un 429 es un límite de tasa, no una prohibición — el servidor te está pidiendo que reduzcas la velocidad. La solución duradera combina retroceso, respetar Retry-After y distribuir la carga a través de un grupo de IPs. Aquí está cómo, con Python funcional.

429 es un límite de velocidad, no una pared

HTTP 429 Demasiadas Solicitudes significa que has enviado demasiadas solicitudes en un período determinado y el servidor te está limitando. Es deliberadamente temporal; a diferencia de un bloqueo duro, un 429 generalmente se elimina una vez que reduces la velocidad. Muchos servidores incluyen un Retry-After encabezado que te dice exactamente cuántos segundos esperar; respetarlo es la solución más efectiva, porque te alinea con el propio límite del servidor en lugar de adivinar.

There are two levers. The first is rate: send fewer requests per second per IP, add delays, cap concurrency, and back off exponentially when a 429 appears. The second is distribution: spread requests across multiple IPs so each stays under the per-IP limit. Rate control is where you should start — a proxy pool multiplies your throughput but does not excuse hammering a site. s4m provides authenticated datacenter proxies (SOCKS5 1080, HTTP 3128, USER:PASS) to spread load, and this pairs directly with the proxy rotation guide and scraping with requests.

Respeta Retry-After, retrocede y luego rota

Un bucle de recuperación que respeta Retry-After, retrocede exponencialmente con jitter y se distribuye a través de un grupo de proxies. Reemplaza USER:PASS.

python
import random, time
import requests

USER, PASS, HOST = "USER", "PASS", "proxy.s4m.online"
POOL = [
    f"socks5h://{USER}:{PASS}@{HOST}:1080",
    f"http://{USER}:{PASS}@{HOST}:3128",
]

def polite_get(url, max_tries=6):
    for attempt in range(1, max_tries + 1):
        proxy = random.choice(POOL)
        r = requests.get(url, proxies={"http": proxy, "https": proxy},
                         timeout=(5, 20))
        if r.status_code != 429:
            r.raise_for_status()
            return r

        # 429: prefer the server's Retry-After, else exponential backoff
        retry_after = r.headers.get("Retry-After")
        if retry_after and retry_after.isdigit():
            wait = int(retry_after)
        else:
            wait = min(2 ** attempt, 60) + random.random()  # cap + jitter

        print(f"[{attempt}/{max_tries}] 429; waiting {wait:.1f}s")
        time.sleep(wait)

    raise SystemExit(f"still rate-limited after {max_tries} tries")

# Global throttle: cap how fast you fire, independent of retries.
MIN_INTERVAL = 0.5  # seconds between requests per worker
_last = 0.0
def throttled_get(url):
    global _last
    delta = time.time() - _last
    if delta < MIN_INTERVAL:
        time.sleep(MIN_INTERVAL - delta)
    _last = time.time()
    return polite_get(url)

print(throttled_get("https://httpbin.org/status/200").status_code)

La orden para arreglar un 429

Las soluciones más baratas y respetuosas primero.

Honrar Retry-After

Si la respuesta 429 incluye un encabezado Retry-After, espera exactamente ese tiempo antes de volver a intentar. Es el servidor diciéndote su límite; seguirlo elimina la mayoría de los 429 de inmediato.

Agrega retroceso exponencial con jitter

Cuando no hay Retry-After, espera 2, 4, 8… segundos (con un límite) más un pequeño jitter aleatorio entre reintentos, para que dejes de golpear y evites reintentos sincronizados.

Limita tu tasa de solicitudes

Limita las solicitudes por segundo y la concurrencia para que te mantengas por debajo del límite en primer lugar. Un rastreo constante y más lento termina de manera más confiable que un estallido que sigue siendo restringido.

Distribuir carga entre IPs

Una vez que tu comportamiento por solicitud sea educado, rota a través de un grupo de proxies para que cada IP se mantenga por debajo del límite por IP. Esto multiplica el rendimiento seguro sin aumentar la tasa en ninguna dirección única.

Por qué la rotación sola no es la respuesta

Es tentador tratar a los proxies como una forma de ignorar los límites de tasa: solo agrega más IPs y sigue disparando. Eso sale mal. Un sitio que devuelve 429 está observando los patrones de solicitud, y una inundación de un conjunto cambiante de direcciones que golpean los mismos puntos finales en el mismo instante es en sí misma una firma detectable que se traduce en prohibiciones severas. La rotación multiplica el rendimiento educado; no reemplaza la cortesía. Siempre combina un grupo de proxies con retroceso, Retry-After, un ritmo realista y una concurrencia sensata.

Honestamente, algunos límites están destinados a ser respetados: verifica si existe una API oficial o una tasa documentada antes de escalar alrededor de un 429, y lee los términos de cada sitio. Cuando realmente necesites distribución, los proxies de datacenter autenticados de s4m distribuyen la carga y están medidos, por lo que ampliar el grupo es barato; para los mecanismos, consulta la guía de rotación. Recuerda que las IPs de datacenter aún pueden ser marcadas en su totalidad, y la rotación no hace nada respecto a las huellas digitales. Prototipa de manera económica con la lista de proxies gratuita y valida las salidas con las herramientas.

FAQ

Preguntas, respondidas

¿Es un 429 una prohibición permanente?

No. HTTP 429 Demasiadas Solicitudes es un límite de tasa temporal — generalmente se despeja una vez que desaceleras. Honra cualquier encabezado Retry-After, añade retroceso y reduce tu tasa de solicitudes, y el acceso típicamente se reanuda.

¿Cuál es la solución más efectiva para un 429?

Respetando el encabezado Retry-After cuando el servidor envía uno. Te dice exactamente cuánto tiempo esperar, para que te alinees nuevamente con el límite del servidor en lugar de adivinar y ser limitado nuevamente.

¿Detendrán los proxies rotativos los errores 429?

Ayuda manteniendo cada IP bajo el límite por IP, pero solo junto con retroceso y limitación. La rotación sin un ritmo educado produce una inundación detectable que escala a bloqueos más difíciles, así que combina ambos.

¿Son suficientes los proxies s4m para eludir cualquier límite de tasa?

Ninguna herramienta honesta puede prometer eso. Los proxies de datacenter s4m distribuyen la carga entre IPs, pero aún necesitas retroceder y limitar, los rangos de datacenter pueden ser marcados, y algunos límites simplemente deben ser respetados a través de una API oficial.

Distribuye la carga de manera honesta

Combina retrocesos y limitación con proxies de centro de datos autenticados en proxy.s4m.online para mantener cada IP por debajo del límite. Pago por uso medido, IP dedicada opcional.

Las personas encontraron esta página buscando

Frases de búsqueda reales que esta página responde — los enlaces abren la página que las cubre en profundidad.