El cliente envía solicitudes demasiado rápido.
Cuándo usarlo
Limitación de frecuencia. Incluye una cabecera Retry-After.
Causas habituales y soluciones
Has alcanzado un límite de frecuencia. Lee la cabecera Retry-After, en segundos o como fecha HTTP, y cualquier cabecera RateLimit o X-RateLimit-Remaining, y luego espera con retrasos exponenciales y jitter en lugar de reintentar de inmediato. Orígenes habituales: cuotas de API por clave o IP, reglas de limitación de frecuencia de Cloudflare, limitación de intentos de inicio de sesión y limit_req de nginx, que devuelve 503 a menos que definas limit_req_status 429.
Muchos usuarios detrás de un mismo NAT o proxy corporativo pueden activar juntos un límite por IP. Si ejecutas el limitador detrás de un balanceador de carga, usa como clave la IP real del cliente de X-Forwarded-For, o todos los usuarios compartirán la dirección y la cuota del balanceador. En el lado del cliente, agrupa las solicitudes, guarda las respuestas en caché y añade un retraso aleatorio a las tareas programadas para que no se disparen todas en el mismo segundo.
Error del cliente (4xx)
Los códigos 4xx son errores del cliente: la solicitud en sí es incorrecta, no está autorizada o apunta a algo que no existe. Repetir la misma solicitud no servirá de nada.
Cómo se ve
HTTP/1.1 429 Too Many RequestsCómo enviarlo
| Node.js / Express | res.status(429).end() |
|---|---|
| Python / Flask | return '', 429 |
| nginx | return 429; |
Cómo comprobarlo
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/