La mayor extensión del 18 de noviembre de Cloudflare - Un resumen

El 18 de noviembre de 2025, una gran parte de Internet se cayó.
Si abrías ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase, o un sinfín de sitios más pequeños, te encontrabas con una página de error 5xx de Cloudflare, o simplemente no se cargaban. Lo que al principio parecía otro gran momento de "Internet está roto" resultó ser algo más sutil y, en cierto modo, más preocupante: un error autoinfligido en lo más profundo de la propia infraestructura de Cloudflare.

A continuación se muestra un recorrido detallado de lo que sucedió en la interrupción de Cloudflare de ayer (18 de noviembre de 2025), por qué sucedió, a quién afectó y qué lecciones deberían aprender los equipos de infraestructura.

¿Qué ocurrió realmente ayer?

El martes 18 de noviembre de 2025, hacia el final de la mañana UTC, Cloudflare comenzó a devolver grandes volúmenes de errores de servidor HTTP 5xx para el tráfico que pasaba por su red. Para los usuarios finales, eso significaba páginas de "Error interno del servidor" o "Error de puerta de enlace" al intentar acceder a muchos sitios web y aplicaciones populares.

Según el propio blog de Cloudflare posterior al incidente, la interrupción:

• Comenzó a afectar al tráfico HTTP de los clientes a las 11:28 UTC

• Se produjeron errores 5xx generalizados en la CDN principal y en los servicios de seguridad.

• Se tomaron importantes medidas de mitigación alrededor de las 13:05-14:30 UTC

• El volumen de errores 5xx volvió a la línea de base a las 17:06 UTC El blog de Cloudflare

La propia Cloudflare lo describió como su peor interrupción desde 2019, ya que no solo afectó a una función o panel de control: interrumpió la capa proxy central que enruta la mayor parte del tráfico de los clientes a través de su red. El blog de Cloudflare

El monitoreo de terceros respaldó esto. Cisco ThousandEyes observó una interrupción global que afectaba a Cloudflare, con tiempos de espera y errores 5xx en servicios como X, OpenAI (ChatGPT) y Anthropic, mientras que las rutas de red parecían en buen estado. Eso apuntaba fuertemente a un fallo del servicio backend, no a un problema a nivel de ISP o de enrutamiento. ThousandEyes

¿Quién se vio afectado?

Dado que Cloudflare se encuentra frente a una parte masiva de Internet (alrededor del 20% de los sitios web confían en Cloudflare para el rendimiento y la seguridad), el radio de explosión fue enorme. AP Noticias+1

Entre los servicios afectados:

• ChatGPT / OpenAI

