La limitación de tasa controla el número de solicitudes que un cliente puede realizar en un periodo de tiempo determinado. Nginx implementa esta función mediante un algoritmo de «cubo con fugas», que suaviza los picos de tráfico al tiempo que mantiene una tasa de solicitudes constante. Esta técnica protege a tus servidores backend de la sobrecarga y garantiza un acceso equitativo para todos los usuarios.

¿Qué es la limitación de tasa?

La limitación de tasa controla el número de solicitudes que un cliente puede realizar en un periodo de tiempo determinado. Piensa en ello como un portero que solo deja entrar a un número determinado de personas por minuto.

NGINX implementa la limitación de tasa mediante el algoritmo del cubo agujereado. Imagina un cubo con un pequeño agujero en el fondo:

•     El agua (las solicitudes) entra a ritmos variables
•     El agua se vacía a un ritmo constante (el límite que hayas configurado)
•     Si el cubo se desborda, el exceso de agua se desecha (se rechazan las solicitudes)

Este enfoque suaviza los picos de tráfico al tiempo que mantiene un flujo constante hacia tu servidor backend.

¿Por qué utilizar la limitación de tasa de NGINX?

La limitación de tráfico tiene múltiples finalidades:

•     Protección contra DDoS: mitigar los ataques de denegación de servicio limitando el tráfico por dirección IP
•     Protección de la API: evitar el uso indebido de los puntos finales de tu API
•     Conservación de recursos: proteger los servidores backend contra la sobrecarga
•     Uso equitativo: garantizar que ningún cliente monopolice los recursos
•     Mitigación de bots: ralentizar los rastreadores y scrapers agresivos
•     Protección de inicio de sesión: evitar los ataques de fuerza bruta contra las contraseñas

 Comprensión de los conceptos de limitación de tasa

Antes de configurar la limitación de tasa, es importante comprender estos conceptos clave:

•     Tasa (Rate): número de solicitudes permitidas por unidad de tiempo (por ejemplo, 10 solicitudes por segundo)
•     Ráfaga (Burst): número de solicitudes excedentes permitidas durante los picos de tráfico
•     Zona: área de memoria compartida que realiza un seguimiento del recuento de solicitudes por clave (normalmente, la IP del cliente)
•     Retraso (Delay): si se deben retrasar las solicitudes excedentes o rechazarlas inmediatamente

Paso 1: Comprender cómo funciona `limit_req`

La limitación de tasa de Nginx utiliza el algoritmo del «cubo con fugas» y requiere dos directivas:

•     `limit_req_zone` (en el contexto `http`) define una zona de memoria compartida, la clave que identifica a un cliente y la tasa permitida por clave.
•     `limit_req` (en `http`, `server` o `location`) aplica una zona a las solicitudes, opcionalmente con una cola de ráfagas.

Una tasa de 10r/s no significa «10 solicitudes en cualquier momento dentro de un segundo». Nginx las distribuye de forma uniforme: una solicitud cada 100 ms. Sin el parámetro «burst», una segunda solicitud que llegue 50 ms después de la primera será rechazada. El parámetro «burst» permite que un cliente supere brevemente la tasa poniendo en cola las solicitudes adicionales, y «nodelay» atiende las solicitudes en cola de forma inmediata en lugar de espaciarlas, aunque sigue contabilizándolas dentro del límite.

En el caso de los sitios web y las API, lo ideal es casi siempre utilizar el modo «burst» con «nodelay»: los navegadores cargan muchos recursos en paralelo, y retrasarlos hace que la página parezca lenta.

Burst

El límite básico anterior es bastante estricto. Si un cliente envía dos solicitudes a la vez, la segunda se rechaza. El «leaky bucket» solo permite una solicitud cada 100 ms (una décima de segundo).

El parámetro «burst» proporciona un margen para los picos de tráfico: 

 Con burst=20:

•     Se procesa 1 solicitud de forma inmediata (el límite de tasa)
•     Se ponen en cola hasta 20 solicitudes adicionales en el «burst bucket»
•     Las solicitudes en cola se procesan según el límite de tasa (una cada 100 ms)
•     Las solicitudes que superen el límite de «burst» se rechazan

Importante: Las solicitudes de «burst» se retrasan, no se procesan de forma inmediata. Un «burst» de 20 solicitudes tarda 2 segundos en procesarse por completo.

 NoDelay

Delay 

 Definición de las zonas de limitación de velocidad

Crea un archivo en /etc/nginx/conf.d/, que el archivo nginx.conf de Ubuntu incluye dentro del bloque http:

sudo nano /etc/nginx/conf.d/rate-limit.conf

Añadir config: 

# Límite general: 10 solicitudes por segundo por IP de cliente
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

# Límite estricto para el inicio de sesión y el restablecimiento de contraseña: 5 solicitudes por minuto por IP
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# Responder con el código 429 «Too Many Requests» en lugar del 503 predeterminado
limit_req_status 429;
limit_req_log_level warn;

La clave $binary_remote_addr es la dirección IP del cliente en formato binario, que ocupa menos memoria que la clave de texto $remote_addr. Una zona de 1 MB almacena unos 16 000 estados de cliente, por lo que 10 m puede contener unas 160 000 direcciones IP. Cuando una zona está llena, Nginx elimina las entradas más antiguas; si aún así no consigue liberar espacio, rechaza la solicitud.

limit_req_status 429 devuelve el código de estado que indica a los clientes que se les está aplicando una limitación de velocidad, y limit_req_log_level warn registra las solicitudes rechazadas en el registro de errores con el nivel «warn» (las solicitudes retrasadas se registran con un nivel inferior).

 Cómo aplicar los límites a tu sitio web

 Abre la configuración de tu sitio:

sudo nano /etc/nginx/sites-available/tu_dominio

server {
    listen 80;
    server_name tu_dominio;
    root /var/www/tu_dominio;

    limit_req zone=perip burst=20 nodelay;

    location = /login {
        limit_req zone=login burst=5 nodelay;
        # Sigue reenviando la solicitud a tu aplicación aquí, por ejemplo:
        # proxy_pass http://127.0.0.1:8000;
    }

    location / {
        try_files $uri $uri/ =404;
    }
}

Recargar Nginx:

sudo nginx -t && sudo systemctl reload nginx 

Poniendo a prueba los límites

Envía 30 solicitudes lo más rápido posible y cuenta los códigos de estado:

for i in $(seq 1 30); do curl -s -o /dev/null -w "%{http_code}\n" http://your_domain/; done | sort | uniq -c 

Resultado:

     21 200
      9 429 

Se atienden la primera solicitud y la ráfaga de 20, y el resto se rechazan. Espera unos segundos y vuelve a ejecutar el bucle: el «bucket» se ha vaciado y se aceptan las solicitudes.

Comprueba el límite de inicio de sesión de la misma manera:

for i in $(seq 1 10); do curl -s -o /dev/null -w "%{http_code}\n" http://your_domain/login; done | sort | uniq -c 

 Resultado

      6 200
      4 429 

Solo se procesan la primera solicitud y la ráfaga de 5. Si ninguna aplicación responde aún en /login, las solicitudes aceptadas devuelven un 404 en lugar de un 200; lo importante es que las últimas cuatro devuelven un 429. Dado que la tasa es de 5 por minuto, se abre una nueva franja cada 12 segundos.

En una prueba de carga con concurrencia, ab informa de cuántas respuestas no fueron 2xx:

ab -n 200 -c 20 http://your_domain/ | grep -E 'Solicitudes completas|No 2xx' 

 Resultado:

Solicitudes completas:      200
Respuestas que no son 2xx:      179 

Multiple Rate Limits

 Aplicar diferentes límites en función de la ubicación o del tipo de solicitud:

