Cómo un archivo de características causó la peor caída de Cloudflare desde 2019

Un martes por la mañana a finales de noviembre, la web se tambaleó. No hubo mapas con alertas rojas parpadeantes ni advertencias apocalípticas dignas de una película de ciberataques de Hollywood. Se rompió de la forma más irritante que la mayoría de los usuarios conoce: páginas que no cargan, aplicaciones que se quedan pensando indefinidamente y pantallas de inicio de sesión que de pronto dejan de funcionar. Si estabas navegando alrededor de las 11:20 UTC del 18 de noviembre de 2025, probablemente pensaste que tu conexión wifi estaba fallando. Lo que ocurría en realidad era que un tramo vital del sistema circulatorio de internet fallaba de golpe.

Cloudflare sufrió su peor caída en 6 años. La compañía define su producto como la "nube de conectividad", una gigantesca red global que acelera sitios web, filtra ataques, sostiene APIs, gestiona autenticaciones, resuelve DNS y canaliza una porción abrumadora del tráfico mundial. Durante varias horas, Cloudflare no hizo nada de eso. En su lugar, repartió errores 5xx como si fueran confeti.

En cuanto estalló el problema, todo el mundo empezó a correr: administradores de sitios, equipos de desarrollo y usuarios corrientes que intentaban entrar a la web de su banco. Los propios ingenieros de Cloudflare también corrían contrarreloj, tratando de entender por qué los sistemas centrales de proxy colapsaban, las puntuaciones de bots fallaban y el tráfico oscilaba entre estados sanos y rotos a intervalos de 5 minutos.

Visto desde fuera parecía un ciberataque a gran escala, y los propios equipos internos de Cloudflare creyeron inicialmente que lo era. Incluso su página de estado externa se vino abajo, y esa página está alojada fuera de la infraestructura de Cloudflare. Era el tipo de coincidencia que resulta difícil atribuir al azar.

El culpable, sin embargo, resultó ser un simple archivo, en lugar de una banda de DDoS, un actor estatal o una nueva botnet exhibiendo músculo. Fue un archivo de características, un fichero de texto plano que duplicó su tamaño y rebasó un límite que llevaba tiempo esperando para estallar.

Dentro de ese archivo había un conjunto de características duplicadas, generadas por un cambio de permisos de base de datos bienintencionado. Aquella modificación era pequeña, rutinaria y teóricamente inofensiva, pero desencadenó una reacción en cadena que desconectó una parte masiva del tráfico global de internet.

Esta es la historia de cómo un único artefacto de configuración dentro del sistema de Bot Management de Cloudflare tumbó la mayor red perimetral del planeta.

La mañana en que internet se atragantó

El primer síntoma apareció alrededor de las 11:20 UTC: un pico repentino a escala mundial de errores HTTP 5xx en toda la red de Cloudflare. Estos errores no son extraños en la red pública, pero a través del troncal de Cloudflare deben mantenerse en niveles mínimos y constantes. Una explosión repentina indicaba que algo muy grave no funcionaba.

El pico resultaba desconcertante, y la oscilación lo era todavía más. El sistema fallaba, se recuperaba y volvía a caer cada 5 minutos, como un extraño latido artificial.

Los ingenieros revisaron de inmediato métricas, registros y trazas, barajando la hipótesis de un ataque masivo distribuido. Habían gestionado bastantes incidentes recientes, incluidos eventos a hiperrescala de estilo Aisuru. Pero los errores no encajaban con ningún patrón de tráfico malicioso reconocible. Algo se estaba destruyendo desde dentro.

Mientras tanto, los clientes de Cloudflare veían páginas que parecían rotas dentro de la propia infraestructura de Cloudflare. Las aplicaciones que dependían de Cloudflare Workers KV arrojaban fallos. Turnstile no cargaba en las páginas de acceso. La autenticación en Cloudflare Access dejó de responder para cualquiera que no tuviera una sesión ya abierta. Quienes recargaban la página no veían reintentos normales; chocaban directamente contra un muro.

