El 18 de noviembre de 2025 pasará a la historia como el día en que Cloudflare, uno de los pilares fundamentales de la infraestructura de Internet, sufrió su peor caída desde 2019. Según el comunicado oficial de la empresa, un problema técnico interno causó que el sistema Bot Management generara un archivo de configuración con características duplicadas que superó el límite del sistema, paralizando gran parte de la red durante aproximadamente 6 horas (11:20 - 17:06 UTC). Desde redes sociales hasta herramientas de productividad, la dependencia global de esta infraestructura quedó en evidencia de la forma más dramática posible.
¿Qué es Cloudflare y por qué su caída es tan significativa?
Cloudflare es una empresa que ofrece servicios de seguridad y rendimiento para sitios web, actuando como intermediario entre los servidores y los usuarios finales. Su red de distribución de contenido (CDN) y protección contra ataques DDoS la convierten en un componente esencial para millones de sitios en todo el mundo. Según datos oficiales, Cloudflare gestiona aproximadamente el 20% del tráfico web global, protegiendo y acelerando millones de sitios web, aplicaciones y servicios.
Cuando Cloudflare experimenta problemas, el impacto se siente a nivel global. No es solo un servicio más: es la columna vertebral de gran parte de Internet moderna. Su infraestructura está diseñada para ser resiliente, pero incluso los sistemas más robustos pueden fallar bajo ciertas circunstancias extraordinarias.
Cronología detallada de la interrupción
Timeline del incidente (según comunicado oficial de Cloudflare)
- 11:05 UTC - Cambio en el control de acceso a la base de datos desplegado. Estado normal.
- 11:20 UTC - Comienza el impacto. El despliegue llega a los entornos de clientes, se observan los primeros errores en el tráfico HTTP de los clientes.
- 11:32 - 13:05 UTC - El equipo investiga niveles elevados de tráfico y errores en el servicio Workers KV. Se implementan mitigaciones como manipulación de tráfico y limitación de cuentas.
- 13:05 UTC - Se implementa bypass para Workers KV y Cloudflare Access, reduciendo el impacto.
- 13:37 UTC - El trabajo se centra en revertir el archivo de configuración de Bot Management a una versión conocida como buena.
- 14:24 UTC - Se detiene la creación y propagación de nuevos archivos de configuración de Bot Management. Se identifica que el módulo Bot Management era la fuente de los errores 500.
- 14:30 UTC - Impacto principal resuelto. Se despliega globalmente un archivo de configuración correcto de Bot Management y la mayoría de los servicios comienzan a operar correctamente.
- 17:06 UTC - Todos los servicios resueltos. Todos los servicios downstream reiniciados y todas las operaciones completamente restauradas.
Plataformas afectadas: el efecto dominó
La caída de Cloudflare tuvo un efecto dominó en múltiples servicios críticos. La lista de plataformas afectadas es impresionante y demuestra la dependencia global de esta infraestructura:
Incluso Downdetector, el sitio especializado en monitorear caídas de servicios, se vio afectado debido a su propia dependencia de Cloudflare. Esto creó una situación irónica donde la herramienta diseñada para detectar problemas estaba experimentando los mismos problemas que intentaba monitorear.
¿Qué pasó realmente? La explicación técnica oficial
Según el comunicado oficial de Cloudflare, el problema NO fue causado por un ciberataque o actividad maliciosa. En realidad, fue un problema técnico interno mucho más específico:
🔍 Causa raíz del incidente
El problema fue desencadenado por un cambio en los permisos de uno de los sistemas de base de datos (ClickHouse) que causó que la base de datos generara múltiples entradas duplicadas en un "archivo de características" utilizado por el sistema Bot Management de Cloudflare.
Este archivo de características se duplicó en tamaño y fue propagado a todas las máquinas de la red. El software que lee este archivo tenía un límite de tamaño que estaba por debajo del tamaño duplicado, causando que el software fallara y generara errores HTTP 500.
El problema técnico en detalle
El sistema Bot Management de Cloudflare utiliza un modelo de machine learning que requiere un archivo de configuración de "características" (features). Este archivo se actualiza cada pocos minutos y se distribuye a toda la red para mantener el sistema actualizado contra nuevas amenazas de bots.
El problema comenzó cuando un cambio en el control de acceso a la base de datos ClickHouse (desplegado a las 11:05 UTC) causó que una consulta generara filas duplicadas en la respuesta. Esto duplicó el número de características en el archivo final, aumentando su tamaño más allá del límite de 200 características que el sistema tenía configurado.
💡 ¿Por qué había un límite?
Cloudflare tiene un límite de 200 características para el sistema Bot Management porque, por razones de rendimiento, preasigna memoria para las características. Normalmente utilizan aproximadamente 60 características, por lo que el límite de 200 estaba muy por encima del uso normal. Cuando el archivo con más de 200 características llegó a los servidores, se alcanzó el límite y el sistema entró en pánico (panic), generando errores 500.
Lo que hizo este incidente especialmente confuso fue que el archivo se generaba cada cinco minutos, y solo se generaba incorrectamente si la consulta se ejecutaba en una parte del clúster ClickHouse que había sido actualizada. Esto causó que el sistema se recuperara y fallara alternativamente, haciendo que inicialmente pareciera un ataque DDoS a gran escala.
Impacto global: servicios afectados según Cloudflare
Según el comunicado oficial de Cloudflare, los siguientes servicios fueron impactados durante el incidente:
Servicios afectados:
- Core CDN y servicios de seguridad: Errores HTTP 5xx en tráfico de clientes
- Turnstile: Falló al cargar, impidiendo el acceso al dashboard
- Workers KV: Nivel significativamente elevado de errores HTTP 5xx
- Dashboard: La mayoría de usuarios no pudieron iniciar sesión debido a Turnstile
- Email Security: Pérdida temporal de acceso a fuente de reputación IP, reduciendo precisión de detección de spam
- Cloudflare Access: Fallos de autenticación generalizados desde el inicio del incidente hasta las 13:05 UTC
Además de los errores HTTP 5xx, Cloudflare también observó aumentos significativos en la latencia de las respuestas de su CDN durante el período de impacto. Esto se debió a que grandes cantidades de CPU fueron consumidas por los sistemas de depuración y observabilidad que automáticamente mejoran los errores no capturados con información adicional de depuración.
Lecciones aprendidas: ¿qué podemos hacer?
Este incidente subraya la necesidad crítica de contar con sistemas redundantes y estrategias de mitigación para enfrentar posibles fallos en servicios críticos. La comunidad tecnológica debe reflexionar sobre cómo construir una Internet más robusta y menos susceptible a interrupciones masivas.
💡 Recomendaciones para empresas
- Diversificación de proveedores: No depender exclusivamente de un solo proveedor de CDN o infraestructura.
- Plan de contingencia: Tener planes de respaldo claros y probados regularmente.
- Monitoreo proactivo: Implementar sistemas de alerta temprana para detectar problemas antes de que afecten a los usuarios.
- Comunicación transparente: Mantener a los usuarios informados durante incidentes.
- Análisis post-mortem: Realizar análisis detallados después de cada incidente para prevenir futuros problemas.
Conclusión: un recordatorio de la fragilidad de Internet
La caída de Cloudflare del 18 de noviembre de 2025 dejó en evidencia la vulnerabilidad de Internet cuando uno de sus principales proveedores experimenta problemas. Millones de usuarios y empresas se vieron afectados, resaltando la importancia de diversificar las dependencias tecnológicas y fortalecer la resiliencia de la infraestructura digital.
Este incidente histórico nos recuerda que, aunque Internet parece omnipresente y robusta, sigue siendo una red compleja de sistemas interdependientes. Un solo punto de fallo puede tener consecuencias globales. La lección es clara: la redundancia y la preparación no son opcionales, son esenciales.
¿Necesitas ayuda con tu infraestructura IT?
En everyWAN ayudamos a las empresas a construir infraestructuras resilientes y preparadas para cualquier eventualidad. Contacta con nosotros para una consultoría personalizada.
Contactar con everyWAN
Microsoft 365
ES 
CAT 
EN