El gran apagón de Cloudflare que dejó medio internet lleno de errores: qué pasó realmente

El 18 de noviembre de 2025, millones de usuarios en todo el mundo se encontraron con la misma imagen al intentar entrar en muchas webs: una página de error de Cloudflare. Durante varias horas, sitios de todo tipo —medios de comunicación, tiendas online, servicios digitales y páginas corporativas— dejaron de funcionar o tardaban una eternidad en cargar.

Lo primero que muchos pensaron fue lo de siempre: “¿habrán hackeado algo?”. Pero la propia Cloudflare ha explicado después que no se trató de un ciberataque, sino de un fallo interno en su sistema, provocado por un cambio de configuración que salió mal y terminó bloqueando el corazón de su red.


¿Qué es Cloudflare y por qué su caída afecta a tanta gente?

Cloudflare es una especie de “central eléctrica” de internet. Muchas webs no se conectan directamente con el usuario, sino que pasan primero por los servidores de Cloudflare, que se encargan de:

  • acelerar la carga de las páginas,
  • protegerlas frente a ataques,
  • y filtrar tráfico malicioso (por ejemplo, bots y ataques DDoS).

Eso significa que, cuando Cloudflare falla, no cae solo una web concreta, sino todas las que dependen de sus servicios. Por eso el impacto fue tan visible: de repente, una parte importante de internet empezó a devolver errores de tipo 5xx, que indican problemas internos en el servidor.


No fue un ataque: el problema estaba en casa

Según ha explicado la empresa, todo empezó a las 11:20 (hora UTC). La red de Cloudflare comenzó a tener problemas para procesar las peticiones y a mostrar páginas de error.

internal error server cloudflare

La causa fue una combinación de dos cosas:

  1. Un cambio en la manera de gestionar permisos en una de sus bases de datos.
  2. Un archivo de configuración que se generó mal y se hizo el doble de grande de lo normal.

Ese archivo, que se actualiza cada pocos minutos, sirve para que el sistema de Cloudflare distinga entre tráfico normal y tráfico de bots (robots automáticos). Es como una lista de “pistas” que usa la inteligencia artificial de la empresa para decidir si una visita es legítima o no.

Con el cambio en la base de datos, esa lista empezó a llenarse de datos duplicados y a crecer más de lo previsto. Cuando ese archivo “hinchado” se envió a todos los servidores de la red, el sistema que lo leía no fue capaz de manejarlo y se bloqueó, provocando el famoso fallo generalizado.


Un fallo raro que iba y venía

Para complicar las cosas, al principio el error no fue estable: iba y venía.

El archivo problemático se genera cada cinco minutos. Como no todos los servidores internos de la base de datos estaban actualizados a la vez, a veces se creaba una versión correcta y otras una versión defectuosa.

Esto hizo que la red de Cloudflare:

  • por momentos funcionara con normalidad,
  • y al poco volviera a fallar de forma masiva.

Desde fuera, y también para parte del equipo interno, este comportamiento parecía el de un ataque por oleadas, lo que llevó a sospechar inicialmente de un DDoS (un bombardeo coordinado de tráfico para tirar un servicio).

Solo cuando analizaron con detalle los cambios recientes se dieron cuenta de que el problema se encontraba en ese archivo de configuración y en cómo se había generado tras la modificación en la base de datos.


¿Cuánto duró el apagón y qué servicios se vieron afectados?

Según la cronología que ha hecho pública la propia empresa:

  • A las 11:05 UTC se aplicó el cambio en la base de datos que, sin saberlo, iba a provocar el problema.
  • Entre las 11:20 y las 11:30 empezaron los primeros errores visibles para los usuarios.
  • A partir de ahí, las caídas se hicieron masivas, con subidas y bajadas de errores a medida que se propagaban archivos “buenos” y “malos”.
  • En torno a las 14:30, Cloudflare consiguió detener la propagación del archivo defectuoso y sustituirlo por una versión anterior que sí funcionaba.
  • A las 17:06, todos los servicios se daban por recuperados.

Durante ese periodo, se vieron afectados:

  • Las webs protegidas por Cloudflare, que mostraban errores 5xx o no cargaban correctamente.
  • Workers KV, un sistema interno de almacenamiento que usan muchas aplicaciones que corren sobre la plataforma de Cloudflare.
  • Cloudflare Access y Turnstile, relacionados con la autenticación y la protección de formularios, lo que dificultó incluso que algunos administradores pudieran entrar en el panel de control.
  • El propio panel de Cloudflare, que sufrió problemas de acceso y lentitud en algunos momentos clave del incidente.

La buena noticia es que, según la empresa, no se perdieron datos de clientes ni hubo intrusiones, pero la interrupción del servicio fue muy visible y afectó tanto a pequeños proyectos como a grandes compañías.


¿Por qué un simple archivo pudo tirar abajo medio internet?

La pregunta que muchos se han hecho es: “¿cómo es posible que un archivo de configuración demasiado grande cause semejante desastre?”.

cloudflare architecture

La respuesta está en cómo trabajan hoy las grandes plataformas de internet:

  • Todo está muy automatizado: los cambios se generan y se distribuyen de forma constante por miles de servidores.
  • Esa automatización es necesaria para reaccionar rápido ante ataques y cambios en el tráfico.
  • Pero si no se ponen suficientes “límites de seguridad” alrededor de esos procesos, un pequeño fallo lógico se puede propagar a toda la red en cuestión de minutos.

En este caso, el sistema asumía que ese archivo tendría siempre un tamaño razonable. Cuando dejó de serlo, el programa que lo leía no supo cómo reaccionar de forma elegante (por ejemplo, ignorando el exceso o cargando una versión mínima) y se limitó a “morirse” devolviendo errores.


Lo que Cloudflare promete cambiar a partir de ahora

Tras el incidente, la compañía ha reconocido que este apagón es “inaceptable” y ha anunciado varias medidas para intentar que no vuelva a repetirse algo parecido. Entre ellas:

  • Tratar sus propios archivos internos como si vinieran de fuera, es decir, validarlos y poner límites estrictos antes de distribuirlos globalmente.
  • Introducir más “interruptores de emergencia”, para poder apagar módulos concretos (como el de detección de bots) sin tener que parar todo el sistema.
  • Revisar los modos de fallo de las piezas clave de su red, para que ante un problema entren en un modo degradado —funcionando con menos funciones— en lugar de dejar de responder por completo.
  • Evitar que sus sistemas de monitorización y registro consuman demasiados recursos cuando hay muchos errores, para que las herramientas de diagnóstico no empeoren la situación.

Lo que este fallo dice sobre el internet actual

Aunque para muchos usuarios el apagón de Cloudflare fue “un día en el que muchas webs no funcionaban”, el incidente deja una reflexión de fondo:

  • Cada vez más servicios de los que se usan a diario dependen de unas pocas grandes infraestructuras globales.
  • Cuando una de ellas falla, el impacto se siente en todo el mundo, incluso en web y negocios que nunca han oído hablar de Cloudflare.
  • La resiliencia de internet ya no depende solo de que “tu servidor vaya bien”, sino de la salud de estos grandes intermediarios.

Cloudflare, al menos, ha optado por explicar con bastante detalle qué ocurrió y asumir su responsabilidad. Pero el episodio recuerda que, incluso sin hackers de por medio, un error de software mal controlado puede tener efectos tan visibles como un gran ataque. Y que la mejor defensa, también en este terreno, pasa por diseñar sistemas que fallen con elegancia… y no apagando medio internet de golpe.


Fuentes:

Scroll al inicio