El 18 de noviembre de 2025 a las 11:20 UTC (todas las horas de este blog corresponden a UTC), la red de Cloudflare comenzó a tener fallas importantes en la distribución del tráfico de red principal. Los usuarios de Internet que intentaban entrar en los sitios de nuestros clientes veían una página de error que señalaba una falla en la red de Cloudflare.
El problema no fue causado, ni directa ni indirectamente, por un ciberataque o una actividad maliciosa de ningún tipo. El incidente se desencadenó por una modificación en los permisos de uno de nuestros sistemas de bases de datos, lo que ocasionó que se generaran múltiples registros en un “archivo de características” usado por nuestro sistema de gestión de bots. A su vez, ese archivo de características duplicó su tamaño. El archivo de características, que resultó más grande de lo previsto, se distribuyó después a todas las máquinas de nuestra red.
El software que se ejecuta en estas máquinas para dirigir el tráfico a través de nuestra red lee este archivo de características para mantener nuestro sistema de gestión de bots actualizado con las amenazas en constante evolución. El software imponía un límite al tamaño del archivo de características, que resultó menor que el tamaño duplicado del archivo. Eso hizo que el software fallara.
Al principio sospechamos equivocadamente que los síntomas se debían a un ataque DDoS masivo, pero luego identificamos el problema real y logramos detener la propagación del archivo de características sobredimensionado, sustituyéndolo por una versión anterior.El tráfico principal fluía con normalidad en gran medida a las 14:30. En las horas posteriores nos dedicamos a reducir la sobrecarga en distintas áreas de nuestra red, mientras el tráfico regresaba rápidamente.A las 17:06, todos los sistemas de Cloudflare funcionaban con normalidad.
Lamentamos las consecuencias que esto tuvo para nuestros clientes y para la comunidad de Internet en general.Dada la importancia de Cloudflare en el ecosistema de Internet, cualquier interrupción de nuestros sistemas es inaceptable. Que nuestra red no haya podido enrutar tráfico durante un período es algo que afecta profundamente a cada integrante de nuestro equipo. Reconocemos que hoy te hemos decepcionado.
Esta publicación ofrece una explicación detallada de lo que sucedió y de los sistemas y procesos que fallaron. Este es apenas el inicio —aunque no el final— de las medidas que pensamos implementar para evitar que una interrupción como esta se repita.
El siguiente gráfico muestra el volumen de errores HTTP 5xx que se produjeron en la red de Cloudflare. Normalmente, este debería ser muy bajo, y lo fue hasta el comienzo de la interrupción.
El volumen anterior a las 11:20 es la línea de referencia esperada de errores 5xx observados en nuestra red. El pico y las fluctuaciones posteriores muestran que nuestro sistema está fallando debido a la carga del archivo de características incorrecto. Lo notable es que nuestro sistema se recuperaba durante un período. Fue un comportamiento muy inusual para 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 actualizaba 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 consecuencia, cada cinco minutos existía la posibilidad de que se generara un conjunto de archivos de configuración, ya sea bueno o malo, y que se propagara rápidamente por la red.
Esta fluctuación generó confusión sobre lo que estaba sucediendo, ya que el sistema completo se recuperaba y luego volvía a fallar, 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 generó el archivo de configuración incorrecto y la fluctuación se estabilizó en un estado de error.
Los errores continuaron hasta que se identificó y resolvió el problema subyacente a partir de las 14:30. Para resolver el problema, detuvimos la generación y la propagación del archivo de características erróneo e insertamos manualmente un archivo válido en la cola de distribución. Y luego, forzamos un reinicio de nuestro proxy central.
La cola larga restante en el gráfico anterior corresponde a nuestro equipo reiniciando los servicios restantes que habían entrado en un estado incorrecto, con el volumen de códigos de error 5xx que volvió a la normalidad a las 17:06.
Los siguientes servicios se vieron afectados:
Servicio / Producto | Descripción del impacto |
|---|
Servicios básicos de CDN y seguridad | Códigos de estado HTTP 5xx. La captura de pantalla en la parte superior de esta publicación muestra la página de error común que veían los usuarios. |
Turnstile | No se podía cargar Turnstile. |
Workers KV | Workers KV registró un aumento considerable de errores HTTP 5xx porque las solicitudes a su puerta de enlace principal fallaron al producirse un error en el proxy central. |
Panel de control | Si bien el panel funcionaba en gran medida, la mayoría de los usuarios no pudo acceder porque Turnstile no estaba disponible en la página de inicio de sesión. |
Seguridad del correo electrónico | Si bien el procesamiento y la distribución del correo electrónico no se vieron afectados, observamos una pérdida temporal de acceso a una fuente de reputación de IP. Esto redujo la eficacia de la detección de spam e impidió que se activaran algunas alertas sobre dominios nuevos, sin consecuencias críticas para los clientes. También observamos fallas en algunas acciones de movimiento automático. Todos los mensajes afectados han sido revisados y corregidos. |
Access | Las fallas de autenticación fueron generalizadas para la mayoría de los usuarios, desde que comenzó el incidente hasta que se aplicó la reversión a las 13:05. Las sesiones de Access que ya estaban activas continuaron funcionando sin problemas.
Cada intento de autenticación fallido mostraba una página de error, por lo tanto, ningún usuario pudo acceder a la aplicación mientras duró la falla.Los inicios de sesión exitosos durante este período se registraron correctamente durante este incidente.
Cualquier actualización de configuración de Access que se intentara en ese momento habría fallado por completo o se habría propagado muy lentamente. Todas las actualizaciones de configuración se han recuperado. |
Además de generar errores HTTP 5xx, notamos que las respuestas de nuestra CDN se volvieron mucho más lentas durante el período de impacto.La causa fue que nuestros sistemas de depuración y monitoreo consumieron mucho CPU, ya que agregan automáticamente información extra para entender mejor los errores que no se detectan.
Cómo Cloudflare procesa las solicitudes y por qué se produjo la falla de hoy
Cada solicitud a Cloudflare sigue una ruta bien definida a través de nuestra red. Podría provenir de un navegador que carga una página web, una aplicación móvil que llama a una API o tráfico automatizado de otro servicio. Las solicitudes se procesan primero en nuestra capa HTTP y TLS, después pasan al sistema de proxy central (denominado FL o “Frontline”) y finalmente a Pingora, que busca en la caché o trae los datos del servidor de origen si hace falta.
Anteriormente compartimos más detalles sobre cómo funciona el proxy central aquí.
Cuando una solicitud pasa por el proxy central, se activan los distintos servicios de seguridad y rendimiento de nuestra red. El proxy aplica la configuración personalizada de cada cliente, que incluye desde reglas de seguridad WAF y protección DDoS hasta el enrutamiento del tráfico hacia Developer Platform y R2.Esto se logra mediante un conjunto de módulos específicos del dominio que aplican las reglas de configuración y políticas al tráfico que pasa por nuestro proxy.
Uno de esos módulos, gestión de bots, fue la causa de la interrupción de hoy.
La gestión de bots de Cloudflare incluye, entre otros sistemas, un modelo de aprendizaje automático que utilizamos para generar puntuaciones de bots para cada solicitud que pasa por nuestra red. Nuestros clientes utilizan las puntuaciones de bots para controlar qué bots tienen autorización para acceder o no a sus sitios.
El modelo toma como entrada un archivo de configuración de "características". En este contexto, una característica es un rasgo individual que el modelo de aprendizaje automático utiliza para determinar si la solicitud se automatizó o no. El archivo de configuración de características es un conjunto de características individuales.
Este archivo de características se actualiza cada pocos minutos y se publica en toda nuestra red, lo que nos permite reaccionar a las variaciones en los flujos de tráfico en Internet. Nos permite reaccionar a nuevos tipos de bots y ataques de bots. Por lo tanto, es fundamental que se implemente de forma frecuente y rápida, ya que los ciberdelincuentes cambian sus tácticas con rapidez.
Un cambio en la forma en que ClickHouse ejecuta las consultas (explicado más adelante), que genera este archivo, hizo que se produjera una gran cantidad de filas de “características” duplicadas.Esto modificó el tamaño del archivo de configuración de funciones de tamaño fijo anterior, lo que provocó que el módulo de bots desencadenara un error.
Como consecuencia, el sistema proxy central que gestiona el procesamiento del tráfico de nuestros clientes generó códigos de error HTTP 5xx para todo el tráfico que dependía del módulo de bots. Esto también afectó a Workers KV y a Access, que dependen del proxy central.
Independientemente de este incidente, estábamos y actualmente estamos migrando el tráfico de nuestros clientes a una nueva versión de nuestro servicio proxy, conocido internamente como FL2. Ambas versiones se vieron afectadas por el problema, aunque el impacto observado fue diferente.
Los clientes implementados en el nuevo motor proxy FL2 observaron errores HTTP 5xx. Los clientes de nuestro anterior motor proxy, conocido como FL, no observaron errores, pero las puntuaciones de bots no se generaban correctamente, lo que hacía que todo el tráfico recibiera una puntuación de bot de cero. Los clientes que tenían reglas implementadas para bloquear bots habrían experimentado una gran cantidad de falsos positivos. Los clientes que no utilizaban nuestra puntuación de bot en sus reglas no experimentaron ningún impacto.
Otro síntoma que observamos que nos confundió y nos hizo pensar que podría haber sido un ataque fue que la página de estado de Cloudflare dejó de funcionar. La página de estado está alojada completamente fuera de la infraestructura de Cloudflare, y no depende de esta.Si bien resultó ser una coincidencia, esto hizo que algunos miembros del equipo que diagnosticaban el problema creyeran que un ciberdelincuente podría estar atacando tanto nuestros sistemas como nuestra página de estado. Los visitantes de la página de estado en ese momento recibieron un mensaje de error:
En la sala de chat de incidentes internos, nos preocupaba que esto pudiera ser la continuación de la reciente ola de ataques DDoS de gran volumen contra Aisuru.
El cambio en el comportamiento de la consulta
Se mencionó anteriormente que un cambio en el comportamiento de la consulta subyacente hizo que el archivo de características tuviera una gran cantidad de filas duplicadas. El sistema de base de datos en cuestión utiliza el software ClickHouse.
Para contextualizar, es útil saber cómo funcionan las consultas distribuidas de ClickHouse. Un clúster de ClickHouse se compone de muchos fragmentos. Para acceder a los datos de todos los fragmentos, usamos lo que se conoce como tablas distribuidas (con tecnología del motor de tablas Distributed) en una base de datos que se llama default. El motor Distributed consulta las tablas subyacentes en una base de datos r0. Las tablas subyacentes son el lugar donde se almacenan los datos en cada fragmento de un clúster de ClickHouse.
Las consultas a las tablas distribuidas se ejecutan mediante una cuenta de sistema compartida. Para reforzar la seguridad y confiabilidad de las consultas distribuidas, estamos trabajando para que se ejecuten directamente con las cuentas de usuario originales.
Hasta hoy, los usuarios de ClickHouse solo veían las tablas de la base de datos default cuando consultaban los metadatos de las tablas en los sistemas de ClickHouse, como system.tables o system.columns.
Como los usuarios ya tienen acceso implícito a las tablas subyacentes en r0, hicimos un cambio a las 11:05 para explicitar este acceso, de modo que los usuarios también puedan ver los metadatos de estas tablas. Al asegurarse de que todas las subconsultas distribuidas se ejecuten con el usuario inicial, los límites de consulta y las concesiones de acceso se pueden evaluar de forma más precisa, evitando que una subconsulta incorrecta de un usuario afecte a otros.
El cambio explicado anteriormente hizo que todos los usuarios accedieran a metadatos precisos sobre las tablas a las que tienen acceso. Lamentablemente, antes se pensaba que la lista de columnas que devolvía una consulta como esta solo incluiría la base de datos "default":
SELECT
name,
type
FROM system.columns
WHERE
table = 'http_requests_features'
order by name;
Observa que la consulta no filtra por el nombre de la base de datos. Con la implementación gradual de las concesiones explícitas a los usuarios de un determinado clúster de ClickHouse, después del cambio realizado a las 11:05, la consulta anterior comenzó a devolver “duplicados” de columnas porque estas correspondían a tablas subyacentes almacenadas en la base de datos r0.
Lamentablemente, este fue el tipo de consulta que usó la lógica de generación de archivos de la función de gestión de bots para elaborar cada "característica" de entrada para el archivo mencionado al principio de esta sección.
La consulta anterior devolvería una tabla de columnas como la que se muestra (ejemplo simplificado).
Sin embargo, como parte de los permisos adicionales que se concedieron al usuario, la respuesta ahora contenía todos los metadatos del esquema r0, lo que efectivamente duplicó con creces las filas en la respuesta, afectando en última instancia el número de filas (es decir, características) en el archivo de salida final.
Cada módulo que funciona en nuestro servicio de proxy cuenta con límites diseñados para impedir que la memoria se consuma sin control y para reservar memoria de forma anticipada, mejorando así el rendimiento. En este caso específico, el sistema de gestión de bots tiene un límite en la cantidad de características de aprendizaje automático que se pueden usar en tiempo de ejecución. Actualmente, ese límite está establecido en 200, muy por encima de nuestro uso actual de unas 60 características. Una vez más, el límite existe porque, por motivos de rendimiento, preasignamos memoria para las características.
Cuando el archivo defectuoso con más de 200 características se propagó a nuestros servidores, se alcanzó este límite, lo que provocó un error grave en el sistema. A continuación, se muestra el código FL2 Rust que hace la comprobación y fue el origen del error no controlado:
Esto causó el siguiente fallo crítico, lo que derivó en un error 5xx:
thread fl2_worker_thread panicked: called Result::unwrap() on an Err value
Otro impacto durante el incidente
Otros sistemas que dependen de nuestro proxy central se vieron afectados durante el incidente. Esto incluyó Workers KV y Cloudflare Access. El equipo pudo disminuir el impacto en estos sistemas a las 13:04, al aplicar un parche en Workers KV que permitió saltar el proxy central. Después de eso, todos los sistemas que dependen de Workers KV (incluido Access) registraron menos errores.
El panel de Cloudflare también resultó afectado porque internamente se utiliza Workers KV y porque Cloudflare Turnstile forma parte del proceso de inicio de sesión.
Turnstile se vio afectado por la interrupción, y como consecuencia los clientes sin una sesión activa en el panel no pudieron acceder.Esto se manifestó como una disponibilidad reducida durante dos periodos: de 11:30 a 13:10 y de 14:40 a 15:30, como se observa en el siguiente gráfico.
El primer período, de 11:30 a 13:10, se debió al impacto en Workers KV, servicio del que dependen ciertas funciones del sistema de control y del panel. Esto se restauró a las 13:10, cuando Workers KV evitó el sistema proxy central.
El segundo período de impacto en el panel ocurrió después de restaurar los datos de configuración de la función. Una acumulación de intentos de inicio de sesión comenzó a saturar el panel. Esta acumulación, junto con los intentos de reintento, generó una latencia elevada, lo que redujo la disponibilidad del panel. La ampliación de la concurrencia en el plano de control permitió recuperar la disponibilidad hacia las 15:30.
Pasos de seguimiento y corrección
Con los sistemas de nuevo activos y funcionando correctamente, ya iniciamos tareas para hacerlos más resistentes frente a fallas similares en el futuro. En particular, nosotros:
Estamos fortaleciendo el procesamiento de archivos de configuración creados por Cloudflare, tal como hacemos con los datos generados por los usuarios
Estamos habilitando más interruptores de desactivación globales para características
Estamos evitando que los volcados de memoria u otros informes de errores sobrecarguen los recursos del sistema
Estamos revisando los modos de fallas para las condiciones de error en todos los módulos proxy centrales
Hoy ha sido la peor interrupción de Cloudflare desde 2019. Hemos tenido interrupciones que han hecho que nuestro panel de control quedara inaccesible. Algunas de ellas han hecho que las características más nuevas no estuvieran disponibles durante un tiempo. Sin embargo, en los últimos seis años o más, no hemos vuelto a sufrir una interrupción que detuviera la mayoría del tráfico esencial en nuestra red.
Una interrupción como la de hoy es inaceptable. Hemos diseñado nuestros sistemas para que soporten fallas y aseguren que el tráfico nunca se detenga.Las interrupciones que hemos tenido en el pasado siempre han sido el motor para desarrollar sistemas más sólidos y resilientes.
En nombre de todo el equipo de Cloudflare, quisiera disculparme por las molestias que causamos hoy en Internet.
Hora (UTC) | Estado | Descripción |
|---|
11:05 | Normal. | Se implementó el cambio de control de acceso a la base de datos. |
11:28 | Comienza el impacto. | La implementación llega a los entornos de los clientes. Se observan los primeros errores en el tráfico HTTP del cliente. |
11:32-13:05 | El equipo investigó los niveles elevados de tráfico y los errores en el servicio de Workers KV.
| El primer síntoma fue una disminución en la velocidad de respuesta de Workers KV, que afectó a otros servicios de Cloudflare.
Se implementaron acciones de mitigación, como la manipulación del tráfico y la restricción de cuentas, para restablecer el servicio Workers KV a su nivel operativo habitual.
La primera prueba automatizada detectó el problema a las 11:31 y la investigación manual se inició a las 11:32. La llamada de incidente se creó a las 11:35. |
13:05 | Se implementó la omisión de Workers KV y Cloudflare Access y el impacto se redujo. | Durante la investigación aplicamos derivaciones internas en Workers KV y Cloudflare Access, lo que hizo que volvieran a una versión previa de nuestro proxy central.Aunque el problema también se presentaba en versiones anteriores de nuestro proxy, el impacto era menor, como se describe a continuación. |
13:37 | Se revirtió el archivo de configuración de gestión de bots a una versión anterior que funcionaba correctamente. | Estábamos seguros de que el archivo de configuración de la gestión de bots había desencadenado el incidente. Los equipos desarrollaron múltiples flujos de trabajo para reparar el servicio, destacando como el más ágil la recuperación de una versión anterior del archivo. |
14:24 | Se detuvo la creación y la propagación de nuevos archivos de configuración de gestión de bots. | Identificamos que el módulo de gestión de bots era el origen de los errores 500 y que esto se debió a un archivo de configuración defectuoso. Suspendimos la instalación automática de nuevos archivos de configuración de gestión de bots. |
14:24 | Prueba de archivo nuevo completada. | Se logró una recuperación satisfactoria con la versión anterior del archivo de configuración y luego se priorizó acelerar la solución a nivel global. |
14:30 | Impacto principal resuelto.Los servicios impactados en cascada empezaron a registrar menos errores. | Se implementó a nivel global un archivo de configuración válido de gestión de bots, y la mayoría de los servicios volvieron a funcionar con normalidad. |
17:06 | Todos los servicios se han resuelto. Termina el impacto. | Todos los servicios afectados se reiniciaron y las operaciones quedaron totalmente restablecidas. |