http {
    # General API limit: 10 req/s
    limit_req_zone $binary_remote_addr zone=api_general:10m rate=10r/s;

    # Login endpoint: 5 req/minute (stricter)
    limit_req_zone $binary_remote_addr zone=api_login:10m rate=5r/m;

    # Search endpoint: 30 req/s (more permissive)
    limit_req_zone $binary_remote_addr zone=api_search:10m rate=30r/s;
} 

server {
    listen 80;
    server_name api.example.com;

    # Strict rate limit for authentication
    location /api/auth/ {
        limit_req zone=api_login burst=5 nodelay;
        proxy_pass http://127.0.0.1:3000;
    }

    # Higher limit for search
    location /api/search/ {
        limit_req zone=api_search burst=50 nodelay;
        proxy_pass http://127.0.0.1:3000;
    }

    # Default limit for other API endpoints
    location /api/ {
        limit_req zone=api_general burst=20 nodelay;
        proxy_pass http://127.0.0.1:3000;
    }
} 

Rate Limiting by API Key

 En el caso de las API con autenticación, aplica el límite de solicitudes por clave de API en lugar de por IP:

http {
    # Use API key from header as the rate limit key
    map $http_x_api_key $api_key {
        default $http_x_api_key;
        ""      $binary_remote_addr;  # Fall back to IP if no key
    }

    limit_req_zone $api_key zone=api_by_key:10m rate=100r/s;
} 

server {
    listen 80;
    server_name api.example.com;

    location /api/ {
        limit_req zone=api_by_key burst=50 nodelay;
        proxy_pass http://127.0.0.1:3000;
    }
} 

Logging 

Cada solicitud rechazada también se registra en el registro de errores:

sudo tail -n 3 /var/log/nginx/error.log

2026/09/25 10:42:17 [warn] 2318#2318: *845 limiting requests, excess: 20.300 by zone "perip", client: 203.0.113.25, server: your_domain, request: "GET / HTTP/1.1", host: "your_domain" 

 Añadiendo:

limit_req_log_level warn; 

 Niveles de registro disponibles: info, notice, warn (recomendado), error (por defecto).

2026/01/22 12:34:56 [warn] limiting requests, excess: 20.500 by zone "mylimit", client: 192.168.1.100 

El valor del excess indica en qué medida el cliente supera el límite. 

    # Registro de solicitudes con límite de velocidad
    log_format rate_limit '$remote_addr - [$time_local] '
                          '"$request" $status $body_bytes_sent '
                          'limit_req_status=$limit_req_status'; 

Y después:

      # Registro de límites de velocidad
    access_log /var/log/nginx/api_access.log rate_limit;

# Count rate-limited requests

grep "limit_req_status=REJECTED" /var/log/nginx/api_access.log | wc -l

Consejo - Truco - Tip:

 Antes de aplicar límites en un entorno de producción con mucho tráfico, añade «limit_req_dry_run on;» junto a «limit_req». De este modo, Nginx registrará en el log qué solicitudes serían rechazadas sin llegar a rechazarlas realmente, lo que te permitirá ajustar primero la tasa y los picos de tráfico en condiciones reales. 

La limitación de la tasa de solicitudes protege tu infraestructura contra el uso indebido, al tiempo que garantiza una distribución equitativa de los recursos. Empieza con límites conservadores, supervisa las tasas de rechazo y ajústalos en función de los patrones de tráfico legítimos. Combina la limitación de la tasa de solicitudes con los límites de conexión para obtener una protección integral tanto contra las solicitudes en ráfagas como contra los ataques de conexión lenta. 

Límite de solicitudes por URI de solicitud

 Limitar el tráfico de URI concretas, independientemente de la dirección IP del cliente:

 limit_req_zone $request_uri zone=peruri:10m rate=100r/s;

location /expensive-endpoint {
    limit_req zone=peruri burst=50 nodelay;
}

Excluyendo a los clientes de confianza (WhiteList)

 Limitación de conexiones simultáneas

