Qué es el rate limiting, en qué se diferencian la ventana fija, la ventana deslizante, el token bucket y el leaky bucket, con un simulador en vivo, el estado 429, Retry-After y un ejemplo de Nginx.
El rate limiting limita cuántas peticiones puede enviar un visitante, una clave o una dirección IP en un periodo de tiempo. Las peticiones que superan el límite se rechazan, normalmente con el estado HTTP 429 Too Many Requests y una cabecera Retry-After que indica cuándo volver a intentarlo. Protege los formularios de acceso, los de contacto y las APIs frente a avalanchas de tráfico y facturas desbocadas.
Los cuatro algoritmos de rate limiting más comunes
Si tu sitio tiene una página de acceso, un formulario de contacto, un proceso de pago o una API a la que llaman otras apps, tarde o temprano alguien la bombardeará, por accidente o a propósito. El rate limiting es la regla que dice cuánto es demasiado. Abajo puedes pulsar botones para enviar peticiones y ver cómo cada algoritmo las acepta o las rechaza, y luego copiar una configuración de Nginx que funciona.
El RFC 6585 define 429 Too Many Requests como el estado para un cliente que ha enviado demasiadas peticiones en un tiempo determinado. La respuesta puede llevar una cabecera Retry-After que indica al cliente cuánto debe esperar.
Por defecto, el módulo limit_req responde a las peticiones rechazadas con 503. Puedes cambiarlo a 429 con la directiva limit_req_status, que es lo que prefieren la mayoría de las APIs porque le dice a quien llama exactamente qué ha pasado.
Todavía no. Los campos RateLimit y RateLimit-Policy proceden de un Internet-Draft de un grupo de trabajo del IETF que seguía en curso en octubre de 2026, así que algunos servicios envían en su lugar las antiguas cabeceras X-RateLimit. Tómalas como pistas útiles.
Un token bucket permite gastar de golpe los tokens acumulados y luego se estabiliza en el ritmo de recarga. Un leaky bucket suaviza el tráfico en un flujo de salida fijo. Nginx documenta que su módulo limit_req usa el método leaky bucket.
No. Gestiona bien el abuso desde pocas fuentes, pero el tráfico repartido entre miles de direcciones también necesita protección en tu hosting o CDN. El rate limiting es una capa, no toda la defensa.
Esto permite a cada dirección IP 5 peticiones por segundo en la ruta de acceso, con una ráfaga de 10 atendidas a la vez, y responde a las peticiones de más con 429 en lugar del 503 por defecto.
La zona de 10m almacena los contadores; la documentación indica que un megabyte guarda unos 16 mil estados de 64 bytes.
Para un solo servidor, un token bucket cabe en unas pocas líneas. Guarda los recuentos en un almacén compartido si usas más de un servidor.
Cada clave recibe 10 tokens que se recargan a 1 por segundo. Una llamada rechazada recibe 429 y un Retry-After en segundos enteros.
Estado 429 con un Retry-After de 30 segundos.
Cada algoritmo permite unas 5 peticiones cada 5 segundos (o un bucket de 5 que avanza a 1 por segundo). Envía peticiones, deja pasar el tiempo y observa qué pasa.
Algoritmo
Ventana fija
Ventana deslizante
Token bucket
Leaky bucket
Enviar 1 petición
Enviar una ráfaga de {n}
Esperar 1 segundo
Reiniciar
Tiempo: {v} s
Permitidas: {n}
Rechazadas con 429: {n}
Registro de peticiones
t={v}s permitida
t={v}s rechazada (429)
Aún no hay peticiones. Pulsa un botón de arriba.
Un modelo didáctico con pasos de un segundo. Los limitadores reales miden en milisegundos.
Empieza gratis · Sin tarjeta de crédito