Dentro de la empresa, los mensajes de alerta se multiplicaban por segundos. La caída simultánea de la página externa de estado avivó la sospecha de un ataque coordinado en curso. No lo era, pero en aquel momento la tensión estaba al límite.

Lo que nadie sabía todavía era que cada 5 minutos la red de Cloudflare se jugaba el tipo a cara o cruz. Con un archivo de configuración válido, todo funcionaba. Con uno corrupto, el núcleo del proxy entraba en pánico. Todo dependía del nodo de base de datos que atendiera la siguiente consulta.

El detonante: una actualización de permisos que parecía inofensiva

Todo este episodio comenzó en un clúster de ClickHouse, el motor de base de datos que alimenta parte de la canalización de analítica y características de aprendizaje automático de Cloudflare.

Los clústeres de ClickHouse están fragmentados en shards. La infraestructura de Cloudflare cuenta con 2 capas principales de base de datos: default, donde residen las consultas distribuidas, y r0, donde se alojan físicamente las tablas subyacentes en cada fragmento.

Históricamente, los usuarios que consultaban metadatos mediante tablas del sistema (como system.columns) solo veían las tablas del esquema default. Sin embargo, los ingenieros de Cloudflare estaban desplegando una mejora para que las consultas distribuidas se ejecutaran con el contexto del usuario que las iniciaba, en lugar de usar una cuenta compartida del sistema. El objetivo era intachable: menos permisos genéricos, mejor aislamiento y mayor control.

A las 11:05 UTC se activó una actualización de permisos que permitía a los usuarios de la base de datos ver explícitamente las tablas subyacentes también en r0, y ahí es donde todo se torció. La consulta empleada para generar el archivo de características de Bot Management era esta:

SELECT name, type
FROM system.columns
WHERE table = 'http_requests_features'
ORDER BY name;

Observa el filtro ausente: no especifica la base de datos. Antes del cambio de permisos eso no importaba, porque el sistema solo exponía los metadatos de una tabla. Tras el cambio, la consulta devolvió 2 conjuntos de características con nombres idénticos, uno procedente del esquema default y otro de r0. El resultado fueron características duplicadas, y esas duplicidades hicieron que el archivo resultante prácticamente doblara su tamaño.

Nadie podría considerar este archivo como un simple volcado de registros prescindible. Alimenta el modelo de aprendizaje automático por el que pasa cada petición de Cloudflare durante la evaluación de bots, y el proxy principal de cada servidor de Cloudflare lo carga en memoria con alta frecuencia. Es una de las piezas de configuración más sensibles de Cloudflare: se refresca constantemente y se distribuye a todo el planeta.

Cada proceso trabajador del proxy tenía un límite muy estricto: no podía manejar más de 200 características. Los modelos habituales utilizaban unas 60, por lo que los ingenieros tenían margen de sobra, hasta que de pronto dejó de haberlo.

En cuanto el archivo superó ese techo, el proxy sufrió un panic de Rust en FL2, la generación más reciente del motor perimetral de Cloudflare, tras toparse con una condición de error no gestionada en el cargador de características. El pánico provocó la caída del proceso, y esa caída sembró errores 5xx por doquier.

Por qué la red parpadeaba sin cesar

Cada 5 minutos, una tarea programada reconstruía el archivo de características de bots. Sin embargo, solo algunos nodos del clúster de ClickHouse habían recibido los nuevos permisos. Según el nodo que atendiera la consulta en cada instante, Cloudflare generaba una de 2 opciones:

• un archivo de configuración de características válido

o

• un archivo defectuoso, demasiado grande para cargarse

Un archivo correcto suponía la recuperación global; un archivo corrupto provocaba una caída generalizada. Este efecto de ruleta rusa complicó enormemente la investigación inicial. Cada vez que un equipo creía que la situación se estabilizaba, el siguiente ciclo de propagación volvía a romper la red en segundos.

