Español
Cómo resolver el error 429 «Demasiadas solicitudes»
Cómo resolver el error 429 «Too Many Requests»
El error HTTP 429 «Too Many Requests» es un código de respuesta de limitación de tasa enviado por un server cuando un usuario (o cliente) excede el número de solicitudes permitidas dentro de un período de tiempo determinado. Este estado suele formar parte de mecanismos de seguridad, protección de API o anti-DDoS.
En entornos de producción, puede interrumpir servicios, romper integraciones de API o afectar al SEO. Esta guía avanzada cubre cómo diagnosticar, prevenir y resolver el error 429 desde las perspectivas de cliente y servidor.
¿Qué causa el error 429?
Escenarios comunes:
Un usuario/bot está enviando demasiadas solicitudes HTTP (llamadas API, cargas de páginas, etc.)
Tu aplicación está haciendo scraping o polling de un servicio de terceros de forma demasiado agresiva
Los firewalls de aplicaciones web (WAFs) o proxies inversos (p. ej., Cloudflare, Nginx) aplican límites de tasa
Los API del servidor o backend usan bibliotecas de limitación de tasa (p. ej., express-rate-limit, mod_evasive, etc.)
Bots o crawlers inundan el sitio web o endpoint
Paso 1: Identificar la fuente
✅ 1. Verifica los Response Headers
Los servers a menudo envían un header Retry-After con una respuesta 429:
HTTP/1.1 429 Too Many Requests
Retry-After: 60Esto le indica al cliente cuánto tiempo esperar (en segundos) antes de intentarlo de nuevo.
✅ 2. Verifica los Access Logs
Para Apache:
cat /var/log/apache2/access.log | grep "429"Para Nginx:
cat /var/log/nginx/access.log | grep "429"Esto ayuda a identificar qué IPs o endpoints están activando el límite.
✅ 3. Usa herramientas de monitoreo
Logs de Fail2Ban
Eventos de Firewall de Cloudflare
Logs a nivel de aplicación (Laravel, Express, Django, etc.)
Analíticas de rate limit (si usas un API gateway)
Paso 2: Correcciones del lado del servidor
A. Nginx Rate Limiting (si está habilitado)
Nginx puede configurarse así:
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;location /api/ {limit_req zone=api_limit burst=10 nodelay;}Solución:
Aumenta rate o burst
Aplícalo a rutas específicas (p. ej., /api/) en lugar de globalmente
Incluye en la whitelist las IPs internas conocidas
B. Apache (mod_evasive or mod_security)
Si mod_evasive está activo:
sudo nano /etc/apache2/mods-enabled/evasive.confAjusta:
DOSPageCount 10
DOSSiteCount 100
DOSBlockingPeriod 10➡️ Aumenta los umbrales o desactívalo para IPs específicas de confianza.
C. Cloudflare / CDN Rules
Si estás detrás de Cloudflare, verifica:
Rate Limiting Rules en Security > WAF
Bot Fight Mode
Firewall Rules bloqueando según User-Agent o IP
Solución:
Reduce la sensibilidad
Incluye en la whitelist las IPs del server o ciertos user agents
Crea reglas personalizadas para crawlers y partners seguros
D. Application-Level Rate Limiting
Comprueba si tu app aplica límites usando bibliotecas como:
Node.js: express-rate-limit
Laravel: ThrottleRequests
Django: drf-extensions o middleware
Actualiza la configuración, como:
rateLimit({
windowMs: 1 * 60 * 1000, // 1 minute
max: 100, // limit each IP to 100 requests per minute
})➡️ Ajusta los límites, añade whitelist de user/IP o aumenta la cuota según los auth tokens.
Paso 3: Correcciones del lado del cliente (al consumir APIs)
Si tu aplicación es el cliente y recibe 429s:
✅ Implementa Exponential Backoff
Reintenta automáticamente las solicitudes con retrasos crecientes:
const retryAfter = (attempt) => Math.pow(2, attempt) * 1000;✅ Respeta los Retry-After Headers
if (response.status === 429) {
const wait = response.headers['retry-after'] * 1000;
setTimeout(() => retryRequest(), wait);
}✅ Añade Rate-Limiting al cliente
Limita tus propias solicitudes si haces polling:
// Use lodash or custom throttling
_.throttle(() => fetchData(), 1000);Paso 4: Consideraciones de SEO
Un estado 429 servido a search engine crawlers puede perjudicar tus rankings.
✅ Solución:
Sirve en su lugar un 503 (Service Unavailable) con Retry-After
Usa robots.txt para limitar la tasa de rastreo:
User-agent: *
Crawl-delay: 10En Cloudflare: ve a Bots > Crawl Management
Paso 5: Proteger sin bloquear a usuarios legítimos
En lugar de límites 429 estrictos:
Usa CAPTCHAs para actividad sospechosa
Implementa retrasos progresivos en lugar de un bloqueo total
Usa rate limiting basado en el usuario en lugar de basado en IP para usuarios con sesión iniciada
Ofrece acceso autenticado con límites de tasa más altos (p. ej., mediante API keys o tokens)
Conclusión
El error 429 Too Many Requests es una herramienta útil pero a veces disruptiva. Entender de dónde proviene —server, CDN o aplicación— es clave para resolverlo. Con una configuración adecuada, registros y respeto por los límites del lado del cliente, puedes equilibrar protección y usabilidad.
Entradas relacionadas