La opción `limit_req` controla la tasa de solicitudes, pero un cliente también puede mantener abiertas muchas conexiones lentas, por ejemplo, mientras descarga archivos de gran tamaño. El módulo `limit_conn` limita el número de conexiones simultáneas por clave. Añade la zona al archivo `/etc/nginx/conf.d/rate-limit.conf`:

limit_conn_zone $binary_remote_addr zone=connperip:10m;
limit_conn_status 429;

A continuación, aplícalo donde sea necesario, por ejemplo, a una sección de descargas de tu sitio web:

location /downloads/ {
    limit_conn connperip 5;
}

 Ahora, cada dirección IP puede tener en marcha un máximo de cinco descargas a la vez. 

Código de respuesta http - Devuelve una respuesta 429 válida

Por defecto, las solicitudes sujetas a limitación de tasa reciben un código de error HTTP 503. En el caso de las API, el código 429 (Demasiadas solicitudes) es más adecuado: 

 limit_req_status 429;

 Por defecto, Nginx devuelve su página de error HTML genérica. En el caso de una API, devuelve JSON y un encabezado «Retry-After» para que los clientes que se comporten correctamente sepan cuándo volver a intentarlo. Añade esto al bloque de servidor de tu sitio:

error_page 429 = @ratelimited;

location @ratelimited {
    default_type application/json;
    add_header Retry-After 1 always;
    return 429 '{"detail": "Demasiadas solicitudes, por favor, reduce el ritmo."}';
}

Recarga Nginx, activa el límite con el bucle del paso 4 y observa una respuesta rechazada:

for i in $(seq 1 25); do curl -s -o /dev/null http://your_domain/; done; curl -i http://your_domain/

Respuesta: 

 HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 1

{"detail": "Too many requests, please slow down."}

Recuerda puedes personalizar la página de error: 

 error_page 429 /rate_limited.html;

location = /rate_limited.html {
    internal;
    return 429 '{"error": "Rate limit exceeded. Please slow down."}';
    add_header Content-Type application/json;
}

Limitación de velocidad tras un proxy o una CDN

 Si Nginx se encuentra detrás de un equilibrador de carga o una CDN como Cloudflare, todas las solicitudes llegan desde la dirección IP del proxy y todos los visitantes comparten un único límite. Utiliza el módulo realip, que viene incluido en Nginx para Ubuntu, para recuperar la dirección del cliente antes de que se evalúen los límites. Añade esto al contexto http, por ejemplo, en /etc/nginx/conf.d/real-ip.conf:

set_real_ip_from 10.0.0.5;
real_ip_header X-Forwarded-For;
real_ip_recursive on; 

Sustituye 10.0.0.5 por la dirección o el rango de tu proxy y utiliza una línea «set_real_ip_from» por cada rango. Incluye únicamente los proxies que controles o en los que confíes: cualquier cliente que pueda acceder directamente a Nginx desde una dirección incluida en la lista podrá establecer su propia IP. En el caso de Cloudflare, incluye sus rangos de IP publicados y utiliza «real_ip_header CF-Connecting-IP;».

Tras recargar la página, el registro de errores debería mostrar las direcciones reales de los clientes en «client:», en lugar de la dirección del proxy. 

Si se encuentra detrás de un equilibrador de carga o una CDN, $binary_remote_addr muestra la dirección IP del equilibrador de carga. Utiliza el módulo «real IP»:

http {
    set_real_ip_from 10.0.0.0/8;
    real_ip_header X-Forwarded-For;

    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
} 

Ejemplo con CloudFlare:

http {
    set_real_ip_from 173.245.48.0/20;
    set_real_ip_from 103.21.244.0/22;
    set_real_ip_from 103.22.200.0/22;
    # ... add all Cloudflare IP ranges
    real_ip_header CF-Connecting-IP;

    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
} 

Bloqueo de usuarios reincidentes con Fail2Ban