Con el tiempo, el despliegue de permisos alcanzó a la totalidad de los nodos. En ese instante la red dejó de parpadear: el archivo generado pasó a ser defectuoso de manera constante y a romperlo todo sin interrupción. Solo entonces la caída se estabilizó en un fallo continuo y evidente.

El impacto en cascada: caídas en KV, fallos de inicio de sesión y puntuaciones a cero

En cuanto el proxy principal colapsó, los subsistemas subordinados cayeron en fila como piezas de dominó.

Workers KV cuenta con una pasarela frontal que depende de la ruta del proxy, por lo que sus errores 5xx se dispararon.

Turnstile, el componente de verificación humana de Cloudflare, simplemente dejó de cargar. Cualquier usuario que intentara acceder a un panel protegido con Turnstile quedó bloqueado.

La autenticación de Access falló para las sesiones nuevas. Quienes ya estaban conectados no tuvieron problemas, pero todos los demás se encontraron con pantallas de error.

En el panel de control de Cloudflare, la mayoría de los usuarios no pudo iniciar sesión durante casi toda la avería. Cuando el servicio se restauró parcialmente más tarde, una avalancha de reintentos provocó su propio atasco de tráfico.

El propio Bot Management reaccionó de manera distinta en el motor de proxy antiguo FL, donde las puntuaciones de bots no fallaban, sino que caían a 0. Esto provocó que los clientes con reglas de bloqueo basadas en esa puntuación empezaran a bloquearlo absolutamente todo, disparando los falsos positivos.

Así, la incidencia fue mucho más allá de un fallo puntual en una función secundaria: golpeó el mismísimo corazón del servicio.

El diagnóstico: el largo trayecto de la sospecha a la causa raíz

Los ingenieros detectaron aumentos bruscos de carga, reintentos y comportamientos anómalos. Probaron a aplicar límites de tasa y desvíos de tráfico para ver si el sistema se estabilizaba, pero nada daba resultado.

A las 13:05 UTC, casi 2 horas después del inicio del impacto, el equipo comenzó a puentear el proxy central para Workers KV y Access. Aquello alivió algunos síntomas y dio un respiro valioso.

Hacia las 13:37 UTC, los equipos estrecharon el cerco sobre el archivo de configuración de Bot Management como el detonante principal. Se abrieron varias líneas de trabajo en paralelo para auditar ClickHouse, revertir los cambios en la base de datos, analizar los registros de los equipos y rastrear la canalización de generación del archivo.

Por fin, a las 14:24 UTC, Cloudflare detuvo la generación y propagación de nuevos archivos de características. Inyectaron una versión que sabían que era correcta y la distribuyeron a toda la red. Hacia las 14:30, internet respiró aliviado y el tráfico principal volvió a fluir con normalidad.

El tramo final de la caída, prolongado hasta las 17:06 UTC, se dedicó a tareas de saneamiento: reiniciar servicios, vaciar colas, estabilizar cachés y depurar estados incoherentes. Para entonces, la causa raíz ya estaba perfectamente identificada: una presunción no documentada en un script generador que daba por sentado que la consulta devolvería una lista fija de columnas.

Lo que Cloudflare no intentó maquillar: esto no debió suceder

El propio CEO de Cloudflare escribió el análisis posterior al incidente. Es un gesto poco común que refleja la gravedad de lo ocurrido.

Fue su peor caída desde 2019 y la empresa no intentó esquivar responsabilidades. Los errores fueron evidentes:

• Una modificación de permisos de base de datos alteró el resultado de una consulta de forma imprevista.

• Un archivo de configuración crítico para modelos de ML carecía de validaciones ante datos mal formados.

• El proxy central no gestionó el exceso de límites con una degradación elegante; entró en pánico directamente.

• Los propios sistemas de depuración de errores consumieron suficiente CPU como para agravar la saturación.

• No existía un interruptor de emergencia que impidiera propagar una configuración dañada.

