Cae otra nube, toca el turno a Cloudflare
Cae otra nube, toca el turno a Cloudflare. La interrupción global de Cloudflare es la última de una tendencia continua de proveedores de infraestructura que se desconectan, dejando grandes extensiones de internet fuera de servicio. Una interrupción similar de AWS el mes pasado también tuvo repercusiones en todo el mundo.
Cloudflare gestiona aproximadamente el 20 % del tráfico global de internet, pero da servicio a un tercio de los sitios web más importantes del mundo, lo que se traduce en decenas de miles de empresas y servicios. Impulsa a minoristas como Shopify, proveedores de IA como OpenAI y Anthropic, así como aplicaciones para smartphones, servicios de streaming y soluciones de software empresarial. Cuando Cloudflare falla, las repercusiones afectan a todos los sectores empresariales, y algunos clientes tardan horas o incluso días en restablecer el servicio, explica Emarketer.
La analista agrega que que las interrupciones son más frecuentes y tardan más en solucionarse. Esto es un síntoma de una infraestructura sobrecargada: el aumento de la carga de IA, la demanda de streaming y el envejecimiento de la capacidad están llevando a los sistemas al límite. Lo ideal sería que las empresas que dependen de Cloudflare diversificaran su conectividad más allá de un solo proveedor; la redundancia es la única forma segura de garantizar la continuidad del negocio ante interrupciones globales.
La firma publicó que el 18 de noviembre de 2025 a las 11:20 UTC, la red de Cloudflare comenzó a experimentar fallos importantes en la entrega del tráfico de red principal. Los usuarios de Internet que intentaban acceder a los sitios de nuestros clientes veían una página de error que indicaba un fallo en la red de Cloudflare.
HTTP error page displayed during the incident
El problema no fue causado, ni directa ni indirectamente, por un ciberataque o actividad maliciosa de ningún tipo. En su lugar, se originó por un cambio en los permisos de uno de nuestros sistemas de bases de datos, lo que provocó que la base de datos generara diversas entradas en un “archivo de funcionalidades” utilizado por Bot Management, nuestro sistema de gestión de bots. A su vez, ese archivo duplicó su tamaño. A continuación, el archivo de funcionalidades de tamaño superior al esperado se propagó a todas las máquinas que componen nuestra red.
El software que se ejecuta en estas máquinas para enrutar el tráfico a través de nuestra red lee este archivo de funcionalidades para mantener nuestro sistema de gestión de bots actualizado con las amenazas en constante cambio. El software tenía un límite en el tamaño del archivo de funcionalidades que era inferior al doble de su tamaño. Eso hizo que el software fallara.
Después de sospechar erróneamente que los síntomas que observábamos eran consecuencia de un ataque DDoS a gran escala, identificamos correctamente el problema principal y pudimos detener la propagación del archivo de funcionalidades, que era más grande de lo esperado, y sustituirlo por una versión anterior del mismo. A las 14:30, el tráfico principal funcionaba con normalidad en su mayor parte. Durante las siguientes horas, trabajamos para mitigar el aumento de la carga en varias partes de nuestra red, a medida que el tráfico volvía a estar en línea. A las 17:06, todos los sistemas de Cloudflare funcionaban con normalidad.
Lamentamos el impacto causado a nuestros clientes y a la red de Internet en general. Dada la importancia de Cloudflare en el ecosistema de Internet, cualquier interrupción de cualquiera de nuestros sistemas es inaceptable. El hecho de que durante un tiempo nuestra red no pudiera enrutar el tráfico ha sido muy difícil para todos los miembros de nuestro equipo. Sabemos que hoy os hemos decepcionado.
Esta publicación explica en detalle lo que sucedió exactamente y qué sistemas y procesos fallaron. También es el comienzo, aunque no el final, de lo que pensamos hacer para garantizar que no vuelva a producirse una interrupción como esta.
La interrupción
El siguiente gráfico muestra el volumen de códigos de estado de error HTTP 5xx servidos por la red de Cloudflare. Normalmente, debería ser muy bajo, y lo fue hasta el comienzo de la interrupción.
Volume of HTTP 5xx requests served by the Cloudflare network
El volumen anterior a las 11:20 h. es la línea base esperada de errores 5xx observados en nuestra red. El pico y las fluctuaciones posteriores muestran que nuestro sistema falla debido a la carga de un archivo de funcionalidades incorrecto. Lo más destacable es que nuestro sistema se recuperó durante un tiempo. Era un comportamiento muy inusual para tratarse de un error interno.
La explicación era que el archivo se generaba cada cinco minutos mediante una consulta que se ejecutaba en un clúster de base de datos ClickHouse, que se estaba actualizando gradualmente para mejorar la gestión de permisos. Los datos erróneos solo se generaban si la consulta se ejecutaba en una parte del clúster que se había actualizado. Como resultado, cada cinco minutos existía la posibilidad de que se generase un conjunto de archivos de configuración, ya fuesen correctos o incorrectos, y que se propagasen rápidamente por la red.
Esta fluctuación no permitía determinar qué estaba sucediendo, dado que el sistema completo se recuperaba para luego fallar nuevamente, debido a la distribución intermitente de archivos de configuración correctos e incorrectos en nuestra red. Inicialmente, esto nos llevó a creer que podría deberse a un ataque. Finalmente, cada nodo de ClickHouse generaba el archivo de funcionalidades erróneo y la fluctuación se estabilizó en un estado de fallo.
Los errores continuaron hasta que se identificó y resolvió el problema subyacente a partir de las 14:30 h. Resolvimos el problema deteniendo la generación y la propagación del archivo de funcionalidades defectuoso e insertando manualmente un archivo válido en la cola de distribución de archivos de funcionalidades. A continuación, forzamos un reinicio de nuestro proxy principal.
La cola larga restante en el gráfico anterior corresponde al reinicio por parte de nuestro equipo de los servicios pendientes que habían entrado en un estado de error. El volumen de códigos de error 5xx volvió a la normalidad a las 17:06 h.