Cada vez que Cloudflare tiene una caída importante, Internet se acuerda de dos cosas al mismo tiempo. La primera: que depender tanto de un actor centralizado tiene costos reales. La segunda: que muchísima gente ya armó su operación alrededor de Cloudflare y salir de ahí no es tan simple como tuitear indignación por un rato.
Ese es el corazón del problema. Cuando un proveedor tan central se cae, no solo falla un CDN. Se afectan sitios, APIs, correos, paneles, resoluciones DNS, proxys, WAFs y una larga cadena de servicios que, en muchos casos, ya ni siquiera se perciben como dependencia explícita.
Por qué Cloudflare concentra tanto
La crítica a Cloudflare suele ser simultáneamente correcta e incompleta. Sí, la concentración excesiva es riesgosa. Pero también es cierto que Cloudflare resolvió, de forma muy accesible, problemas que muchos proveedores tradicionales resolvían peor, más caro o directamente no resolvían. DNS rápido, proxy, CDN, mitigación básica, certificados, WAF y una interfaz sencilla son una combinación difícil de ignorar.
Dónde aparece el riesgo real
El problema aparece cuando esa comodidad se transforma en dependencia estructural. Sitios que ya no saben operar sin el proxy encendido, equipos que no distinguen qué controla su origen y qué controla Cloudflare, DNS atados a una única plataforma sin plan alternativo.
Caso real: cuando la dependencia era invisible
Un cliente descubrió durante una caída de Cloudflare que su sistema de facturación dependía indirectamente de CF. Un plugin de WordPress cargaba assets desde un CDN de terceros que usaba Cloudflare como upstream. Nadie en el equipo lo sabía porque nunca había fallado antes. El problema no fue técnico: fue de inventario.
Este tipo de dependencia oculta es la más peligrosa porque no aparece en ningún diagrama de arquitectura.
Alternativas: sí, pero no mágicas
Existen alternativas, pero no siempre en el mismo paquete ni con el mismo costo operativo. Cambiar de proveedor no es solo mover un DNS.
Comparativa de alternativas CDN
| Proveedor | Precio base | WAF incluido | Configuración | Ideal para |
|---|---|---|---|---|
| Cloudflare Free | Gratis | Básico | Muy simple | Cualquier escala inicial |
| Bunny CDN | $0.01/GB | No | Simple | Contenido estático, media |
| Fastly | Pay-per-use | Sí | Developer-first | APIs, tráfico dinámico |
| AWS CloudFront | Pay-per-use | Vía Shield | Compleja | Ecosistema AWS |
| Akamai | Enterprise | Sí (avanzado) | Compleja | Grandes empresas con legacy |
Criterio REACTIV: Bunny es razonable para sitios de contenido con presupuesto limitado. Fastly es la alternativa técnica más sólida si el equipo tiene madurez DevOps. Akamai tiene sentido solo si ya estás en contratos enterprise.
Qué conviene preguntarse si dependes mucho de Cloudflare
- Qué parte de tu operación depende realmente de él
- Qué seguiría funcionando si el proxy falla
- Qué servicios no deberían vivir en la misma canasta
- Qué plan alternativo existe para DNS y publicación
- Cuánto de esa dependencia fue decisión y cuánto costumbre
Cómo auditar tu dependencia real: comandos y pasos
Paso 1: Identificar qué pasa por el proxy CF
bash# Ver si tu dominio resuelve a IPs de Cloudflare
dig +short tudominio.com
# Rango CF: 104.16.0.0/12, 172.64.0.0/13, 131.0.72.0/22Paso 2: Verificar que el origen responde sin el proxy
bash# Reemplaza IP-SERVIDOR con tu IP real de origen
curl -H "Host: tudominio.com" http://IP-SERVIDOR/ -ISi este comando falla o devuelve error, tu servidor no está preparado para operar sin CF.
Paso 3: Auditar dependencias ocultas
bash# Escanear assets HTML buscando dominios externos
grep -oP 'https?://[^\/"]+' index.html | sort -u
# Verificar cuáles de esos dominios resuelven a IPs CloudflarePaso 4: Configurar subdominio de emergencia sin proxy
En tu panel DNS de CF, crea un registro A con la nube gris, sin proxy:
bashorigin.tudominio.com → A → IP-SERVIDOR (proxy: OFF)Este subdominio es tu fallback manual si CF falla en modo proxy.
Arquitectura de fallback: 3 niveles según tu riesgo
| Nivel | Descripción | Cuándo aplica |
|---|---|---|
| Nivel 1 — Básico | Subdominio de origen sin proxy + monitoreo | Sites que pueden tolerar 30 min de caída manual |
| Nivel 2 — Intermedio | DNS secundario (ej: Route53 + CF) + health check automático | Operaciones críticas con SLA informal |
| Nivel 3 — Multi-CDN | Tráfico distribuido entre CF + Fastly/Bunny con failover automático | Servicios con SLA contractual, e-commerce, banca |
La lectura madura del tema
Muchas organizaciones criticaron a Cloudflare por sus caídas, pero habrían sufrido bastante más sin él durante años normales. Puede perjudicarte cuando falla, pero también probablemente te ayudó a evitar caídas, abuso, latencia innecesaria y configuraciones bastante peores durante mucho tiempo.
Conclusión corta
La conclusión útil no es “hay que salir de Cloudflare” ni tampoco “hay que confiarle todo”. Si lo usas, úsalo con criterio. Entiende qué parte de tu operación depende de él, qué podrías sostener si falla y qué no conviene delegar sin medir bien la dependencia.
Lo que este artículo NO cubre (y por qué)
Este análisis está enfocado en el riesgo de dependencia y las decisiones de arquitectura básica. No cubre:
- Cloudflare Workers y Edge Computing: es un tema propio con implicancias de arquitectura que merecen análisis separado.
- Cloudflare Zero Trust o ZTNA: reemplazar VPN con Zero Trust es una decisión de seguridad compleja que va más allá del CDN.
- Configuración avanzada de WAF y reglas: el tuning de WAF empresarial requiere contexto específico de cada operación.
- Gestión de Argo Smart Routing: optimización de red de pago con lógica propia.
Si alguno de esos temas te interesa para tu operación específica, ese es el punto donde conviene una conversación directa con criterio técnico, no un artículo genérico.