Error 429 Too Many Requests: qué significa y cómo solucionarlo

¿Qué es el error HTTP 429?

HTTP 429 Too Many Requests significa que el servidor te está limitando la velocidad: tú, tu dirección IP o tu aplicación habéis enviado más solicitudes de las que permite en un período de tiempo. Es temporal. El servidor funciona; simplemente decide no responderte por ahora.

El código se añadió en la RFC 6585 (2012) precisamente para este caso, y la respuesta puede incluir un encabezado Retry-After que indica cuánto esperar. Lo verás al navegar por sitios con mucho tráfico, al llamar a APIs, al descargar en masa o al usar una VPN cuya IP comparten muchas personas.

Se diferencia de sus vecinos: un 401 significa que no has iniciado sesión, un 403 que no tienes permiso, y un 429 que tienes permiso, pero vas demasiado rápido.

¿Cómo se ve el error 429?

El mensaje depende de quién responda. Estos son los que más se buscan:

A diferencia de un error 500, que indica que algo falló en el servidor, un 429 es un error del cliente en términos de HTTP: el servidor se protege de recibir demasiadas solicitudes.

Cómo funciona la limitación de velocidad (rate limiting)

La limitación de velocidad (rate limiting) es una técnica que usan los servidores para controlar cuántas solicitudes puede hacer un cliente en un intervalo de tiempo. Al superar el límite, el servidor suele responder 429 (algunos responden 403 o 503).

Existen varios algoritmos habituales:

• Ventana fija — El servidor permite N solicitudes por ventana de tiempo (p. ej., 100 por minuto). El contador se reinicia a intervalos fijos.
• Ventana deslizante — Similar a la ventana fija, pero la ventana se desplaza con cada solicitud. Evita ráfagas en los límites de la ventana.
• Token bucket (cubo de tokens) — El servidor asigna tokens que se recargan a ritmo constante. Cada solicitud consume un token. Sin tokens, se rechazan las solicitudes.
• Leaky bucket (cubo con fuga) — Las solicitudes se procesan a ritmo constante sin importar el tamaño de la ráfaga. Las que sobran esperan en cola o se descartan.

Muchas APIs anuncian sus límites en los encabezados de respuesta. Los de GitHub, por ejemplo, son x-ratelimit-limit (solicitudes permitidas por hora), x-ratelimit-remaining, x-ratelimit-used y x-ratelimit-reset (cuándo se reinicia la ventana, en segundos Unix). Un borrador del IETF propone encabezados estándar RateLimit y RateLimit-Policy para lo mismo.

Saber qué algoritmo y qué ventana usa un servicio te ayuda a diseñar tu cliente para mantenerlo dentro del límite.

Causas comunes del error HTTP 429

La causa depende de quién vea el error:

Cómo solucionar el error 429 (para visitantes)

Si ves un error 429 al navegar por un sitio web, estas son las soluciones que puedes probar. Empieza por la más simple y ve avanzando.

1. Espera e inténtalo de nuevo

La solución más simple es esperar. Un 429 es temporal: el servidor te pide que bajes el ritmo, no te ha bloqueado.

Cuánto depende del límite del sitio: algunos se reinician en un minuto, otros son por hora o por día. Si la página o la API envía un encabezado Retry-After, esa es la espera exacta. Después, carga la página una sola vez.

No sigas actualizando: cada actualización es otra solicitud y cuenta contra el mismo límite.

2. Borra las cookies del sitio

Rara vez influye, pero algunos sitios cuentan las solicitudes por cookie de sesión. Borra solo las cookies de ese sitio para empezar una sesión nueva, sin cerrar sesión en todo lo demás:

• Chrome / Edge: abre chrome://settings/content/all (Edge: edge://settings/content/all), busca el sitio y elimina sus datos
• Firefox: haz clic en el candado de la barra de direcciones → "Clear cookies and site data…"
• Safari: Safari → Ajustes → Privacidad → Gestionar datos de sitios web… → busca el sitio → Eliminar

