Cloudflare: qué es, cómo funciona y cómo configurarlo para frenar DDoS

Qué es Cloudflare hoy: CDN, seguridad y red global

Cloudflare es, a la vez, CDN (red de entrega de contenidos) y capa de seguridad para aplicaciones y APIs. En términos simples, pone sus servidores en medio del tráfico entre tus usuarios y tu origen (tu hosting), actuando como proxy inverso. Con eso consigue dos objetivos: acelerar (porque sirve contenido cacheado desde nodos cercanos) y proteger (porque filtra y absorbe tráfico malicioso antes de que te alcance).

En mi día a día, me resulta útil pensar Cloudflare como “el borde” donde tomo decisiones rápidas: ¿esta petición es legítima?, ¿desde qué país viene?, ¿cuántas veces golpea el endpoint de login? Cuando empecé a usarlo, la mejora de tiempos fue evidente solo por cache estática (imágenes/CSS/JS) y compresión, pero el verdadero valor me llegó con el WAF y las reglas de Rate Limiting.

Puntos clave que siempre explico al equipo

CDN y cache: reduce latencia y consumo de ancho de banda del servidor.
Seguridad: WAF administrado + reglas personalizadas, mitigación DDoS en capa 3/4/7, y controles por país/ASN.
Servicios añadidos: 1.1.1.1 (DNS), WARP (cliente tipo VPN), Workers (código en el edge), Pages (deploy estático), Turnstile (desafíos sin captchas intrusivos).

En mis proyectos, Cloudflare ha sido el primer escudo contra DDoS. Sin tocar el origen, pude frenar picos de tráfico hostil y mantener la web operativa.

CDN y proxy inverso: velocidad y latencia

Activa cache estática con reglas por extensiones y TTLs sensatos.
Usa Argo/Smart routing si el presupuesto lo permite (en planes de pago) para saltos más eficientes.
Fuerza HTTP/2/3 y compresión Brotli, y habilita Early Hints si está disponible en tu plan.

WAF, Rate Limiting y mitigación DDoS: el stack de seguridad

