¿Qué es el rate limiting por IP?

El rate limiting por IP es un mecanismo que limita el número de peticiones que una dirección IP puede enviar a un servidor durante un periodo determinado. Si superas el límite, el servidor rechaza temporalmente tus peticiones, generalmente con un error HTTP 429 ("Too Many Requests"). Es una de las herramientas más habituales para proteger servidores contra abusos, ataques de denegación de servicio y scraping automatizado.

Probablemente ya te lo has encontrado sin saberlo. Cuando un sitio te muestra "Demasiados intentos, vuelve a probar en 5 minutos" después de varios inicios de sesión fallidos, eso es rate limiting. Cuando una API te devuelve un error después de cierto número de llamadas por minuto, eso es rate limiting. Cuando un buscador bloquea temporalmente tus consultas porque has buscado demasiado rápido, eso también es rate limiting.

Por qué es necesario

Un servidor web tiene recursos limitados: CPU, memoria, ancho de banda, conexiones a la base de datos. Cada petición consume una parte de esos recursos. Sin ninguna limitación, un solo usuario (o un script automatizado) podría monopolizar el servidor enviando miles de peticiones por segundo, haciendo el servicio inaccesible para todos los demás.

El rate limiting protege contra varios tipos de amenazas:

Ataques DDoS y fuerza bruta. Un ataque de denegación de servicio distribuido (DDoS) inunda un servidor de peticiones para dejarlo inoperativo. El rate limiting por sí solo no basta para bloquear un DDoS masivo (que viene de miles de IPs diferentes), pero limita el daño que una sola IP puede causar. Para ataques de fuerza bruta (probar miles de contraseñas), el rate limiting es la primera línea de defensa: limitar a 5 o 10 intentos de inicio de sesión por minuto hace el ataque impracticable.

Scraping y crawling abusivo. Los bots que extraen contenido de un sitio (precios, artículos, datos) envían cientos de peticiones por segundo. El rate limiting ralentiza estos bots hasta hacer la extracción masiva económicamente inviable (demasiado lento, demasiado tiempo de servidor necesario).

Abuso de API. Las API públicas (meteorología, geolocalización, IA, pagos) tienen un coste por petición para el proveedor. Sin rate limiting, un usuario podría consumir recursos desproporcionados, ya sea por error (un bucle en su código) o intencionadamente. La mayoría de las API imponen límites por clave API y por dirección IP.

Equidad entre usuarios. Incluso sin intención maliciosa, un usuario "voraz" (que refresca una página 50 veces por minuto, o un script mal escrito) puede degradar la experiencia para los demás. El rate limiting garantiza un reparto equitativo de los recursos.

Cómo funciona técnicamente

El principio es simple: el servidor asocia cada petición con una dirección IP, cuenta el número de peticiones recibidas de esa IP en una ventana de tiempo y rechaza las peticiones que superan el umbral definido. Pero la implementación concreta varía según el algoritmo utilizado.

Ventana fija (Fixed Window). El tiempo se divide en intervalos fijos (por ejemplo, ventanas de un minuto). El servidor cuenta las peticiones por IP en cada ventana. Si alcanzas 100 peticiones en la ventana actual, las siguientes se rechazan hasta el inicio de la siguiente ventana. Es el algoritmo más simple, pero tiene un defecto: si envías 100 peticiones al final de una ventana y 100 al inicio de la siguiente, has enviado 200 peticiones en pocos segundos, el doble del límite previsto.

Ventana deslizante (Sliding Window). En lugar de ventanas fijas, el servidor mira los últimos N segundos en todo momento. Cada petición se cuenta sobre un periodo deslizante. Esto suaviza la distribución y elimina el problema de la ventana fija, pero requiere más memoria y cálculo en el servidor.

Token Bucket (cubo de tokens). Cada IP dispone de un "cubo" con un número fijo de tokens. Cada petición consume un token. Los tokens se regeneran a un ritmo constante (por ejemplo, 10 por segundo). Si el cubo está vacío, la petición se rechaza. Este modelo permite ráfagas cortas (burst): puedes enviar muchas peticiones de golpe si tu cubo está lleno, luego debes esperar la regeneración. Es el algoritmo más usado en producción porque es flexible y predecible a la vez.