• La canalización de despliegue confiaba a ciegas en los datos internos.

Para una compañía que presume de resiliencia, redundancia y aislamiento de fallos a nivel de red, reconocer esto resultó sumamente doloroso.

Un momento muy humano: el temor interno a un ataque coordinado

Un detalle especialmente revelador de las conversaciones de la comunidad fue que los ingenieros de Cloudflare temieron de verdad estar bajo un ataque organizado. La caída accidental e independiente de la página de estado hizo pensar que alguien golpeaba a Cloudflare y a su monitor externo a la vez. No había ningún atacante, pero esa casualidad volvió caóticos los primeros compases de la respuesta.

Muchos clientes compartieron la misma sospecha en foros. Tras un año repleto de caídas masivas en grandes plataformas en la nube, los operadores no inventan fantasmas: han visto suficiente para saber que cuando internet tiembla, rara vez es por casualidad.

Reacciones de la comunidad: enfado, sorpresa y preguntas incómodas

En los debates posteriores a la caída, la comunidad planteó dudas de fondo muy razonables.

¿Por qué se tardó tanto en diagnosticar el problema? Muchos se preguntaron cómo la gestión de cambios no relacionó al instante la actualización de ClickHouse con el incidente.

¿Debería Cloudflare compensar a los clientes? El acuerdo de nivel de servicio ofrece créditos técnicos, pero los usuarios argumentan que eso no cubre las pérdidas reales del negocio.

¿Por qué da la impresión de que las caídas de Cloudflare son más frecuentes últimamente? Algunos señalaron incidentes recientes en otros gigantes de la nube, apuntando a que la fiabilidad de todo el sector parece resentirse.

¿Por qué forma parte Bot Management de la ruta crítica de las peticiones? Técnicamente tiene sentido, pero introduce un punto único de mala configuración que muy pocos clientes sospechaban que existiera.

Los comentarios reflejaban dudas prácticas más que rabia destructiva, nacidas de profesionales que necesitan que Cloudflare sea aburrido, constante e invisible.

Las soluciones y el camino por delante

Cloudflare detalló con total transparencia las medidas correctivas tras el análisis:

• Tratar la ingesta de archivos internos de configuración con el mismo rigor que las entradas no confiables de usuarios

• Incorporar interruptores de emergencia globales para detener despliegues de configuración descontrolados

• Mejorar el control de fallos en todos los módulos del proxy

• Evitar que los sistemas de depuración sobrecarguen la CPU durante situaciones de degradación

• Revisar los límites y las premisas de asignación de memoria

Es una lista ambiciosa, pero Cloudflare cuenta con un historial claro: cada gran avería impulsa una mejora arquitectónica. Su red actual es más resistente que la de 2019 gracias a los fallos superados, y tras este tropiezo saldrá todavía más reforzada.

Un solo archivo y una reacción en cadena planetaria

Resulta impresionante comprobar cómo un archivo de características duplicado, un simple conjunto de datos y no una línea de código ejecutable, pudo derribar cargas de trabajo en varios continentes. Ese es el mundo en el que operamos hoy: sistemas interconectados donde la premisa interna más modesta puede alcanzar un radio de impacto planetario.

No hubo atacantes ni redes de bots desbocadas. Una dependencia oculta, sacada a la luz por un cambio rutinario de permisos, se multiplicó por decenas de miles de servidores en cuestión de minutos.

Cloudflare pidió disculpas, asumió el error y puso en marcha las mejoras necesarias. Pero la lección va mucho más allá de Cloudflare. Internet es hoy un tejido de sistemas distribuidos que confían mutuamente en sus datos, sus canalizaciones y sus agentes automáticos. Cuando una sola premisa falla, la onda expansiva sacude a todos los demás. No resulta tranquilizador, pero así es exactamente como funciona la red actual.

El 18 de noviembre de 2025 un archivo de características duplicó su tamaño, y durante unas horas internet encogió a su paso.