Empieza por el WAF administrado (conjunto OWASP-like) y añade Custom Rules (método, ruta, IP, país, ASN, user-agent).
En rutas sensibles (login, /wp-login.php, /api/*): aplica Rate Limiting con umbrales por minuto/segundo y respuesta “challenge” o “block”.
Supervisa false positives y ajusta: primero agresivo, luego afinas.

Yo prefiero arrancar “firme” con WAF/Rate Limiting y luego aflojar según los falsos positivos. Es más fácil relajar que levantar una web ya tumbada.

Servicios clave: 1.1.1.1, WARP, Workers y Pages

1.1.1.1/WARP: útiles para navegación y pruebas, no sustituyen tu WAF.
Workers: lógica ligera en el edge (headers, AB testing, canary).
Pages: front estático rápido con CI integrado si tu stack lo permite.

Cómo protege de verdad contra DDoS (y qué límites tiene)

Un DDoS no es un único “tipo” de ataque: capa 3/4 (volumen/red) y capa 7 (HTTP y negocio). Cloudflare tiene defensa automática de base, pero el resultado real depende de tus reglas y de cómo diseñaste la app.

Capa 3/4 (volumen)

Normalmente no tocas nada: la red de Cloudflare absorbe y filtra.
Aun así, evita exponer el IP de origen (ponlo detrás de un firewall/allowlist solo para los rangos de Cloudflare).

Capa 7 (HTTP)

Define umbrales por ruta crítica y método (p. ej., POST /login).
Usa “challenge” (Turnstile/javascripts light) antes de bloquear; así separas bots de humanos.
Reglas por signature: bloquea user-agents sospechosos y patrones de scraping.

En un pico, las reglas por endpoint (API y login) salvaron la experiencia. Sin eso, la web quedaba “viva” pero inutilizable por saturación lógica.

Límites y buenas prácticas

No todo es Cloudflare: optimiza tu app (consultas, caché a nivel app, índices).
Ten observabilidad: logs al día, dashboards, alertas en tiempo real.
Define umbrales por entorno (staging vs producción).

Cuando Cloudflare se cae: checklist de continuidad de negocio

¿Puede caerse? Sí, como cualquier proveedor crítico. La diferencia la marca tu plan de contingencia.

Checklist práctico

Monitoreo: alerta en /status del proveedor + tu propio APM y uptime externo.
DNS y resolución: disponer de DNS alternativo documentado para un posible failover manual (no siempre trivial).
Bypass temporal: plan para publicar IP de origen (solo si está blindado) o puerta alternativa vía otro CDN si es esencial.
Cache en origen/CDN secundario: precarga de rutas críticas.
Comunicación: plantilla de estatus y mensajes a clientes (evita pánico).

El día que Cloudflare cae, la sensación es de ir a ciegas. Monitoring y “plan B” son obligatorios; yo lo aprendí en carne propia.

Bloqueos por país o rangos de IP: cómo no pegarte un tiro en el pie

Bloquear por geolocalización o rangos de IP puede reducir ruido, pero tiene coste en usuarios legítimos. Mencionas un caso real en España, donde el bloqueo de rangos complica accesos válidos.

Estrategia recomendada

Empieza por ASN (autonomous systems) conflictivos antes que por país completo.
Mantén listas de permitidos (IP/ASN) para socios y back-office.
Sustituye bloqueos duros por challenges suaves con Turnstile en rutas de riesgo.
Loguea por qué se bloqueó (regla, país, ASN) y ofrece canal de desbloqueo (ticket, header de verificación).

En España he visto bloqueos de rangos afectar a usuarios reales. Ajustar allowlists y desafíos me evitó soporte infinito y reseñas negativas.

Implementación paso a paso (plantilla de reglas)

WAF básico (rule sets + custom)

Activa WAF administrado y en “Simulación” 24–48 h: revisa hits.
Crea reglas custom por ruta:
- Bloquear POST a /wp-login.php con más de X intentos/min.
- Desafío si país ∈ {alto riesgo} y ruta coincide con /api/*.
- Bloquear user-agents vacíos o known bad.
Activa Bot Fight Mode (si aplica) con cuidado en APIs públicas.

Rate Limiting por rutas críticas (login, APIs)

Login: 10 req/min/IP → challenge 15 min; si reincide, block 1 h.
API: 100 req/min/API key; supera → 429 con Retry-After.
Formularios de contacto: 5 envíos/10 min/IP y desafío.

Logs y observabilidad para iterar

Exporta logs (Workers/Analytics/Logpush) a tu almacén (p. ej., S3/BigQuery).
Métricas diarias: solicitudes mitigadas, tasa de falsos positivos, tiempo de carga y contenido servido desde caché.
Revisa top reglas por impacto y ajusta quincenalmente.

A mí me funcionó un ciclo simple: publicar reglas → simular → medir → endurecer solo donde el dato lo pide.

Métricas que importan y cómo reportarlas a negocio

Rendimiento: TTFB, LCP, Core Web Vitals, % de aciertos de cache.
Seguridad: nº de solicitudes bloqueadas/mitigadas por tipo (DDoS, WAF, Rate Limit).
Coste: ancho de banda ahorrado vs coste del plan (Free/Pro/Business/Enterprise).
Fiabilidad: disponibilidad percibida (uptime), tiempos de incidencia y MTTR.

Truco de reporting: un panel mensual con 4 KPIs y 3 notas de contexto. Cuando mostré cuánto ancho de banda dejó de pagar el origen gracias a la cache, el argumento a favor de subir de plan salió solo.

Conclusión

Cloudflare es un acelerador y un escudo al mismo tiempo. Si configuras bien el WAF, aplicas Rate Limiting sensible y sustituyes bloqueos duros por desafíos inteligentes, frenas DDoS sin romper la experiencia. Y con un plan de contingencia claro para caídas, reduces el riesgo operativo. En mi caso, ha sido pieza clave en casi todos mis proyectos, con el matiz de vigilar bloqueos regionales (como en España) para no dañar a quien sí quiere entrar.

FAQs

¿Cloudflare es solo un CDN?
No. Es CDN + proxy inverso + WAF + mitigación DDoS + servicios en el edge (Workers/Pages) y herramientas como Turnstile y WARP.

¿Qué hago si tengo falsos positivos?
Pon reglas en Simulación, revisa logs, mueve “block” a “challenge”, añade allowlists de IP/ASN y ajusta umbrales por ruta.

¿Bloquear por país es buena idea?
Solo como último recurso. Empieza por ASN conflictivos, aplica desafíos y conserva un mecanismo de desbloqueo para usuarios legítimos.

¿Cómo preparo un plan B ante caídas?
Uptime externo, DNS alternativo documentado, opción de bypass (si el origen está protegido) y comunicación clara con clientes.