Cloudflare sufrió ayer su peor caída desde 2019. Entre las 11:20 y...
Daniel Blanco 💻🤖@DanielBlancoSWE
6 views
Nov 19, 2025
~2 min read
Advertisement
1
Cloudflare sufrió ayer su peor caída desde 2019.
Entre las 11:20 y las 14:30 UTC gran parte del tráfico global dejó de pasar por su red, mostrando errores 5xx en miles de webs.
Me he leído su post mortem y te lo resumo en este hilo para que entiendas lo que ocurrió 🧵
Entre las 11:20 y las 14:30 UTC gran parte del tráfico global dejó de pasar por su red, mostrando errores 5xx en miles de webs.
Me he leído su post mortem y te lo resumo en este hilo para que entiendas lo que ocurrió 🧵
2
Todo empezó con un cambio de permisos en un cluster de ClickHouse.
El cambio hizo que una consulta generara datos duplicados y acabara produciendo un archivo para el sistema de Bot Management con el doble de tamaño de lo normal.
Dicho sistema es el que se encarga de analizar si una petición viene de un bot o de un usuario real.
El cambio hizo que una consulta generara datos duplicados y acabara produciendo un archivo para el sistema de Bot Management con el doble de tamaño de lo normal.
Dicho sistema es el que se encarga de analizar si una petición viene de un bot o de un usuario real.
3
El archivo se distribuye automáticamente a todos los servidores, porque el modelo de ML que detecta bots lo necesita como entrada.
Pero el software que lo carga tenía un límite de tamaño para el fichero.
Al recibir un archivo demasiado grande, falló. Y al fallar, el proxy central de Cloudflare dejó de procesar el tráfico que dependiese del sistema de bots, retornando errores HTTP 5xx
Pero el software que lo carga tenía un límite de tamaño para el fichero.
Al recibir un archivo demasiado grande, falló. Y al fallar, el proxy central de Cloudflare dejó de procesar el tráfico que dependiese del sistema de bots, retornando errores HTTP 5xx
4
Para empeorar las cosas, el archivo se regeneraba cada 5 minutos. A veces salía bien, y a veces mal, dependiendo de si la query se ejecutaba en la parte del cluster que se había actualizado.
Esto provocó que su sistema entrara en ciclos de caída y recuperación, lo que les hizo sospechar un DDoS masivo inicialmente.
Esto provocó que su sistema entrara en ciclos de caída y recuperación, lo que les hizo sospechar un DDoS masivo inicialmente.
5
A las 13:05 se aplicaron bypasses internos para volver a una versión anterior del core y reducir el impacto en los servicios de Workers KV y Access.
A las 14:24 por fin detuvieron la creación del archivo corrupto y cargaron manualmente una versión buena.
A las 14:30 la mayor parte del tráfico volvió a funcionar.
A las 14:24 por fin detuvieron la creación del archivo corrupto y cargaron manualmente una versión buena.
A las 14:30 la mayor parte del tráfico volvió a funcionar.
6
El problema afectó a:
- CDN y servicios de seguridad
- Turnstile
- Workers KV
- Dashboard
- Access
- Aumento de latencia en todo el CDN
- CDN y servicios de seguridad
- Turnstile
- Workers KV
- Dashboard
- Access
- Aumento de latencia en todo el CDN
7
A las 17:06 todos los servicios quedaron totalmente recuperados.
Resumiendo, la causa fue una consulta que devolvió el doble de columnas tras un cambio en permisos, generó un archivo demasiado grande, superó un límite interno y provocó que el módulo de bots fallase.
A partir de ahí, muchos servicios cayeron en cascada como resultado, afectando a una parte enorme del tráfico mundial.
Resumiendo, la causa fue una consulta que devolvió el doble de columnas tras un cambio en permisos, generó un archivo demasiado grande, superó un límite interno y provocó que el módulo de bots fallase.
A partir de ahí, muchos servicios cayeron en cascada como resultado, afectando a una parte enorme del tráfico mundial.
8
Cloudflare asumió las culpas y anunció ya los próximos pasos:
- Endurecer validaciones de archivos internos
- Añadir más "kill switches" para desactivar features
- Mejorar la gestión de errores y blindar rutas críticas del proxy.
Reconocen que una caída así es inaceptable en un servicio central de Internet.
- Endurecer validaciones de archivos internos
- Añadir más "kill switches" para desactivar features
- Mejorar la gestión de errores y blindar rutas críticas del proxy.
Reconocen que una caída así es inaceptable en un servicio central de Internet.
9
Personalmente, creo que a pesar de que la caída fue enorme, su actuación ha sido impecable.
Han arreglado el problema, admitido las culpas y ya están trabajando para que no se repita.
Y además sacan un post mortem súper detallado al día siguiente!
Si te interesa, puedes leerlo completo aquí 👉blog.cloudflare.com/18-november-20…
Han arreglado el problema, admitido las culpas y ya están trabajando para que no se repita.
Y además sacan un post mortem súper detallado al día siguiente!
Si te interesa, puedes leerlo completo aquí 👉blog.cloudflare.com/18-november-20…