Tras borrarlas, cierra y vuelve a abrir el navegador antes de visitar el sitio otra vez.

3. Desconecta la VPN o el proxy

Si usas una VPN o un proxy, puede que compartas dirección IP con cientos de usuarios más. Cuando sus solicitudes juntas superan el límite del servidor, todos los de esa IP quedan limitados.

Prueba a desconectar la VPN y a entrar al sitio con tu conexión normal. Si el error 429 desaparece, el problema era la IP de la VPN.

Si necesitas la VPN, cambia a otra ubicación de servidor: su dirección puede estar compartida por menos gente.

4. Desactiva las extensiones del navegador

Algunas extensiones hacen solicitudes en segundo plano a los sitios que visitas: los rastreadores de precios, las herramientas SEO y las extensiones de actualización automática pueden sumar hasta alcanzar un límite. (Los bloqueadores de anuncios suelen hacer lo contrario y reducen las solicitudes.)

Para comprobarlo, abre el sitio en una ventana de incógnito o privada, donde la mayoría de las extensiones están desactivadas. Incógnito también empieza sin cookies, así que si el 429 desaparece, hay una extensión o un límite por sesión implicado.

Desactiva las extensiones una por una para encontrar la culpable. En Chrome, ve a chrome://extensions/ y desactívalas individualmente.

5. Comprueba si tu dirección IP es compartida

Mucha gente puede compartir una misma dirección IP pública: la red de una oficina o un colegio, la red de un operador móvil (CGNAT) o un servidor VPN. Sus solicitudes cuentan contra el mismo límite que las tuyas.

Si estás en una red así, cargar el sitio desde tu conexión de casa o con datos móviles te dirá si la dirección compartida es el problema. Si el límite está en tu propia dirección, espera a que se reinicie en lugar de cambiar de red para saltártelo. Consulta tu IP pública actual con ¿Cuál es mi IP?.

Cómo solucionar el error 429 (para desarrolladores)

Si tu código recibe 429, está enviando solicitudes más rápido de lo que la API permite. Sigue este orden: lee Retry-After, reintenta con retroceso y jitter, y luego reduce el número de solicitudes.

1. Implementa retroceso exponencial

El retroceso exponencial es la estrategia de reintento estándar: en lugar de reintentar de inmediato tras un 429, duplica la espera cada vez (1 segundo, 2, 4, 8…) y añade jitter, un retraso aleatorio extra, para que muchos clientes no reintenten todos a la vez.

Esta versión usa Retry-After cuando el servidor envía uno válido, en cualquiera de sus dos formatos, recurre a retroceso con jitter en caso contrario y se rinde tras unos pocos intentos. (En un navegador que llama a la API de otro sitio, Retry-After solo se puede leer si la API lo expone con Access-Control-Expose-Headers.)

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === maxRetries) return response;

    // Retry-After is either a number of seconds or an HTTP date
    const header = response.headers.get('Retry-After');
    let delay = NaN;
    if (header) {
      const seconds = Number(header);
      delay = Number.isNaN(seconds) ? Date.parse(header) - Date.now() : seconds * 1000;
    }
    if (!Number.isFinite(delay)) delay = 2 ** attempt * 1000 + Math.random() * 1000; // backoff + jitter
    await new Promise((resolve) => setTimeout(resolve, Math.max(delay, 0)));
  }
}

2. Respeta el encabezado Retry-After

Cuando un servidor envía Retry-After con un 429, indica exactamente cuánto esperar. La RFC 9110 permite dos formas: un número de segundos o una fecha HTTP.

Retry-After: 60 significa esperar 60 segundos. Retry-After: Wed, 21 Oct 2026 07:28:00 GMT significa esperar hasta esa hora. Compruébalo antes de tu propia lógica de retroceso: el servidor sabe más que tu código.

En Python, maneja ambas formas y detente tras unos pocos intentos en lugar de recurrir sin fin:

import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

import requests


def get_with_retry(url, max_retries=5):
    for attempt in range(max_retries + 1):
        response = requests.get(url)
        if response.status_code != 429 or attempt == max_retries:
            return response
        retry_after = response.headers.get("Retry-After", "")
        try:
            if retry_after.isdigit():
                wait = int(retry_after)
            else:  # an HTTP date
                wait = (parsedate_to_datetime(retry_after) - datetime.now(timezone.utc)).total_seconds()
        except (TypeError, ValueError):  # missing or unparseable: back off with jitter
            wait = 2 ** attempt + random.random()
        time.sleep(max(wait, 0))

3. Almacena en caché las respuestas de la API

Si tu aplicación hace la misma llamada a la API varias veces, guarda la respuesta en caché en lugar de consultar la API cada vez. Así reduces drásticamente el número de solicitudes.

Usa una caché en memoria (como Redis o un simple Map) para los datos de acceso frecuente. Fija un TTL (tiempo de vida) razonable según la frecuencia con que cambian los datos.

Por ejemplo, si consultas los registros DNS de un dominio, es probable que no cambien en los próximos 5 minutos: guárdalos en caché.

const cache = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async function cachedFetch(url) {
  const cached = cache.get(url);
  if (cached && Date.now() - cached.time < CACHE_TTL) return cached.data;

  const response = await fetch(url);
  if (!response.ok) throw new Error(`HTTP ${response.status}`); // never cache errors (a 429 included)
  const data = await response.json();
  cache.set(url, { data, time: Date.now() });
  return data;
}

4. Usa webhooks en lugar de polling

Si consultas una API repetidamente para detectar cambios (p. ej., revisar el estado de un pedido cada 10 segundos), cambia a webhooks si el servicio los admite.

Con webhooks, el servidor envía las actualizaciones a tu aplicación cuando algo cambia, sin necesidad de consultar sin parar. Esto puede reducir tus llamadas a la API de miles por hora a un puñado.

La mayoría de las APIs modernas (Stripe, GitHub, Twilio, Shopify) admiten webhooks. Consulta la documentación de la API para configurarlos.

5. Solicita límites más altos

Si de verdad necesitas más llamadas a la API, contacta con el proveedor del servicio. Muchas APIs ofrecen límites más altos en planes de pago o para aplicaciones verificadas.

Al pedir límites más altos, explica tu caso de uso y estima el volumen de solicitudes que esperas. Muchas APIs, entre ellas las de Google, tienen un formulario o un plan de pago para límites mayores.

Algunas APIs también ofrecen endpoints por lotes que permiten obtener varios recursos en una sola solicitud y reducir el total de llamadas.

Cómo solucionar el error 429 (para administradores web)

Si tus visitantes o consumidores de API reciben errores 429, el problema está en la configuración de tu servidor. Así se diagnostica y se corrige.

1. Ajusta tus límites de velocidad

Si usuarios reales reciben 429, averigua qué capa responde primero: tu CDN o WAF, tu servidor web o tu aplicación. Luego ajusta los límites de esa capa.

En nginx, limit_req hace el trabajo. Ten en cuenta que responde 503 por defecto: añade limit_req_status 429; para que los clientes sepan que deben reducir el ritmo en lugar de pensar que el servidor está caído:

# Define rate limit zone: 10 requests per second per IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # Up to 20 extra requests pass at once (nodelay); more than that get 429
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

El parámetro burst deja pasar picos cortos sin un 429; sin él, una carga de página normal con muchas solicitudes puede alcanzar el límite.

Apache no tiene un limitador de tasa de solicitudes integrado: su mod_ratelimit limita el ancho de banda, no el número de solicitudes, y el módulo de terceros mod_evasive responde 403. Usa un proxy inverso, un WAF o tu aplicación para los 429. En Node.js, express-rate-limit responde 429 por defecto.

2. Añade IPs de confianza a la lista blanca

