Loading...
Infraestructura

Falla de Cloudflare del 18 de noviembre de 2025: impacto y lecciones para empresas

Análisis técnico de la interrupción global, sus causas conocidas y cómo diseñar arquitecturas resilientes ante la dependencia de terceros.

Richard Emert • 20 de noviembre, 2025

El lunes 18 de noviembre de 2025, un fallo en la infraestructura de Cloudflare provocó una interrupción global que afectó a millones de sitios web, APIs y servicios empresariales durante más de 90 minutos. Empresas como Discord, Steam, Reddit, Shopify y varias instituciones financieras quedaron inaccesibles, generando pérdidas millonarias y afectando la confianza de los usuarios.

¿Qué ocurrió?

A las 15:47 UTC, Cloudflare reportó una anomalía en su sistema de enrutamiento global. Los servidores de DNS y proxy dejaron de responder a solicitudes, lo que provocó que cualquier dominio que use Cloudflare (incluyendo APIs y CDNs) devolviera errores de conexión o tiempos de espera.

En México y Latinoamérica, el impacto fue severo: bancos digitales, marketplaces y plataformas de e-learning quedaron inaccesibles durante la tarde, justo en horas pico de operación.

Causa raíz (según el comunicado de Cloudflare)

En su informe preliminar, Cloudflare confirmó que la falla fue causada por un cambio de configuración automatizado en sus routers de borde. Este cambio, destinado a optimizar el tráfico, introdujo una regla que generó un bucle de enrutamiento en su red global, saturando los sistemas y provocando una caída en cascada.

Lo más preocupante: el sistema de monitoreo no detectó la anomalía a tiempo porque las alertas estaban mal calibradas para este tipo de fallo.

Lecciones para empresas que dependen de terceros

Esta falla no es la primera (recordemos AWS en 2021, Fastly en 2021, o el ataque a Dyn en 2016), pero refuerza una verdad incómoda: la dependencia crítica de un solo proveedor es un riesgo empresarial. Aquí nuestras recomendaciones técnicas:

  1. Evita la dependencia monolítica: Si usas Cloudflare, asegúrate de que tu DNS primario esté en otro proveedor (ej: AWS Route 53) con TTL bajo para failover rápido.
  2. Implementa health checks externos: Usa servicios como Pingdom o Datadog para monitorear la disponibilidad desde múltiples regiones, no solo desde tu infraestructura.
  3. Diseña APIs con resiliencia: Tus aplicaciones móviles y web deben manejar errores de red con caché local y reintentos inteligentes, no con pantallas de error.
  4. Documenta tu plan de contingencia: ¿Qué haces si Cloudflare, AWS o tu proveedor de hosting falla? Ten un runbook claro y pruébalo cada 6 meses.

¿Debemos dejar de usar Cloudflare?

No. Cloudflare sigue siendo una herramienta esencial para seguridad, rendimiento y mitigación de DDoS. Pero su uso debe ser estratégico, no absoluto. La arquitectura ideal no es “Cloudflare vs. sin Cloudflare”, sino “Cloudflare con planes de contingencia”.

En Ingensoft, diseñamos nuestras arquitecturas con el principio de resiliencia multi-proveedor: incluso en proyectos pequeños, incluimos mecanismos de fallback para evitar puntos únicos de falla. Porque en infraestructura, lo que no se prueba, no existe.

RE

Richard Emert

CEO & Arquitecto de Soluciones en Ingensoft

Ha diseñado infraestructuras para clientes en sectores críticos (finanzas, salud, energía) con disponibilidad del 99.99%. Apasionado por la ingeniería de confiabilidad (SRE) y la arquitectura evolutiva.