Guía de rate limiting en Cloudflare: defiende ataques CC en 5 minutos, también con el plan gratuito
Son las 3 de la madrugada. La alerta del monitor suena: CPU al 100 % y el sitio caído. En los logs, decenas de IPs martilleando la API a cientos de peticiones por segundo: un ataque CC.
Bloqueas IPs a mano y aparecen otras al instante. Tras dos horas recuerdas Cloudflare. Abres el panel, ves Rate Limiting — ¡y el plan gratuito sirve! Una regla: máximo 20 peticiones por minuto por IP; si se pasa, bloqueo 10 minutos. Cinco minutos y el ataque queda fuera.
Defender un CC no es tan complicado si configuras el rate limiting antes. En este artículo veremos cómo usarlo en Cloudflare: plan gratuito, umbrales, escenarios distintos y trampas habituales.
¿Qué es un ataque CC? ¿Por qué el rate limiting lo frena?
CC significa Challenge Collapsar: simula muchos usuarios normales visitando tu sitio hasta agotar los recursos del servidor.
¿No es lo mismo que un DDoS? No del todo. El DDoS clásico envía muchos paquetes basura con un patrón claro; la protección DDoS automática de Cloudflare suele pararlo. El CC es más astuto: peticiones HTTP normales, como si fueran personas. La protección DDoS tradicional puede no verlo.
Un usuario real abre unas pocas páginas por minuto, unas 5-10 peticiones. En un CC, una IP puede hacer más de 1000 en 30 segundos. Y suelen atacar desde muchas máquinas o proxies, repartiendo el tráfico.
El rate limiting está pensado para esto. Monitoriza la frecuencia por IP (o sesión, clave API, etc.); si supera el umbral, actúa: CAPTCHA o bloqueo temporal.
En un ataque que viví, la IP enviaba 200-300 peticiones por segundo y yo tenía 20 por minuto. El límite saltaba en 1-2 segundos. Los usuarios normales no lo activaban.
Dato útil: la documentación de Alibaba Cloud WAF indica que, en un CC típico, una máquina zombi supera las 1000 peticiones en 30 segundos, mientras un usuario normal suele hacer menos de 10 por minuto.
La diferencia es clara.
¿Y si un usuario real va muy rápido, p. ej. refrescando una API? Puede pasar; por eso el umbral importa. Más adelante vemos valores por escenario.
¡El plan gratuito también sirve! Rate limiting en Cloudflare
Mucha gente (yo incluido antes) cree que el rate limiting es de pago. Desde octubre de 2022, Cloudflare lo incluye en Free, Pro y Business.
Antes, antes de 2022, se cobraba por tráfico: 5 USD por millón de peticiones. En sitios grandes, dolía. Por eso yo no lo activaba.
Ahora Cloudflare lo anunció en el blog: las reglas van incluidas, sin cargo extra. En el plan gratuito puedes crear 1 regla; Pro y Business permiten más.
¿Basta 1 regla? En sitios pequeños y medianos, sí. Úsala donde más te atacan: login, registro o API crítica.
En mis proyectos pequeños solo protejo el login. Casi un año sin problemas; escaneos menores también caen.
Si necesitas varias rutas sensibles, quizá toque Pro o Business: Pro ~20 USD/mes (10 reglas), Business ~200 USD/mes (15 reglas). Para sitios personales y pymes, 1 regla suele bastar.
Recuerda: aunque solo tengas 1 regla de rate limiting, la protección DDoS básica está en todos los planes, sin límite de tráfico. El rate limiting apunta a CC sutiles y abuso de APIs.
Plan gratuito vs de pago:
- Cantidad de reglas: Free 1, Pro 10, Business 15
- Características avanzadas: Bot Score, JA3, etc.
- Tiempo de respuesta: planes de pago responden mejor con mucho tráfico
Si empiezas, prueba el plan gratuito en tu interfaz más crítica y observa. Si necesitas más reglas, sube de plan.
¿Cómo fijar umbrales? Recomendaciones por escenario
La primera vez miré “Requests per period” sin saber si poner 10 o 100: muy bajo y bloqueas usuarios; muy alto y no paras el ataque.
Tras documentación de Cloudflare, prácticas de grandes proveedores y pruebas propias, estos son valores de referencia. Ajústalos a tu tráfico real.
Login/registro (lo más atacado)
Zona habitual de fuerza bruta y credential stuffing. Los usuarios reales piden poco; un ataque dispara el volumen.
Recomendación oficial (tres capas):
- Capa 1: 4 peticiones/minuto → JavaScript Challenge
- Capa 2: 10 peticiones/10 minutos → CAPTCHA
- Capa 3: 20 peticiones/hora → bloqueo 1 día
En Free solo hay 1 regla. Yo uso:
- Una capa: 20 peticiones/60 segundos → bloqueo 10 minutos
En mis logs, incluso con contraseña incorrecta, rara vez superan 5 intentos/minuto. Un script hace cientos o miles. 20/min equilibra ambos mundos.
Seguridad alta:
- Modo estricto: 10 peticiones/60 segundos → bloqueo 1 hora
API (según el negocio)
API de consulta:
- Recomendado: 30 peticiones/10 segundos → JavaScript Challenge (~3/s; suficiente para muchas apps)
API intensiva (imágenes, análisis):
- Recomendado: 10 peticiones/60 segundos → limitación de velocidad
API pública:
- Según facturación y capacidad: API gratuita ~100/hora; API de pago, límites por plan
Google Cloud Armor sugiere, como referencia, 2000 peticiones/20 minutos con limitación gradual del 20 % del tráfico sobrante.
Páginas web (anti-scraping)
- Páginas normales: 100 peticiones/30 segundos → JavaScript Challenge
- Especiales (búsqueda, descargas): 50 peticiones/60 segundos → CAPTCHA
¿Por qué tan alto en páginas normales? Navegar rápido + assets de una página pueden sumar muchas peticiones. 100/30 s no molesta a usuarios reales pero frena crawlers.
No limites demasiado la home. Una vez limité la portada y bloqueé a Google y Bing; el SEO cayó hasta quitar la regla.
Referencia práctica
Alibaba Cloud WAF propone para sitios medianos:
- Más de 1000 peticiones en 30 s desde una IP → bloqueo 10 horas
Es un colchón amplio. Si dudas, empieza ahí y ajusta con logs.
Truco: al principio usa Managed Challenge, no Block. Si el umbral es algo bajo, un humano puede pasar el CAPTCHA. Cuando confirmes que no hay falsos positivos, sube a Block.
Tutorial en 5 minutos (paso a paso)
Paso 1: entrar en Rate Limiting
Inicia sesión, elige el dominio:
Security → WAF → Rate limiting rules
Verás Create rule. En Free: 0/1 rules.
Paso 2: información básica
Rule name: p. ej. Login-Rate-Limit o API-Protection.
Paso 3: condiciones (Expression)
Proteger login:
Field: URI Path
Operator: equals
Value: /api/loginSolo monitoriza /api/login.
Proteger toda la API:
Field: URI Path
Operator: contains
Value: /api/Excluir un User-Agent (p. ej. tu monitor):
Field: User Agent
Operator: does not equal
Value: MyMonitorBotPaso 4: parámetros (núcleo)
Characteristics:
- IP Address: por IP (recomendado contra CC)
- Session: por cookie de sesión
- Headers: p. ej. API Key
Para login, IP Address.
Period: suelo usar 60 segundos.
Requests per period: login 20, API 30.
Duration: suelo usar 10 minutos.
Ejemplo login:
- Characteristics: IP Address
- Period: 60 seconds
- Requests: 20
- Duration: 10 minutes
Más de 20 peticiones al login en 1 minuto desde la misma IP → bloqueo 10 minutos.
Paso 5: acción (Action)
Managed Challenge (recomendado): Cloudflare distingue humano/bot; mejor UX.
Block: 403; máxima protección, más riesgo de falsos positivos.
Legacy CAPTCHA: CAPTCHA clásico.
JS Challenge: JavaScript en el cliente; poco molesto para usuarios reales.
Empieza con Managed Challenge; luego Block si hace falta.
Paso 6: guardar
Deploy al final. Efecto inmediato.
Paso 7: verificar
for i in {1..30}; do curl https://yourdomain.com/api/login; doneLas primeras 20 deberían pasar; desde la 21, 429 o desafío.
Revisa Security → Events para ver bloqueos.
Ejemplo completo
Proteger /api/auth/login:
Información básica:
- Rule name: Login-Rate-Limit
Coincidencia:
- URI Path equals
/api/auth/login
Rate limiting:
- Characteristics: IP Address
- Period: 60 seconds
- Requests: 20
- Duration: 10 minutes
Acción:
- Managed Challenge
Deploy. Cinco minutos.
Trucos avanzados y errores habituales
Error 1: crawlers SEO
No limites en exceso la home ni todo el sitio.
Una regla global (50 peticiones/30 s) disparó errores de rastreo en Search Console: Google descarga muchos assets a la vez.
Solución: solo login y API; contenido sin límite estricto.
Recomendaciones:
- Login, registro, API: estricto
- Contenido: laxo o sin límite
- Home: evita limitar
- Anti-scraping fino: Bot Management (de pago)
Error 2: saltarse Cloudflare
Un amigo tenía rate limiting y aun así sufrió CC: atacaban la IP real del servidor.
Cloudflare es proxy inverso. Si conocen la IP de origen, entran directo.
Soluciones:
- Firewall: solo IPs de Cloudflare
# Solo IPs de Cloudflare
for i in `curl https://www.cloudflare.com/ips-v4`; do
ufw allow from $i to any port 443 proto tcp
ufw allow from $i to any port 80 proto tcp
done-
Rotar IP de origen si se filtró; no la expongas en DNS.
-
Authenticated Origin Pulls: certificado de Cloudflare en el origen.
Error 3: no revisar reglas
Sin revisión:
- Umbral bajo → quejas de usuarios
- Más tráfico legítimo → umbrales obsoletos
- Nuevo patrón de ataque → reglas débiles
Revisa Security Analytics cada mes: bloqueos, falsos positivos, 429.
Ajusta: pocos 429 → baja umbrales; muchos 429 → súbelos.
Truco 1: ataques distribuidos
Muchas IPs proxy, cada una con poca frecuencia: el límite por IP no basta.
- Session/Cookie en lugar de IP
- Filtro User-Agent (Python, curl, etc.)
- Bot Management (de pago): limitar Bot Score < 30
Truco 2: respuesta progresiva (de pago)
Capa 1 (laxa):
- Umbral alto (p. ej. 30/min)
- JS Challenge
Capa 2 (media):
- 50/10 min
- Managed Challenge
Capa 3 (estricta):
- 100/hora
- Block 24 h
Truco 3: protección por región
Si tu negocio es sobre todo en China:
(ip.geoip.country ne "CN") and (http.request.uri.path eq "/api/login")Solo IPs fuera de CN reciben el límite estricto. Ojo con VPN: mejor Challenge que Block.
Para cerrar
En resumen: configurar rate limiting no es difícil; lo importante es hacerlo antes del ataque.
Muchos empiezan a las 3 de la madrugada con la alerta sonando. Cinco minutos de configuración previa evitan ese caos.
Qué hacer ahora:
- Configura una regla, aunque nunca te hayan atacado.
- Empieza por el login si solo tienes 1 regla gratis.
- Prueba con curl o refrescos rápidos; mira Security Events.
- Revisa cada mes Security Analytics y ajusta umbrales.
Y restringe el firewall a IPs de Cloudflare; si te saltan el proxy, las reglas no sirven de nada.
Si te atas, consulta la documentación oficial o la comunidad de Cloudflare.
Espero que esto te ayude a configurar rate limiting y mantener el CC lejos de tu sitio.
Flujo completo para configurar rate limiting en Cloudflare contra ataques CC
Desde entender el CC hasta crear reglas de rate limiting en 5 minutos, con umbrales recomendados y errores habituales
Estimated time: PT5M
-
1
Step 1: Entender el CC y el rate limiting
Características del CC: -
2
Step 2: Conocer el plan gratuito y límites de reglas
Plan gratuito: -
3
Step 3: Configurar umbrales por escenario
Login/registro: -
4
Step 4: Tutorial en 5 minutos: crear la regla
Paso 1: Rate Limiting -
5
Step 5: Parámetros, acción y verificación
Paso 4: parámetros -
6
Step 6: Guardar, verificar y evitar errores
Paso 6: Deploy (efecto inmediato)
FAQ
¿Se puede usar rate limiting de Cloudflare en el plan gratuito? ¿Cuál es el límite de reglas?
Antes:
• Antes de 2022, el rate limiting se cobraba por tráfico: 5 USD por millón de peticiones
• Para sitios con mucho tráfico, el costo era considerable
Ahora no hay que preocuparse: Cloudflare anunció en su blog oficial que las reglas de rate limiting están incluidas en todos los planes, sin cargo extra.
En el plan gratuito puedes crear 1 regla de rate limiting; Pro y Business permiten más.
Diferencias principales entre plan gratuito y de pago:
• Cantidad de reglas (Free 1, Pro 10, Business 15)
• Características avanzadas (en planes de pago puedes usar condiciones más complejas, como Bot Score o huella JA3)
• Tiempo de respuesta (en planes de pago la respuesta es más rápida con alto tráfico)
Para sitios pequeños y medianos, 1 regla suele bastar. Lo clave es usarla donde más te atacan: normalmente login, registro o APIs críticas. En mis propios proyectos pequeños solo configuro 1 regla para proteger el login. Llevan casi un año funcionando sin problemas.
Aunque el plan gratuito solo tiene 1 regla de rate limiting, la protección DDoS básica de Cloudflare está incluida en todos los planes y sin límite de tráfico. Los DDoS evidentes se bloquean solos. El rate limiting apunta sobre todo a ataques CC más sutiles y al abuso de APIs.
¿Qué es un ataque CC? ¿Por qué el rate limiting lo frena?
• CC significa Challenge Collapsar: simula muchos usuarios normales visitando tu sitio hasta agotar los recursos del servidor
Diferencia entre CC y DDoS:
• El DDoS tradicional es más bruto: envía muchos paquetes basura con un patrón claro, y la protección DDoS automática de Cloudflare suele bloquearlo
• El CC es más astuto: envía peticiones HTTP normales, como si fueran personas reales, y la protección DDoS tradicional puede no detectarlo
Por ejemplo, un usuario normal puede abrir unas pocas páginas en un minuto, unas 5-10 peticiones. En un CC, una sola IP puede hacer más de 1000 peticiones en 30 segundos. Además, el atacante suele usar muchas máquinas o IPs proxy, repartiendo el tráfico y dificultando la defensa.
Datos de referencia:
• La documentación de mejores prácticas de Alibaba Cloud WAF indica que, en un CC típico, una máquina zombi puede superar las 1000 peticiones en 30 segundos
• Un usuario normal suele hacer menos de 10 peticiones por minuto
• La diferencia es evidente
Principio del rate limiting:
• Monitoriza la frecuencia de peticiones por IP (o sesión, clave API, etc.)
• Si supera el umbral que defines, actúa
• Puede mostrar un CAPTCHA para demostrar que eres humano o bloquear durante un tiempo
En un ataque que viví, la IP del atacante enviaba 200-300 peticiones por segundo y yo tenía un umbral de 20 por minuto. El tráfico malicioso activaba el límite en 1-2 segundos y el resto quedaba fuera. Los usuarios normales no lo activaban, así que la experiencia no se veía afectada.
¿Qué umbrales conviene usar según el escenario? ¿Qué diferencia hay entre login, API y páginas web?
Configuración recomendada en tres capas (oficial de Cloudflare):
• Capa 1: 4 peticiones/minuto → JavaScript Challenge
• Capa 2: 10 peticiones/10 minutos → CAPTCHA
• Capa 3: 20 peticiones/hora → bloqueo directo 1 día
En el plan gratuito solo hay 1 regla, así que hay que simplificar. Yo uso: 20 peticiones/60 segundos → bloqueo 10 minutos.
¿Cómo elegí ese umbral? Revisé los logs y vi que, aunque un usuario falle la contraseña, rara vez supera 5 intentos por minuto. Un script de ataque puede hacer cientos o miles por minuto. 20/min equilibra protección y falsos positivos.
Si tu sitio exige mucha seguridad, puedes ser más estricto: 10 peticiones/60 segundos → bloqueo 1 hora.
API (ajustar al negocio):
• API de consulta: 30 peticiones/10 segundos → JavaScript Challenge (≈3 peticiones/segundo, suficiente para muchas apps frontend)
• API intensiva (procesamiento de imágenes, análisis): 10 peticiones/60 segundos → limitación de velocidad
• API pública: según tu modelo de facturación y capacidad (API gratuita: 100 peticiones/hora; API de pago: límites por plan)
Páginas web (anti-scraping):
• Páginas normales: 100 peticiones/30 segundos → JavaScript Challenge
• Páginas especiales (búsqueda, descargas): 50 peticiones/60 segundos → CAPTCHA
¿Por qué umbrales tan altos en páginas normales? Al navegar, un usuario puede abrir varios enlaces rápido y cada página dispara CSS, JS e imágenes: docenas de peticiones. 100 en 30 segundos no afecta a usuarios reales, pero frena crawlers agresivos.
Ojo: no pongas límites muy estrictos en la home. Una vez limité demasiado la portada y bloqueé a Google y Bing; el SEO cayó.
¿Cómo configurar reglas de rate limiting en Cloudflare? ¿Cuáles son los pasos?
• Inicia sesión en Cloudflare, elige tu dominio
• Ruta: Security → WAF → Rate limiting rules
• Si no tienes reglas, verás el botón Create rule
• En el plan gratuito aparece 0/1 rules: puedes crear 1 regla
Paso 2: información básica
• Tras Create rule verás el formulario
• Rule name: un nombre claro, p. ej. Login-Rate-Limit o API-Protection
Paso 3: condiciones de coincidencia (Expression)
• Para proteger login:
- Field: URI Path
- Operator: equals
- Value: /api/login
• Para toda la API:
- Field: URI Path
- Operator: contains
- Value: /api/
Paso 4: parámetros de rate limiting (núcleo)
• Characteristics: IP Address (recomendado contra CC)
• Period: suelo usar 60 segundos
• Requests per period: login 20, API 30
• Duration: suelo usar 10 minutos
Ejemplo completo para login:
• Characteristics: IP Address
• Period: 60 seconds
• Requests: 20
• Duration: 10 minutes (más de 20 peticiones al login en 1 minuto desde la misma IP → bloqueo 10 min)
Paso 5: acción (Action)
• Managed Challenge (recomendado): Cloudflare distingue humano y bot; mejor UX si hay falso positivo
• Block: 403 directo; máxima protección, pero más riesgo de bloquear usuarios reales
Empieza con Managed Challenge; tras validar, puedes pasar a Block.
Paso 6: guardar y activar
• Deploy al final de la página; la regla entra en vigor al instante
Paso 7: verificar
• Prueba con curl o el navegador:
for i in {1..30}; do curl https://yourdomain.com/api/login; done
• Las primeras 20 deberían pasar; desde la 21, 429 o página de desafío
¿Qué errores habituales hay al configurar rate limiting? ¿Cómo evitar perjudicar usuarios reales y crawlers SEO?
• No pongas límites muy estrictos en la home ni en todo el sitio
• En un proyecto puse una regla global: 50 peticiones/30 segundos → bloqueo
• Tras una semana, Google Search Console mostró muchos errores de rastreo
• Google descarga CSS, JS e imágenes a la vez y activaba el límite
• Lo arreglé protegiendo solo login y API, sin limitar páginas de contenido
Recomendaciones:
• Login, registro y API: límites estrictos
• Contenido normal: límites laxos o ninguno
• Home: evita limitar si puedes
• Para anti-scraping avanzado, Bot Management (de pago) distingue crawlers buenos y malos
Error 2: el atacante evita Cloudflare
• Un conocido tenía rate limiting y aun así sufrió CC
• El atacante iba directo a la IP real del servidor
• Cloudflare es un proxy inverso; si conocen la IP de origen, saltan la protección
Soluciones:
1) Firewall del servidor solo para IPs de Cloudflare (listas IPv4/IPv6 oficiales en puertos 80 y 443)
2) Rotar la IP de origen si se filtró; no expongas la IP en DNS
3) Authenticated Origin Pulls: exige certificado de Cloudflare para confirmar el origen del tráfico
Error 3: no monitorizar ni ajustar
• Las reglas no son para siempre
• Revisa Security Analytics cada mes: peticiones bloqueadas, falsos positivos, tasa de 429
• Pocos 429 → puedes bajar umbrales; muchos 429 → súbelos o ajusta reglas
¿Cómo responder a ataques distribuidos? ¿Qué técnicas avanzadas hay?
• Los CC actuales usan muchas IPs proxy; cada IP pide poco y el límite por IP no basta
Métodos:
1) Contar por Session/Cookie (no por IP):
• Con sesión, cuenta por Session ID
• Aunque cambien de IP, la misma sesión sigue limitada
• Characteristics: Cookie y nombre de tu cookie de sesión
2) Filtrar por User-Agent:
• Muchos scripts usan User-Agent raros (Python, curl, etc.)
• Añade filtros en la expresión
3) Bot Management (de pago):
• Cloudflare puntúa cada petición 1-100; cuanto más bajo, más bot
• Puedes limitar solo Bot Score < 30
• Requiere Business o Enterprise
Estrategia progresiva (planes de pago):
• Capa 1 (laxa): umbral alto (p. ej. 30/min) → JS Challenge
• Capa 2 (media): 50/10 min → Managed Challenge
• Capa 3 (estricta): 100/hora → Block 24 h
Protección por región:
• Si tu negocio es sobre todo en China, puedes ser más estricto con tráfico extranjero
• En Expression: (ip.geoip.country ne "CN") and (http.request.uri.path eq "/api/login")
• Solo IPs fuera de CN reciben el límite estricto
• Ojo con VPN: mejor Challenge que Block directo
9 min de lectura · Publicado el: 1 dic 2025 · Actualizado el: 21 ago 2026
Cloudflare Full Stack
Si llegaste desde búsqueda, lo más rápido es ir al artículo anterior o siguiente de esta misma serie.
Anterior
Guía de reglas de firewall de Cloudflare para principiantes: 5 reglas gratuitas filtran el 80% del tráfico malicioso (plantillas incluidas)
¿Solo 5 reglas de firewall en el plan gratuito de Cloudflare? Esta guía ofrece plantillas WAF probadas en producción con filtros por IP, ASN, UA y rutas, te enseña a configurar prioridades paso a paso y filtrar el 80% del tráfico malicioso en 30 minutos, con código completo
Parte 6 de 23
Siguiente
Guía completa del escudo de 5 segundos de Cloudflare: 3 trucos de configuración para resolver problemas de SEO y experiencia
Explicación detallada del funcionamiento del escudo de 5 segundos de Cloudflare (modo Under Attack), su impacto en SEO y métodos de configuración precisa con Page Rules. Incluye 7 mejores prácticas y recomendaciones para optimizar el Challenge Passage, para que defiendas ataques DDoS minimizando el impacto negativo.
Parte 8 de 23
Comentarios
Inicia sesión con GitHub para dejar un comentario