HTTP 429 Too Many Requests: espera y luego reintenta bien
HTTP 429 Too Many Requests
HTTP 429 Too Many Requests: Retry-After y backoff | We.Inc
Qué significa un estado 429, cómo leer Retry-After y código de reintentos con backoff exponencial y jitter. Planifica tu propio calendario de reintentos con la calculadora.
Una respuesta 429 significa que el servidor te está aplicando rate limiting: este cliente envió más peticiones de las que permite en una ventana de tiempo. Deja de enviar durante un rato. Si la respuesta trae una cabecera Retry-After, espera ese tiempo; si no, reintenta con backoff exponencial más jitter aleatorio para que muchos clientes no reintenten al unísono.
Cómo leer una respuesta 429
Parte
Qué dice
Qué debe hacer tu cliente
Estado 429
Demasiadas peticiones en un tiempo determinado
Pausar este cliente, no insistir sin parar
Retry-After: 120
Espera 120 segundos (forma de retraso en segundos)
Esperar al menos ese tiempo
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT
Espera hasta esa hora (forma de fecha HTTP)
Restar la hora actual y luego esperar
Sin Retry-After
El servidor no dio ninguna pista
Aplicar backoff exponencial con jitter
Caché
Una caché no debe guardar un 429
No servir nunca más tarde un 429 guardado
Define el primer retraso, el tope y cuántos reintentos permites, y elige un tipo de jitter. La calculadora muestra el rango de espera de cada intento y el total en el peor caso, para que veas si tu cliente se rinde antes de que se reinicie la ventana del servidor.
Introduce el retraso base en milisegundos, el que se usa antes del primer reintento.
Introduce el tope, lo máximo que puede durar una sola espera.
Elige cuántos reintentos permitir y un tipo de jitter.
Lee los rangos por intento y el total, y copia el código correspondiente de abajo.
Respeta Retry-After por encima de tu propio calendario siempre que el servidor lo envíe. Él sabe cuándo se reinicia su ventana y tú no.
Reintenta solo las peticiones que se pueden repetir sin riesgo. Un POST de pago reintentado sin clave de idempotencia puede cobrar dos veces.
Limita el número de reintentos además del retraso, y muestra un error claro cuando se agoten.
Cuando controles el servidor, devuelve 429 con Retry-After en lugar de descartar o ralentizar peticiones en silencio, para que los clientes bien hechos puedan adaptarse.
Preguntas frecuentes
¿El 429 es un error del cliente o del servidor?
Pertenece a la clase 4xx, así que describe el comportamiento del cliente: demasiadas peticiones. No hay nada roto en el servidor. La solución es enviar menos peticiones o repartirlas.
¿Qué contiene Retry-After?
O un número de segundos de espera, como 120, o una fecha HTTP a partir de la cual puedes volver a intentarlo. Tu cliente debe manejar las dos formas.
¿Por qué añadir jitter al backoff exponencial?
Sin jitter, todos los clientes que fallaron en el mismo momento vuelven a reintentar en el mismo momento, lo que recrea el pico. Una espera aleatoria dentro de cada ventana reparte los reintentos.
¿Por qué mi rate limit de nginx devuelve 503 en lugar de 429?
El módulo limit_req rechaza con 503 salvo que lo cambies. Añade limit_req_status 429; junto a tu línea limit_req para que los clientes vean el código más preciso.
¿Una CDN puede cachear una respuesta 429?
No debe. El RFC 6585 dice que una caché no debe guardar las respuestas con el código de estado 429, para que cada cliente reciba una respuesta nueva cuando se levante el límite.
Quién envía un 429 y por qué
Las APIs, los formularios de inicio de sesión y los endpoints de búsqueda cuentan las peticiones por usuario, por clave o por dirección IP y rechazan las que sobran. La especificación deja el recuento en manos del servidor, así que una API puede limitar por minuto y otra por día.
La respuesta debería explicar el límite en su cuerpo, y puede añadir Retry-After para indicar cuánto esperar.
Los tres tipos de backoff de la calculadora
El backoff exponencial simple duplica la espera cada vez hasta llegar al tope: min(cap, base * 2^attempt). El full jitter elige una espera aleatoria entre cero y ese número. El equal jitter conserva la mitad y aleatoriza la otra mitad, lo que garantiza una pausa mínima.
El full jitter es el que mejor reparte la carga, y por eso es una opción por defecto sensata. El equal jitter encaja con clientes que nunca deben reintentar al instante.
Código de cliente que respeta el 429
fetch con Retry-After y full jitter
Lee las dos formas de Retry-After, recurre al full jitter si no hay cabecera y se detiene tras un número fijo de reintentos.
Enviar un 429 desde tu propio servidor
nginx: limitar por IP y responder con 429
limit_req rechaza con 503 por defecto; limit_req_status lo cambia a 429.
Cómo es la respuesta
Un cuerpo breve que explica el límite y un Retry-After en segundos.
Calculadora de calendario de reintentos
Retraso base (ms)
Tope por espera (ms)
Reintentos
Tipo de jitter
Full jitter
Equal jitter
Sin jitter
Espera antes de cada reintento
Reintento
Espera más corta
Espera más larga
Peor caso antes de rendirse: {v}
Usa números enteros mayores que cero, con un tope al menos igual al retraso base.