• X (antes Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends y otras plataformas de juegos

• Varios sitios de transporte público y gubernamentales, como New Jersey Transit y los sistemas digitales de los ferrocarriles franceses SNCF AP News+1

Los rastreadores de interrupciones, como Downdetector, registraron miles de informes de incidencias simultáneas en el momento álgido. Reuters informó de unos 5.000 usuarios afectados sólo para X en un momento dado, antes de que los recuentos disminuyeran a medida que se iban aplicando las correcciones. Reuters

Desde la perspectiva del usuario, esto se manifestó como:

• Los sitios no se cargaban en absoluto

• Los flujos de inicio de sesión se bloqueaban o fallaban (especialmente en el caso de Cloudflare Access o Turnstile).

• Las API responden de forma intermitente o con errores 5xx.

• Cuadros de mando y paneles de administración fuera de tiempo

En otras palabras: grandes partes de Internet "se sentían caídas", aunque la causa principal se concentraba en los sistemas internos de un único proveedor.

Cómo funciona Cloudflare normalmente (en términos sencillos)

Para entender por qué esta interrupción fue tan grave, es útil conocer el recorrido aproximado de una solicitud a través de la red de Cloudflare.

Cloudflare actúa como proxy inverso CDN y capa de seguridad:

1. Su navegador o aplicación se conecta a Cloudflare en lugar de directamente al sitio de origen.

2. Cloudflare termina TLS y HTTP en su extremo.

3. Las solicitudes fluyen hacia el sistema proxy central de Cloudflare, denominado FL ("Frontline") y su nueva generación FL2.

4. Ese proxy central

   • Aplica reglas WAF (cortafuegos de aplicaciones web)

   • Ejecuta modelos de gestión de bots

   • gestiona la protección DDoS, el almacenamiento en caché y la salida al origen

   • Enruta el tráfico a otros productos internos como Workers, R2, Access, etc. El blog de Cloudflare

En funcionamiento normal esta arquitectura es altamente resistente: si un centro de datos tiene un problema, el tráfico se enruta a través de otros; los cambios de configuración se despliegan cuidadosamente; las características individuales deben fallar de forma contenida.

La interrupción de ayer fue precisamente mala porque el fallo estaba dentro de la propia ruta proxy común, y estaba estrechamente vinculado a un archivo de configuración que se envía a todo el mundo con frecuencia y de forma automática.

La causa raíz: un archivo de gestión de bots que se ha estropeado.

La explicación oficial de Cloudflare apunta a un culpable clave:
un archivo de configuración de funciones utilizado por su sistema de gestión de bots. El blog de Cloudflare

Esta es la cadena de acontecimientos en lenguaje sencillo:

1. Bot Management utiliza un "archivo de características"

   • El modelo de detección de bots de Cloudflare se basa en un conjunto de "características", señales sobre cada solicitud que se utilizan para decidir si se trata de un humano o de un bot.

   • Estas características se agrupan en un archivo de configuración que se regenera cada pocos minutos y se despliega globalmente, para que Cloudflare pueda adaptarse rápidamente a los nuevos patrones de ataque. El blog de Cloudflare

2. Un cambio en el comportamiento de consulta de ClickHouse

   • El archivo de características se genera mediante consultas a una base de datos de ClickHouse.

   • Cloudflare hizo un cambio alrededor de las 11:05 UTC para mejorar la seguridad y los permisos para las consultas distribuidas - permitiendo a los usuarios ver los metadatos no sólo de un esquema por defecto, sino también de las tablas r0 subyacentes. El blog de Cloudflare

   • La consulta que construye la lista de características no filtró por nombre de base de datos; de repente empezó a obtener columnas duplicadas tanto de default como de r0, duplicando efectivamente el número de filas de características.

3. El archivo de características aumentó de tamaño

   • El módulo de Gestión de Bots tiene un límite estricto sobre el número de características que acepta (fijado en 200, muy por encima de las ~60 que se utilizan normalmente).

   • Cuando el nuevo archivo generado excedió ese límite, el módulo alcanzó el límite y entró en pánico, debido a un error no manejado en el código Rust que usaba Result::unwrap() en un valor de error. El blog de Cloudflare

4. Los servicios proxy del núcleo han empezado a devolver errores 5xx

   • Debido a que Bot Management está integrado en la ruta del proxy principal, el pánico surgió como respuestas HTTP 5xx para cualquier tráfico que dependiera de ese módulo.

   • En el nuevo motor FL2, los clientes vieron errores 5xx explícitos.

   • En el motor FL más antiguo, las puntuaciones de bots pasaban silenciosamente a cero, lo que podía causar falsos positivos en las reglas de bloqueo de bots. El blog de Cloudflare

5. La parte realmente desagradable: el archivo cambiaba entre "bueno" y "malo".

   • El clúster ClickHouse se actualizaba gradualmente, y el archivo de características se regeneraba cada cinco minutos.

   • A veces la consulta se ejecutaba en nodos actualizados (produciendo un archivo malo), a veces en nodos no actualizados (produciendo un archivo bueno).

   • Eso significaba que, durante un tiempo, la red de Cloudflare oscilaba entre el funcionamiento normal y el fallo a medida que se propagaban las diferentes versiones del archivo. El blog de Cloudflare

Esta oscilación hizo que la situación fuera extremadamente confusa internamente. Al principio, los equipos de Cloudflare sospecharon de un ataque DDoS masivo porque el patrón de error no parecía un simple fallo de software. Incluso la página de estado de Cloudflare, que está alojada fuera de su propia infraestructura, mostró brevemente errores, una coincidencia que alimentó aún más la sospecha de un ataque externo. El blog de Cloudflare+1

Sólo cuando se dieron cuenta de que el factor común era el archivo de características del bot se aclaró el panorama.

Cronología del incidente

Basándonos en la autopsia de Cloudflare y en los informes de terceros, podemos elaborar una cronología aproximada del 18 de noviembre de 2025: El Blog de Cloudflare+2MilOjos+2

• 11:05 UTC - Se implementa un cambio de control de acceso a la base de datos en ClickHouse.

• 11:20-11:30 UTC - Se empiezan a generar y propagar versiones incorrectas del archivo de funciones de gestión de bots.

• 11:28 UTC - Primer impacto en clientes: se observan errores HTTP 5xx elevados en el tráfico de clientes.

• 11:30-11:32 UTC - Las herramientas de monitorización externa y las pruebas automatizadas empiezan a detectar fallos intermitentes.

• 11:35 UTC - Cloudflare abre una llamada de incidencia interna; comienza la investigación.

• ~11:48 UTC - Cloudflare publica una actualización de estado confirmando un incidente. Se reenvía

• 11:30-13:05 UTC - Los equipos se centran en lo que parece ser un comportamiento degradado de Workers KV e investigan múltiples causas posibles (incluidos escenarios de ataque).

• 13:05 UTC - Mitigación clave: Workers KV y Cloudflare Access se cambian para eludir el proxy central; se reduce el impacto. El blog de Cloudflare

• 14:30 UTC - Se identifica la causa raíz; se detiene la generación y propagación de archivos de características defectuosos. Se inserta manualmente un archivo de configuración conocido como bueno y se reinicia el proxy central. La mayor parte del tráfico del núcleo vuelve a la normalidad. El blog de Cloudflare

• 14:40-15:30 UTC - Los problemas con el panel de control y el inicio de sesión persisten mientras Turnstile y la acumulación de intentos de autenticación crean picos de carga secundarios. El blog de Cloudflare

• 17:06 UTC - Las tasas de error vuelven a la línea de base; Cloudflare declara que los sistemas son completamente normales. El blog de Cloudflare

Desde el punto de vista del usuario, la interrupción se sintió peor entre el final de la mañana y el principio de la tarde UTC, aunque las ventanas de impacto exactas variaron según la región y según los productos de Cloudflare de los que dependía cada servicio.

Por qué esta interrupción es tan importante

Riesgo de centralización

Cloudflare forma parte de un pequeño conjunto de proveedores centrales de infraestructuras de Internet, junto con las principales plataformas en la nube (AWS, Azure, GCP) y otras grandes CDN. Cuando uno de estos actores falla, el impacto es amplio y a menudo no evidente.

Esta interrupción:

• No vino de un percance de enrutamiento BGP o un corte de cable ISP.

• No se debió a un ataque malintencionado (a pesar de las sospechas iniciales).

• Vino de un único error de configuración y límites en un componente interno.

Esto es importante porque muestra cómo los sistemas complejos y estrechamente acoplados pueden fallar catastróficamente incluso sin interferencias externas. Cuando muchas organizaciones se basan en el mismo proveedor, éste se convierte de facto en una pieza sistémicamente importante de Internet.

Las dependencias "blandas" también perjudican

Algunos de los servicios afectados no sólo utilizaban Cloudflare como una CDN tonta. Lo hacían:

• Usando Cloudflare Access para autenticación y acceso de confianza cero.

• Utilizando Workers KV como parte de los planos de control interno.

• Confiar en Turnstile para inicios de sesión resistentes a bots. El blogde Cloudflare+1

Cuando estos productos fallan, no sólo se cae el contenido del sitio web, sino también los inicios de sesión, las funciones de administración y las API internas. Esto hace que la recuperación sea más compleja: la página de estado, las herramientas de incidencias o la interfaz de administración también pueden depender del mismo proveedor que acaba de fallar.

Lo que Cloudflare dice que va a cambiar

En el blog de Cloudflare se describen varias medidas correctivas que la empresa ya está tomando para reducir el riesgo de que vuelva a ocurrir algo similar: El blog de Cloudflare

1. Endurecer la ingestión de archivos de configuración autogenerados
   Trate las configuraciones generadas internamente con el mismo escepticismo y validación que las entradas suministradas por el usuario, incluyendo una comprobación estricta del esquema y el tamaño antes de su despliegue.

2. Más interruptores de desactivación globales
   Facilite la desactivación rápida de módulos internos problemáticos (como la gestión de bots) en toda la red, para que fallen al abrirse en lugar de provocar el pánico en toda la ruta del proxy.

3. Proteger los recursos del sistema de las tormentas de errores
   Asegúrese de que los volcados del núcleo, los metadatos de depuración y las herramientas de observabilidad no puedan saturar la CPU y la memoria cuando los errores empiecen a aumentar.

4. Revise los modos de fallo en los módulos proxy del núcleo
   Audite sistemáticamente cómo se comporta cada módulo interno ante entradas o configuraciones inesperadas, y garantice una degradación gradual en lugar de un fallo global.

5. Perfeccione los despliegues y el aislamiento
   Aunque no se ha explicado con gran detalle, el incidente sugiere que Cloudflare probablemente segmentará aún más cómo se propagan las nuevas configuraciones y los comportamientos de la base de datos, para reducir la posibilidad de que un solo cambio erróneo afecte a toda la flota.

También enmarcaron el incidente como un fracaso absoluto de sus expectativas de resiliencia, calificándolo de "inaceptable" y reconociendo explícitamente el dolor que causó tanto a los clientes como a los usuarios normales de Internet. El blog de Cloudflare

Lecciones para los equipos de infraestructura y SRE

Incluso si usted no está ejecutando algo tan grande como Cloudflare, hay algunas lecciones muy prácticas de diseño y operación en esta interrupción:

Trate la configuración interna como una entrada no fiable

Es fácil asumir que "nuestra propia" configuración generada es siempre correcta. Ayer se demostró por qué eso es peligroso:

• Valide siempre el tamaño, la forma y los límites de los archivos de configuración antes de aplicarlos.

• Considere la posibilidad de aplicar primero la configuración a un pequeño subconjunto de tráfico o nodos, con reversión automática en caso de anomalías.

• Mantenga límites superiores estrictos y disyuntores en torno al recuento de funciones, la preasignación de memoria y el uso de CPU.

Diseño para fallos parciales

Un fallo en el módulo de gestión de bots no debería ser capaz de provocar el pánico en toda la ruta del proxy:

• Por defecto, fail-open frente a fail-closed en algunas capas de seguridad cuando la alternativa es un apagón completo.

• Construir interruptores de seguridad claros y probados para las funciones no esenciales.

• Asegúrese de que los subsistemas críticos (autenticación, página de estado, herramientas de incidencias) pueden funcionar en modo degradado o a través de rutas alternativas.

Observe las señales correctas

La oscilación entre "good config" y "bad config" cada cinco minutos hacía que la señal pareciera tráfico de ataque o comportamiento externo ruidoso:

• Asegúrese de disponer de correlación por versión o por configuración en su canal de observabilidad.

• Construya paneles que hagan que los cambios de configuración sean visualmente obvios sobre los gráficos de error.

• Incluya pruebas sintéticas sólidas desde un punto de vista externo, para poder distinguir rápidamente los fallos internos de los problemas de red/ruta.

No ponga todos los huevos en la misma cesta de infraestructura

Para organizaciones que utilizan Cloudflare:

• Considere configuraciones multi-CDN para propiedades verdaderamente críticas.

• Evite que su página de estado dependa por completo del mismo proveedor que su pila principal (Cloudflare hace esto, pero ayer hubo un problema casual con el host de su página de estado que confundió aún más las cosas). El blog de Cloudflare+1

• Piénselo dos veces antes de vincular estrechamente la autenticación, los planos de control de la API y la entrega del frontend al mismo proveedor sin rutas alternativas.

Panorama general

Sólo en los últimos meses, hemos sido testigos de importantes interrupciones en Microsoft Azure, Amazon Web Services y ahora Cloudflare, que han dejado temporalmente fuera de servicio grandes cantidades de servicios para consumidores y empresas. AP News+2ElWashington Post+2

El patrón es claro:

• Internet depende cada vez más de un puñado de gigantes proveedores de infraestructuras.

• Las interrupciones suelen ser autoinfligidas, y se deben más a complejos cambios internos que a ataques externos.

• Incluso los proveedores con prácticas de SRE de primera clase pueden tropezar por interacciones inesperadas entre la configuración, el comportamiento de la base de datos y los límites codificados.

El incidente de Cloudflare de ayer es un duro recordatorio de que "la nube" no es mágica. En el fondo, sigue siendo software escrito por humanos, sujeto a los mismos tipos de errores que cualquier otra aplicación, sólo que con órdenes de magnitud de más personas dependiendo de ella.

Para los usuarios, el incidente se recordará sobre todo como "aquella mañana en que X y ChatGPT no cargaban".
Para los ingenieros, es probable que se estudie como un ejemplo de libro de texto de cómo sutiles errores de configuración en un sistema distribuido central pueden propagarse en un evento global de Internet.