Si ciertos clientes (servicios de monitorización, procesadores de pago, tus propios microservicios) reciben límites, añade sus direcciones IP a la lista blanca.

En nginx, geo y map dan una clave vacía a las direcciones de confianza, y nginx no cuenta las solicitudes con clave vacía. Esto sustituye la línea limit_req_zone del ejemplo anterior:

geo $rate_limit {
    default        1;
    192.168.0.0/16 0;  # Internal network
    10.0.0.0/8     0;  # Internal network
    203.0.113.50   0;  # Payment processor
}

map $rate_limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

limit_req_zone $limit_key zone=api:10m rate=10r/s;

No limites por accidente a los rastreadores de buscadores: Google trata un 429 como un error del servidor y reduce su ritmo de rastreo (Google Search Central). Verifica las solicitudes reales de Googlebot y Bingbot con una consulta de DNS inverso confirmada por una consulta directa de ese nombre, o exime los rangos de IP publicados de los rastreadores.

3. Revisa la configuración del WAF y CDN

Si usas Cloudflare, AWS WAF, Sucuri u otro servicio de seguridad, sus reglas de límite pueden responder antes de que tu servidor vea siquiera la solicitud.

Cloudflare muestra a los visitantes "Error 1015: You are being rate limited" cuando se activa una regla de límite de peticiones. Encuentra la regla en las reglas de seguridad del panel, revisa sus eventos y sube el umbral o reduce su alcance.

Las reglas basadas en tasa de AWS WAF cuentan las solicitudes por IP (u otra clave) en una ventana de 1, 2, 5 o 10 minutos, con un límite mínimo de 10. Una solicitud bloqueada recibe 403 por defecto; configura una respuesta personalizada 429 para que los clientes sepan que deben retroceder.

Mira las analíticas del CDN para separar visitantes reales de bots antes de cambiar nada.

4. Optimiza el rendimiento del servidor

Algunos servicios limitan con más dureza cuando están bajo carga, como válvula de seguridad. Mejorar el rendimiento del servidor te permite subir los límites con seguridad.

Las optimizaciones clave: activa la caché de respuestas para reducir la carga del backend, usa un CDN para los recursos estáticos, añade caché de consultas con Redis o Memcached, implementa pooling de conexiones a la base de datos y escala horizontalmente con balanceo de carga si el tráfico lo justifica.

Usa nuestro Verificador de encabezados HTTP para comprobar que tus encabezados de caché están bien configurados.

Error 429 vs otros errores HTTP

Es fácil confundir el error 429 con otros códigos de estado HTTP. Así se diferencian:

La distinción clave: el 429 es deliberado y temporal: el servidor decide rechazarte por ahora. La mayoría de los códigos 5xx indican que algo falló en el servidor, aunque un 503 también puede ser un mantenimiento planificado o, en nginx, un límite de velocidad.

Cómo prevenir los errores 429

Más vale prevenir que curar. Estas son las buenas prácticas para evitar los errores 429 desde el principio:

• Lee la documentación de la API — Conoce los límites antes de escribir código. La mayoría de los servicios los publican con claridad.
• Vigila tu uso — Sigue los encabezados X-RateLimit-Remaining para saber cuánto te falta para el límite.
• Agrupa solicitudes — Usa endpoints por lotes cuando existan en lugar de hacer llamadas individuales.
• Distribuye las solicitudes — Reparte las llamadas a la API de forma uniforme en el tiempo en lugar de enviar ráfagas.
• Usa claves de API — Las solicitudes autenticadas suelen tener límites más altos que las anónimas.
• Implementa circuit breakers — Si recibes 429 repetidos, deja de enviar solicitudes por completo durante un período de enfriamiento.
• Prueba con simuladores de límites — Simula respuestas 429 en desarrollo para asegurarte de que tu gestión de errores funciona.
• Registra las respuestas 429 — Anota cuándo y dónde ocurre la limitación para optimizar tus patrones de solicitud.