Leaky Bucket (cubo con fuga). Las peticiones entran en una cola (el cubo) y se procesan a un ritmo constante (el caudal de fuga). Si el cubo está lleno, las nuevas peticiones se rechazan. A diferencia del Token Bucket, el Leaky Bucket impone un caudal de salida estrictamente constante, sin ráfagas. Es útil cuando se quiere un flujo de procesamiento perfectamente regular.

Dónde se aplica el rate limiting

El rate limiting puede aplicarse en diferentes niveles de la infraestructura de red, y en la práctica a menudo es así: varias capas se superponen.

A nivel de servidor web. Nginx, Apache y la mayoría de servidores web integran módulos de rate limiting. Nginx, por ejemplo, usa el algoritmo Leaky Bucket con su directiva limit_req. Defines un número de peticiones por segundo por IP, y Nginx se encarga del resto. Es eficaz para una protección básica, pero el servidor tiene que recibir y procesar parcialmente cada petición antes de rechazarla.

A nivel de reverse proxy o balanceador de carga. Colocar el rate limiting delante de los servidores de aplicación (en un reverse proxy como Nginx o HAProxy, o un balanceador de carga) permite bloquear las peticiones antes de que lleguen a la aplicación. Es más eficiente en recursos.

A nivel de CDN o cortafuegos de aplicación (WAF). Servicios como Cloudflare, AWS WAF o Akamai aplican el rate limiting en el borde de la red (edge), antes incluso de que la petición llegue a tu infraestructura. Es la capa más eficaz contra ataques volumétricos, porque la petición se bloquea lo más cerca posible de su origen.

A nivel de aplicación. La propia aplicación puede implementar rate limiting, a menudo con más granularidad: por usuario conectado, por endpoint, por tipo de operación. Por ejemplo, una API puede autorizar 1.000 peticiones GET por minuto pero solo 10 peticiones POST en un endpoint de creación de cuenta, porque los intentos abusivos de creación de cuenta son un vector de ataque habitual.

Las cabeceras HTTP relacionadas con el rate limiting

Cuando un servidor aplica rate limiting, normalmente comunica la información de límites mediante cabeceras HTTP en la respuesta. No hay un estándar universal, pero las convenciones más habituales son:

X-RateLimit-Limit: el número máximo de peticiones permitidas en la ventana de tiempo actual. X-RateLimit-Remaining: el número de peticiones restantes antes de alcanzar el límite. X-RateLimit-Reset: el momento (en timestamp Unix o en segundos restantes) en que la ventana se reinicia y el contador vuelve a cero. Retry-After: una cabecera HTTP estándar que indica cuánto tiempo esperar antes de reintentar, devuelta con la respuesta 429.

Un borrador IETF (RFC 6585 para el código 429 y propuestas más recientes) intenta estandarizar estas cabeceras, pero en la práctica cada API usa su propia convención. Si desarrollas una aplicación que consume APIs, lee siempre la documentación de la API para saber cómo comunica sus límites.

Por qué la IP sola no siempre basta

El rate limiting por IP tiene un problema fundamental: una dirección IP no siempre corresponde a un solo usuario.

El CGNAT. Muchos operadores móviles y algunos ISP usan CGNAT (Carrier-Grade NAT), que hace que cientos o miles de usuarios compartan una misma dirección IPv4 pública. Si limitas una IP a 100 peticiones por minuto, en realidad estás limitando a todos los usuarios detrás de ese CGNAT a un total combinado de 100 peticiones. Un solo usuario normal puede agotar la cuota para todos los demás.

Redes corporativas y universitarias. Miles de empleados o estudiantes pueden acceder a internet a través de una sola dirección IP pública (o un pequeño número de direcciones). El rate limiting por IP los penaliza colectivamente.

VPN y proxies. Los usuarios de VPN comparten a menudo una dirección IP con cientos de otras personas. Un rate limiting estricto por IP puede bloquear usuarios legítimos simplemente porque usan el mismo servidor VPN que un bot.

Direcciones IP dinámicas. A la inversa, un atacante puede cambiar fácilmente de dirección IP (usando un pool de proxies, una botnet, o simplemente activando el modo avión en su teléfono) y eludir el rate limiting por IP. Si el límite es por IP y el atacante tiene acceso a 10.000 direcciones, el límite efectivo se multiplica por 10.000.

