Raspado Cortés Que Aún Escala: Un Manual de Limitación de Tasa
Golpear un sitio te hace ser bloqueado; rastrear una solicitud a la vez no te lleva a ninguna parte. El punto medio escalable es el ritmo adaptativo por dominio, distribuido a través de IPs limpias — cortés con el sitio, rápido para ti.
Casi la mitad de todo el tráfico de Internet ahora es automatizado, y los sitios web lo saben. La limitación de tasa es su primera y más básica defensa — un límite de velocidad que decide cuánto puedes tomar y qué tan rápido. La tentación es tratarlo como un obstáculo para romper con fuerza bruta, pero eso te hace ser bloqueado. El error opuesto, rastrear una solicitud cuidadosa a la vez, no te lleva a ninguna parte a escala. La respuesta escalable es raspado cortés: ajusta el ritmo de cada objetivo como lo haría un usuario legítimo pero pesado, distribuye la carga a través de IPs limpias, y deja que las propias respuestas del sitio ajusten tu velocidad. Así es como te mantienes rápido sin convertirte en el tráfico que bloquea a todos.
Saber qué límite estás alcanzando
Los servidores cuentan tus solicitudes contra un identificador — generalmente tu IP, a veces una clave API o cuenta — durante una ventana de tiempo, y actúan cuando cruzas un umbral. Los tres modelos comunes se comportan de manera diferente: una ventana fija cuenta solicitudes por minuto calendario; un cubo de tokens te da un número fijo de tokens (digamos 100 por minuto) y gasta uno por solicitud, forzando una espera cuando el cubo se vacía; una ventana deslizante cuenta durante los últimos 60 segundos continuos en cualquier instante. La consecuencia práctica es que un estallido es más peligroso que un flujo constante — diez solicitudes en un segundo pueden activar un límite que cien distribuidas en un minuto no lo harían.
Los límites también vienen en sabores. Los límites suaves son gentiles: el servidor te ralentiza, o devuelve 429 Too Many Requests con una cabecera Retry-After diciéndote exactamente cuánto tiempo esperar (el Error 1015 de Cloudflare es esto). Algunos sitios toleran pequeños estallidos — permitiendo 100 por minuto pero solo limitando a 120 — mientras que otros limitan temprano, digamos a 15 por minuto, y solo bloquean duramente a 30. Los límites duros son techos estrictos: una API que permite 1,000 solicitudes por hora te bloquea completamente una vez que lo excedes. Empuja un límite suave repetidamente y este escala: 429 se convierte en 403, luego una prohibición temporal de minutos a horas cuya ventana crece cada vez que lo activas, y finalmente una lista negra permanente de tu IP o subred completa.
Lee la respuesta, no adivines
La mayor mejora para un raspador es reaccionar a lo que el servidor te dice en lugar de disparar a una tasa fija. Aprende el vocabulario: 429 significa desacelerar y respetar Retry-After; 403 significa que esta identidad está marcada, así que rota en lugar de reintentar; 503 es a menudo un desafío o rechazo temporal; y un 200 que devuelve una página CAPTCHA es un bloqueo suave, no un éxito. Trata cada uno de manera diferente. El movimiento equivocado — reintentar la misma IP quemada en un 403, o ignorar Retry-After y seguir golpeando en un 429 — es lo que convierte una advertencia suave en una prohibición permanente. Nuestros análisis profundos sobre cómo solucionar 429s cubren el manejo de respuestas en detalle.
import time, requests
def polite_get(session, url, max_tries=4):
for attempt in range(max_tries):
r = session.get(url, timeout=20)
if r.status_code == 200 and "captcha" not in r.text.lower():
return r
if r.status_code == 429: # obey the server
wait = int(r.headers.get("Retry-After", 2 ** attempt))
time.sleep(wait)
continue
if r.status_code in (403, 503): # this exit is burned
rotate_ip(session) # fresh IP, then retry
time.sleep(2 ** attempt) # exponential backoff
continue
return r
return None
Presupuesta solicitudes por dominio
Un rastreador que toca muchos sitios nunca debe aplicar una tasa global a todos ellos. Un pequeño blog y un mercado endurecido toleran cargas muy diferentes, así que da a cada dominio su propio presupuesto. Un cubo de tokens por host es el patrón limpio: asigna una tasa conservadora por dominio, rellénalo con el tiempo, y deja que las solicitudes a diferentes hosts se ejecuten en paralelo mientras las solicitudes al mismo host se mantienen dentro de su límite. Comienza despacio en un nuevo objetivo y deja que los códigos de respuesta te digan si puedes acelerar.
import time
from collections import defaultdict
class DomainLimiter:
def __init__(self, per_min=30):
self.gap = 60.0 / per_min # min seconds between hits per host
self.last = defaultdict(float)
def wait(self, host):
now = time.time()
delay = self.gap - (now - self.last[host])
if delay > 0:
time.sleep(delay)
self.last[host] = time.time()
# 30 req/min to any single host; different hosts proceed independently
limiter = DomainLimiter(per_min=30)
limiter.wait("example.com")Distribuye la carga para que cada IP se mantenga cortés
Aquí está el movimiento que reconcilia "cortés" con "escala": la cortesía se mide por IP, pero tu rendimiento total es la suma a través de IPs. Si un objetivo tolera 30 solicitudes por minuto por dirección, una IP te limita a 30 — pero diez IPs limpias, cada una haciendo 30, te dan 300 por minuto mientras cada salida individual se mantiene cortés. Un gateway residencial rotativo hace esto automáticamente, entregando una IP nueva por solicitud a través de más de 90M de direcciones para que ninguna salida individual parezca agresiva. Esto no es un truco para golpear más fuerte; es distribuir la carga genuina para que ningún servidor soporte un pico sospechoso. Los fundamentos de la rotación de IP están en qué es la rotación de IP y por qué importa.
Distribuye la carga a través de IPs limpias y rotativas
Toma menos, cachea más, elige tus horas
La solicitud más cortés es la que nunca envías. Tres hábitos reducen la carga sin costarte datos. Primero, cachea agresivamente y usa solicitudes condicionales — envía If-Modified-Since o If-None-Match para que una página sin cambios devuelva un pequeño 304 en lugar del cuerpo completo, lo que ahorra al servidor y a tu ancho de banda. Segundo, presupuesta la concurrencia deliberadamente: un semáforo que limite las solicitudes en vuelo por dominio evita que explotes accidentalmente. Tercero, programa trabajos pesados para las horas fuera de pico del objetivo, cuando tu tráfico es una parte menor del suyo y menos probable de activar un umbral. Combinados, estos pueden reducir a la mitad las solicitudes que un trabajo necesita — la disciplina detrás de nuestra lista de verificación anti-bloqueo más amplia.
Una cosa más que vale la pena decir claramente: revisa robots.txt y respeta las expectativas de rastreo declaradas de un sitio. La cortesía no es solo autopreservación — ser un buen ciudadano mantiene la web abierta para todos. Nuestra guía sobre robots.txt en la práctica cubre lo que hace y no hace vinculante.
Preguntas frecuentes
¿Cómo evito la limitación de tasa al hacer scraping?
Ajusta el ritmo de cada dominio con su propio presupuesto de solicitudes, respeta Retry-After en 429s, retrocede exponencialmente, y distribuye la carga a través de un grupo rotativo de IPs limpias para que ninguna dirección parezca agresiva. Añade caché y solicitudes condicionales para enviar menos solicitudes en general, y programa trabajos pesados para las horas fuera de pico del objetivo.
¿Qué significa HTTP 429 y cómo debo manejarlo?
429 Too Many Requests es un límite de tasa suave — el servidor te está pidiendo que desaceleres, no que te está bloqueando. Lee la cabecera Retry-After y espera exactamente ese tiempo antes de reintentar; si está ausente, retrocede exponencialmente. Nunca lo ignores y sigas golpeando, porque los 429s repetidos escalan a 403s y luego a prohibiciones temporales o permanentes.
¿Cuántas solicitudes por minuto son seguras?
No hay un número universal — depende completamente del objetivo. Un sitio pequeño puede tolerar solo unas pocas solicitudes por minuto; uno grande, muchas más. Comienza de manera conservadora (digamos 20–30 por minuto por IP), observa los 429s, y ajusta a partir de las respuestas. Escala el rendimiento total añadiendo IPs, no aumentando la tasa en una sola.
¿Los proxies rotativos cuentan como descorteses?
No cuando se usan para distribuir carga genuina. La rotación mantiene cada IP individual dentro de una tasa cortés mientras tu rendimiento agregado crece — el servidor nunca ve un pico sospechoso de ninguna dirección. Se vuelve descortés solo si lo usas para exceder lo que el sitio puede manejar razonablemente en total; ajusta el ritmo del agregado, no solo la tasa por IP.
Cortés y escalable no son opuestos. Lee las señales, respeta Retry-After, presupuesta por dominio, cachea lo que puedas, y distribuye el resto a través de IPs limpias y rotativas. Terminas siendo más rápido que el raspador imprudente — porque eres el que nunca es bloqueado.