429 Too Many Requests

Uso

El código de estado 429 Too Many Requests indica que el número de solicitudes HTTP ha superado el umbral permitido. Esto ocurre, por ejemplo, cuando el servidor quiere limitar el número de llamadas a la API en una hora.

La especificación no define cómo cuenta el servidor las solicitudes HTTP ni cómo identifica a los usuarios. La limitación de velocidad se aplica por recurso, por usuario, en todo el servidor o en varios servidores. La identificación del usuario se realiza mediante credenciales o, de forma alternativa, mediante cookies.

Opcionalmente, el servidor incluye la cabecera HTTP Retry-After para informar al cliente de cuándo se vuelven a aceptar solicitudes.

Nota

La limitación de velocidad (rate limiting) pone un tope al número total de solicitudes dentro de una ventana de tiempo (corte estricto), mientras que el estrangulamiento (throttling) ralentiza el procesamiento de las solicitudes poniéndolas en cola o retrasando las respuestas. La duración de la espera depende de la cabecera Retry-After. Sin Retry-After, las ventanas habituales van de 60 segundos a 24 horas según la API. Los usuarios de VPN comparten direcciones IP con muchos otros usuarios, de modo que los límites de velocidad por IP afectan a todos los usuarios de VPN del mismo servidor.

Impacto en SEO

Googlebot interpreta el 429 como una señal de error del servidor. Cuando un sitio devuelve respuestas 429, Google reduce temporalmente la frecuencia de rastreo en todo el sitio. Una vez que se reanudan las respuestas normales, la frecuencia de rastreo se recupera de forma gradual. A diferencia de otros códigos 4xx, las respuestas 429 sí afectan al presupuesto de rastreo. Las respuestas 429 persistentes en URL indexadas acaban provocando su eliminación de los resultados de búsqueda. Para hacer que Googlebot baje el ritmo, 429 es el código de estado correcto: 401 y 403 no reducen la frecuencia de rastreo. Bingbot también reduce su frecuencia de rastreo ante respuestas 429. Además, Bing admite crawl-delay en robots.txt como alternativa al estrangulamiento basado en códigos de estado.

Ejemplo

El cliente solicita un recurso y el servidor responde con 429 Too Many Requests.

Solicitud

GET /current-news HTTP/1.1
Host: example.com

Respuesta

HTTP/1.1 429 Too Many Requests
Retry-After: 1800
Content-Type: text/html
Content-Length: 173

<html>
  <head>
    <title>Request Limit Exceeded</title>
  </head>
  <body>
   <p>The request limit has been reached.
   Try again in 30 minutes.</p>
  </body>
</html>

Cómo solucionarlo

Revise la cabecera Retry-After de la respuesta. Su valor indica un número de segundos o una fecha HTTP que señala cuándo vuelve el servidor a aceptar solicitudes. Detenga todas las solicitudes hasta el momento indicado.

Implemente una espera exponencial con variación aleatoria (jitter) entre los intentos de reintento. Duplique el tiempo de espera tras cada fallo (1 s, 2 s, 4 s, 8 s) y añada un desplazamiento aleatorio para evitar que varios clientes reintenten en el mismo instante y generen un nuevo pico de tráfico.

Supervise las cabeceras de límite de velocidad antes de alcanzar el techo. Muchas API incluyen las cabeceras X-RateLimit-Limit, X-RateLimit-Remaining y X-RateLimit-Reset. Siga el recuento restante y reduzca el ritmo de las solicitudes de forma proactiva.

Campos estandarizados de límite de velocidad

Más allá de las cabeceras X-RateLimit-*, estándar de facto, el IETF está estandarizando los campos de respuesta RateLimit y RateLimit-Policy para señalizar la cuota y su reinicio.

Encole las solicitudes salientes en el lado del cliente. Una cola de solicitudes con una tasa de despacho controlada evita que las ráfagas superen el límite. Agrupe varias operaciones en una sola llamada a la API cuando el endpoint admita operaciones por lotes.

Almacene en caché las respuestas de los datos que no se espera que cambien entre solicitudes. Las llamadas idénticas redundantes son la fuente más común de consumo innecesario del límite de velocidad.

En el lado del servidor, en nginx, las directivas limit_req_zone y limit_req controlan los límites de velocidad por IP o por endpoint. Establezca limit_req_status 429; para que las solicitudes limitadas devuelvan el código de estado correcto en lugar del 503 predeterminado. Use los parámetros burst y nodelay para permitir picos breves de tráfico sin rechazar a los clientes de inmediato.

En AWS API Gateway, configure los ajustes de estrangulamiento a nivel de etapa (stage) o de método. Aumente la capacidad de tasa y de ráfaga para ajustarla a los patrones de tráfico previstos cuando los umbrales predeterminados resulten demasiado restrictivos.

Referencias de código

.NET

HttpStatusCode.TooManyRequests

Rust

http::StatusCode::TOO_MANY_REQUESTS

Rails

:too_many_requests

Go

http.StatusTooManyRequests

Symfony

Response::HTTP_TOO_MANY_REQUESTS

Python3.5+

http.HTTPStatus.TOO_MANY_REQUESTS

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_TOO_MANY_REQUESTS

Angular

@angular/common/http/HttpStatusCode.TooManyRequests