Por eso los sistemas de rate limiting modernos combinan generalmente la IP con otros identificadores: clave API, token de autenticación, huella del navegador, cookie de sesión. La IP sigue siendo un criterio útil, pero rara vez suficiente por sí solo.

Qué pasa cuando te limitan

La respuesta más habitual es un código HTTP 429 (Too Many Requests). El servidor también puede devolver un 503 (Service Unavailable) si la limitación se debe a una sobrecarga general y no a un exceso individual.

Algunos servicios no bloquean completamente el acceso sino que degradan el servicio: ralentizan las respuestas (throttling), reducen la calidad de los resultados o añaden un CAPTCHA para verificar que eres humano.

Otros servicios bloquean silenciosamente sin devolver un error explícito. Siguen respondiendo con un código 200 (OK) pero devuelven datos vacíos o resultados degradados. Este "rate limiting silencioso" (shadow banning) es habitual en redes sociales y algunos buscadores, y está diseñado para ser difícil de detectar por los bots.

Cómo gestionan los desarrolladores el rate limiting

Si desarrollas una aplicación que consume una API, debes gestionar el rate limiting correctamente. El método estándar es el "exponential backoff": cuando recibes una respuesta 429, esperas un tiempo dado antes de reintentar, y duplicas ese tiempo con cada fallo sucesivo. Por ejemplo: primer reintento después de 1 segundo, segundo después de 2 segundos, tercero después de 4 segundos, etc.

Las buenas prácticas incluyen:

Leer las cabeceras Retry-After y X-RateLimit-Reset para saber exactamente cuándo reintentar, en vez de adivinar. Implementar una caché para evitar repetir las mismas peticiones. Agrupar peticiones (batching) cuando la API lo permita. Distribuir las peticiones en el tiempo en vez de enviarlas en ráfaga. Prever un circuit breaker que deje de llamar a la API durante un tiempo si los errores 429 se acumulan, para no agravar la situación.

Rate limiting y privacidad

El rate limiting por IP implica que el servidor identifica y rastrea las peticiones por dirección IP. Es una forma de tratamiento de datos personales (la dirección IP se considera dato personal en muchas jurisdicciones, especialmente bajo el RGPD en Europa). Las empresas que implementan rate limiting deberían en teoría mencionar este tratamiento en su política de privacidad.

Desde el punto de vista del usuario, el rate limiting por IP también significa que tu actividad está siendo contabilizada. Si usas un VPN o un proxy por razones de privacidad, el rate limiting puede paradójicamente penalizarte: compartes una IP con otros usuarios y la cuota común se agota más rápido.

Eludir el rate limiting

Cambiar de dirección IP (mediante un VPN, un proxy rotativo o el modo avión en el móvil) permite eludir un rate limiting basado únicamente en la IP. Los servicios de scraping comerciales usan pools de miles de direcciones IP residenciales para distribuir las peticiones y mantenerse por debajo de los umbrales por IP.

Pero los sistemas de protección modernos no se limitan a la IP. Combinan el análisis de la huella del navegador, el comportamiento de navegación (ritmo de clics, movimientos de ratón, tiempo en las páginas), los CAPTCHA y el análisis de patrones de peticiones para distinguir humanos de bots, incluso cuando la IP cambia en cada petición.

La carrera entre los sistemas de rate limiting y las técnicas de evasión es permanente. Los métodos que funcionan hoy pueden ser detectados mañana. Si estás del lado del servidor, la mejor estrategia es combinar varias capas de protección en vez de depender solo de la IP.

Ejemplos de límites habituales

Estos límites varían enormemente según el servicio, el plan de precios y el contexto. Una API de pago ofrece generalmente límites mucho más altos que un plan gratuito. Un endpoint sensible (inicio de sesión, pago, creación de cuenta) tiene límites mucho más bajos que un endpoint de lectura de datos.

El rate limiting por IP es una protección esencial para cualquier servidor expuesto a internet. Impide los abusos, protege los recursos y garantiza un acceso equitativo. Pero la dirección IP sola es un identificador cada vez menos fiable con el CGNAT, las VPN y los proxies. Los sistemas modernos combinan la IP con otras señales para distinguir el tráfico legítimo del abusivo, y es esa combinación la que marca la diferencia entre una protección eficaz y un simple filtro fácil de eludir.