Fallo de Cloudflare: deja al descubierto la falsa descentralización de la industria cripto

4 fallas graves en 18 meses: ¿por qué es tan difícil romper el dilema de la centralización?

Fuente: rekt news

Traducción: Saoirse, Foresight News

18 de noviembre de 2025, 6:20 a.m. hora del Este de EE. UU. Muchos de nosotros experimentamos una caída de la red.

No fue una interrupción gradual, ni hubo señales de advertencia. Un segundo antes estabas revisando el celular, operando, chateando con IA; al siguiente, todo lo que veías eran páginas de error 500.

Twitter se colgó en medio de un tuit, ChatGPT dejó de responder a mitad de conversación y Claude simplemente se congeló.

Incluso Downdetector —ese sitio al que acudís cuando todo lo demás falla para chequear el estado de los servicios— tampoco cargaba, sin poder decirte que “todo está caído”.

El 20% del tráfico global desapareció de la nada, todo porque Cloudflare, que debería proteger Internet de ataques, terminó “atacándose” a sí mismo.

Un cambio de configuración rutinario (actualización de permisos de base de datos) activó un bug oculto en su sistema de protección contra bots y, en un instante, el “portero” dejó a todos afuera.

En octubre, cuando Amazon Web Services (AWS) tumbó a Coinbase, los usuarios cripto en Twitter se burlaban de los males de la “centralización”.

¿Pero qué pasó cuando explotó la falla de Cloudflare en noviembre? Al menos durante las primeras horas, el ecosistema cripto quedó en silencio total.

Después de todo, cuando la infraestructura que sostiene Twitter está caída, ni siquiera podés discutir sobre la “fragilidad de la infraestructura” en Twitter.

Varios servicios clave se paralizaron (sistemas de transporte caídos), interfaces empresariales con errores, exploradores blockchain como Arbiscan y DeFiLlama mostrando error 500 uno tras otro —pero la blockchain en sí no mostró signos de interrupción de consenso.

Si la revolución “descentralizada” que defendés puede quedar fuera de servicio por el tamaño de un archivo de configuración de una empresa, ¿quién tiene realmente el control?

Línea de tiempo de la falla: del “cambio de configuración” al “apagón total”

11:05 UTC: se completa el despliegue del cambio de control de acceso a la base de datos.

23 minutos después, a las 11:28 UTC, el cambio llega al entorno de usuarios y aparecen los primeros errores en el tráfico HTTP.

En otras palabras: la falla ya había ocurrido, pero nadie sabía dónde estaba el problema.

Para las 11:48 UTC, la página oficial de estado de Cloudflare finalmente admite “fallas en servicios internos”—lo que en lenguaje corporativo significa: “todo está descontrolado y todos lo notan”.

La reacción en cadena fue instantánea: el cambio rompió la capa de gestión de bots de Cloudflare y, al cargar un archivo de funciones que duplicó su tamaño, el servicio de proxy colapsó.

Los sistemas aguas abajo también cayeron: Workers KV (almacenamiento clave-valor) y Access (control de acceso) no podían conectar con el proxy; la tasa de errores explotó y el uso de CPU se disparó junto con la carga de las herramientas de monitoreo.

El tráfico seguía llegando a los nodos perimetrales de Cloudflare, pero el proxy ya no respondía.

Al principio, Cloudflare pensó que estaba bajo ataque, y no cualquier ataque: un DDoS masivo.

Más extraño aún: hasta la página oficial de estado, alojada fuera de la infraestructura de Cloudflare, también cayó, lo que llevó a los ingenieros a sospechar de un ataque coordinado a sus sistemas centrales y de monitoreo.

Pero no era así. No hubo ataque externo; el problema era interno.

Poco después de restaurar el servicio, el CTO de Cloudflare, Dane Knecht, publicó una disculpa pública, calificando el incidente como “totalmente inaceptable” y atribuyendo la causa a un cambio rutinario de configuración—ese cambio fue el que disparó el colapso de la capa de protección contra bots.

“Defraudamos a nuestros clientes y a los usuarios de Internet en general”, escribió Knecht, “un bug latente en el servicio que soporta nuestra protección contra bots colapsó tras un cambio rutinario de configuración, provocando una falla masiva en nuestra red y otros servicios. No fue un ataque externo.”

En el pico de la falla, Downdetector recibió 11.183 reportes.

El “apagón digital” duró más de cinco horas y media; recién a las 17:06 UTC el servicio se restauró por completo, aunque a las 14:30, tras desplegar la configuración correcta de gestión de bots a nivel global, el impacto más grave ya se había mitigado.

Impacto de la falla: de Web2 al cripto, nadie se salvó

Web2, el primer afectado

La plataforma X recibió 9.706 reportes de fallas.

En vez de la timeline habitual, los usuarios veían el mensaje de error “Uy, algo salió mal”.

ChatGPT se quedó “mudo” a mitad de conversación, sin responder a ninguna orden.

Spotify interrumpió su servicio de streaming, Canva dejó afuera a los diseñadores, Uber y Door Dash también presentaron fallas.

Ni los gamers se salvaron: jugadores de League of Legends fueron desconectados a mitad de partida.

Incluso se reportó que las máquinas de autoservicio de McDonald’s mostraron errores—justo en la hora pico del almuerzo y con la infraestructura caída.

El sector cripto tampoco se salvó.

Parálisis masiva en plataformas cripto

El frontend de Coinbase colapsó por completo; los usuarios solo veían la página de login sin cargar.

La web y la app de Kraken también “murieron”, consecuencia directa de la caída global de Cloudflare.

BitMEX publicó en su página de estado: “Investigando la causa de la falla, el rendimiento de la plataforma está degradado, pero los fondos de los usuarios están seguros”. Mismo guion, distinto exchange.

Etherscan no cargaba, Arbiscan directamente caído.

El panel de análisis de DeFiLlama mostraba errores internos de servidor de forma intermitente.

Incluso Ledger anunció que, debido a la falla de Cloudflare, la disponibilidad de algunos servicios se vio reducida.

La única “excepción”: los protocolos blockchain en sí

Pero los siguientes sistemas no se vieron afectados:

Según reportes, Binance, OKX, Bybit, Crypto.com, KuCoin y otros exchanges principales no sufrieron fallas en el frontend, las transacciones on-chain siguieron normales—mientras tanto, la blockchain funcionó perfectamente, sin señales de interrupción de consenso.

Los protocolos blockchain siguieron operando de forma independiente—el problema no estaba en la cadena, sino en la infraestructura Web2 que usamos para acceder a ella.

Si la blockchain sigue funcionando pero nadie puede acceder, ¿el cripto realmente sigue “online”?

Análisis profundo: ¿cómo una consulta a la base de datos tumbó el 20% de la red?

Cloudflare no aloja sitios web ni ofrece servicios de servidores en la nube como AWS.

Su rol es el de “intermediario”: se ubica entre el usuario y la web, da servicio a 24 millones de sitios, y procesa el 20% del tráfico global a través de nodos en 120 países y 330 ciudades.

El discurso de Cloudflare es: se posiciona como “escudo y acelerador de Internet”, ofreciendo protección DDoS 24/7, protección contra bots, enrutamiento de tráfico, firewall global (WAF), terminación TLS, edge computing basado en Workers y DNS—todo en una red unificada de “seguridad-rendimiento”.

En la práctica: domina el 82% del mercado de protección DDoS, tiene un ancho de banda de 449 Tbps y está interconectado con los principales ISP y proveedores de nube del mundo.

El problema central: cuando el intermediario falla, todos los servicios detrás se vuelven “inalcanzables”.

El CTO Dane Knecht lo dijo sin rodeos en X:

“Lo digo claro: hoy temprano, por un problema en la red de Cloudflare, mucho tráfico que depende de nosotros se vio afectado. Defraudamos a nuestros clientes y a los usuarios de Internet en general.”

El CEO Matthew Prince fue aún más directo:

“Hoy fue la peor falla de Cloudflare desde 2019... En más de 6 años, nunca habíamos tenido una caída que impidiera que la mayor parte del tráfico central pasara por nuestra red.”

La raíz técnica de la falla

Todo empezó con una actualización rutinaria de permisos en la base de datos. A las 11:05 UTC, Cloudflare modificó su clúster de base de datos ClickHouse para mejorar seguridad y confiabilidad—permitiendo que usuarios con “acceso implícito” pudieran ver metadatos de tablas de forma “explícita”.

¿Dónde estuvo el error? La consulta que generaba el archivo de configuración del servicio anti-bots no filtraba por “nombre de base de datos”.

La consulta de gestión de tráfico malicioso empezó a devolver entradas duplicadas—una del default DB y otra del almacenamiento r0. Así, el archivo de funciones duplicó su tamaño: de unos 60 features a más de 200.

Cloudflare había puesto un límite hardcodeado de 200 features para la preasignación de memoria, pensando “esto es mucho más de los 60 que usamos ahora”. Típica mentalidad ingenieril: poner un margen “suficiente” hasta que ocurre lo inesperado.

El archivo sobredimensionado disparó el límite, el código en Rust colapsó y arrojó el error: “thread fl2_worker_thread panicked: called Result::unwrap() on an Err value”.

El sistema anti-bots es clave en el control de Cloudflare. Si colapsa, el sistema de health checks que informa al balanceador de carga qué servidores están sanos también “falla”.

Peor aún: ese archivo de configuración se regenera cada 5 minutos.

Solo cuando la consulta se ejecutaba en los nodos ya actualizados del clúster, se generaban datos erróneos. Así, cada 5 minutos, la red de Cloudflare alternaba entre “normal” y “fallida”: a veces cargaba el archivo correcto, a veces el erróneo.

Ese “vaivén” llevó a los ingenieros a pensar que era un ataque DDoS—los errores internos rara vez causan ciclos de “recuperación y caída”.

Finalmente, cuando todos los nodos ClickHouse se actualizaron, cada archivo generado era erróneo. El “vaivén” terminó, y llegó la “falla total y estable”.

Sin señales precisas del sistema, este entró en “modo conservador” y marcó la mayoría de los servidores como “no saludables”. El tráfico seguía llegando, pero no podía ser enrutado correctamente.

Los nodos perimetrales de Cloudflare recibían las solicitudes de los usuarios, pero no podían procesarlas.

“No fue un ataque externo”, insistió Knecht, “no hubo acciones maliciosas ni DDoS. Solo una consulta a la base de datos sin filtro, justo tras una actualización de permisos, y eso disparó la falla.”

Cloudflare prometía “99,99% de disponibilidad”, pero esta vez, no cumplió.

Así fue.

La historia se repite: 4 fallas graves en 18 meses, ¿por qué no se resuelve la centralización?

20 de octubre de 2025—Falla de AWS por 15 horas. El DNS de DynamoDB en la región este de EE. UU. falló, congelando Coinbase, trabando Robinhood, interrumpiendo Infura (afectando MetaMask), y dejando fuera de línea a Base, Polygon, Optimism, Arbitrum, Linea, Scroll y otras redes blockchain. Aunque los fondos on-chain estaban seguros, muchos usuarios veían su saldo en “cero”.

29 de octubre de 2025—Falla de Microsoft Azure. Problemas de sincronización en Azure Front Door dejaron fuera de línea Microsoft 365, Xbox Live y servicios empresariales.

Julio de 2024—Un update defectuoso de CrowdStrike (empresa de seguridad) en Windows. La falla paralizó vuelos, retrasó procesos médicos y congeló servicios financieros; la recuperación total llevó días.

Junio de 2022—La anterior gran falla de Cloudflare. Varios exchanges cripto suspendieron servicios—mismo patrón, otro año.

Julio de 2019—Otra falla previa de Cloudflare. Coinbase fuera de línea, CoinMarketCap inaccesible—la primera “señal de alerta” ignorada por todos.

En solo 18 meses, ocurrieron 4 grandes fallas de infraestructura.

Cuatro fallas, una misma lección: la infraestructura centralizada lleva a “fallas centralizadas”.

Cuatro fallas que podrían haber acelerado la transición del sector cripto hacia la descentralización—pero sigue dependiendo de la infraestructura de tres empresas.

¿Cuántas advertencias más necesita la industria para pasar de “suponer que puede fallar” a “construir como si fuera inevitable que falle”?

La “mentira” de la descentralización: descentralizar el protocolo no es descentralizar el acceso

Te vendieron este sueño:

“Finanzas descentralizadas, dinero resistente a la censura, sistemas sin confianza, sin puntos únicos de falla, ‘si no son tus llaves, no son tus monedas’, el código es ley.”

Pero el 18 de noviembre, la realidad golpeó: una mañana de falla en Cloudflare bastó para paralizar servicios cripto durante horas.

La verdad técnica:

Ningún protocolo blockchain reportó fallas. La red de bitcoin funcionó normal, la de ethereum también—la cadena en sí no tuvo problemas.

La realidad en el uso:

Interfaces de exchanges caídas, exploradores blockchain fuera de servicio, wallets sin funcionar, plataformas de análisis caídas, pantallas de error 500 en los exchanges.

Los usuarios no podían acceder a la blockchain “descentralizada” que supuestamente “poseían”. El protocolo funcionaba—siempre y cuando pudieras “llegar” a él.

Estas frases pueden incomodar a muchos…

David Schwed, COO de SovereignAI, fue tajante:

“Ahora falla Cloudflare, hace semanas fue AWS, y esto demuestra que no podemos delegar la ‘resiliencia’ de la infraestructura en un solo proveedor. Si tu organización necesita operar 24/7, tenés que construir la infraestructura asumiendo que va a fallar. Si tu plan de continuidad es solo ‘esperar a que el proveedor lo arregle’, eso es pura negligencia.”

“Pura negligencia”—no accidente, no descuido, negligencia.

Jameson Lopp lo resumió así:

“Tenemos una gran tecnología descentralizada, pero la volvimos frágil al concentrar la mayoría de los servicios en unos pocos proveedores.”

Ben Schiller, durante la última caída de AWS, dijo algo que hoy sigue vigente:

“Si tu blockchain se cae por una falla de AWS, no es lo suficientemente descentralizada.”

Cambiá “AWS” por “Cloudflare” y el problema es el mismo—la industria nunca aprendió la lección.

¿Por qué se elige la “conveniencia” antes que el “principio”?

Montar infraestructura propia implica: comprar hardware caro, asegurar energía estable, mantener ancho de banda dedicado, contratar expertos en seguridad, redundancia geográfica, sistemas de backup, monitoreo 24/7—todo requiere inversión.

Con Cloudflare, solo hacés clic, ponés la tarjeta y en minutos está todo desplegado.

La protección DDoS la da otro, la disponibilidad la garantiza otro, el escalado lo resuelve otro.

Las startups buscan “salir rápido”, los VC exigen “eficiencia de capital”—todos eligen la “conveniencia”, no la resiliencia.

Hasta que la “conveniencia” deja de ser conveniente.

La caída de AWS en octubre desató debates eternos sobre “descentralización” en Twitter.

¿Y la de Cloudflare en noviembre? Silencio total.

No por “reflexión filosófica”, ni por “profunda meditación”.

Sino porque, cuando quisieron quejarse, la plataforma que usan para quejarse (Twitter) también estaba caída.

Cuando el “punto único de falla” es la plataforma que usás para burlarte de los “puntos únicos de falla”, no hay de qué reírse.

Si el acceso depende de tres empresas, y dos fallan en el mismo mes, la “descentralización a nivel de protocolo” no significa nada.

Si los usuarios no pueden llegar a la blockchain, ¿qué estamos “descentralizando” realmente?

El dilema del monopolio: tres empresas controlan el 60% del mercado cloud, ¿qué futuro le espera al cripto?

AWS controla cerca del 30% del mercado global de infraestructura cloud, Microsoft Azure el 20%, Google Cloud el 13%.

Tres empresas controlan más del 60% de la infraestructura que sostiene Internet.

La industria cripto, que debería ser la solución a la “centralización”, depende de la infraestructura más centralizada del mundo.

Lista de “dependencias centralizadas” del sector cripto

• Coinbase — depende de AWS;
• Binance, BitMEX, Huobi, Crypto.com — todos dependen de AWS;
• Kraken construyó su infraestructura sobre AWS, pero igual sufrió la caída de la CDN de Cloudflare.

Muchos exchanges “descentralizados” en realidad corren sobre infraestructura centralizada.

Las caídas de octubre y noviembre tienen una diferencia clave:

Cuando cayó AWS, la plataforma X (ex Twitter) seguía online, y los usuarios cripto podían burlarse de la “fragilidad de la infraestructura”.

Pero cuando cayó Cloudflare, X también se cayó.

Cuando la plataforma que usás para “reírte del punto único de falla” es parte del mismo punto de falla, ya no hay gracia.

Esa ironía hizo que el debate de la industria ni siquiera arrancara.

Tres grandes caídas en 30 días, y los reguladores ya están muy atentos.

Preguntas clave para los reguladores

• ¿Estas empresas son “instituciones de importancia sistémica”?
• ¿Los servicios backbone de Internet deberían ser regulados como servicios públicos?
• ¿Qué riesgos surgen cuando el “demasiado grande para caer” se combina con infraestructura tecnológica?
• Si Cloudflare controla el 20% del tráfico global, ¿es esto un problema de monopolio?

Corinne Cath-Speth, de la organización Article 19, fue clara tras la última caída de AWS: “Cuando un proveedor se cae, los servicios críticos también: los medios no pueden acceder, apps seguras como Signal dejan de funcionar, y la infraestructura que sostiene la sociedad digital se desmorona. Necesitamos urgentemente diversificar la nube”.

En otras palabras: los gobiernos empiezan a notar que unas pocas empresas pueden detener Internet.

En realidad, las alternativas descentralizadas existen hace tiempo, pero nadie las adopta.

Por ejemplo, Arweave para almacenamiento, IPFS para transferencia de archivos distribuida, Akash para cómputo, Filecoin para hosting descentralizado.

¿Por qué las soluciones descentralizadas no despegan?

El rendimiento es inferior al de las opciones centralizadas; la latencia es evidente para el usuario.

La adopción es bajísima y, comparado con el simple “deploy en AWS”, el proceso es mucho más complejo.

El costo suele ser mayor que alquilar infraestructura a los “tres grandes” (AWS, Azure, Google Cloud).

La realidad es:

Construir infraestructura realmente descentralizada es mucho más difícil de lo que parece.

La mayoría de los proyectos solo hablan de “descentralización”, pero rara vez la implementan. Elegir lo centralizado siempre es más simple y barato—hasta que, tras 4 caídas en 18 meses, se ve el costo oculto de esa “simplicidad”.

Max Li, CEO de OORT, lo denunció en una columna de CoinDesk:

“Para una industria que se enorgullece de la ‘descentralización’ y predica sus ventajas, depender tanto de plataformas cloud centralizadas y frágiles es pura hipocresía.”

Su propuesta: usar estrategias de nube híbrida y que los exchanges distribuyan sistemas críticos en redes descentralizadas.

Las plataformas cloud centralizadas tienen ventajas de rendimiento y escala irremplazables—pero cuando hay miles de millones en juego y cada segundo cuenta, su resiliencia es menor que la de una solución distribuida.

Solo cuando el costo de la “conveniencia” sea tan alto que cambie el comportamiento de la industria, el “principio” vencerá a la “conveniencia”.

Claramente, la caída del 18 de noviembre no fue lo suficientemente grave, ni la de AWS el 20 de octubre, ni la de CrowdStrike en julio de 2024.

¿Cuánto más tiene que pasar para que la “infraestructura descentralizada” deje de ser un tema de charla y pase a ser un requisito obligatorio?

El 18 de noviembre, la industria cripto no “fracasó”—la blockchain funcionó perfecto.

El verdadero “fracaso” fue la mentira colectiva: creer que se pueden construir “aplicaciones imparables” sobre infraestructura que sí puede caer; creer que la “resistencia a la censura” tiene sentido cuando tres empresas controlan el acceso; creer que, si un archivo de configuración de Cloudflare decide si millones pueden operar, eso sigue siendo “descentralización”.

Si la blockchain sigue generando bloques pero nadie puede enviar transacciones, ¿realmente está “online”?

La industria no tiene ningún plan de contingencia.

Si hay una falla, solo queda esperar a que Cloudflare lo arregle, que AWS vuelva, que Azure saque un parche.

Esa es la “estrategia de recuperación ante desastres” actual.

Imaginá: ¿qué pasa si la identidad digital se integra profundamente con la blockchain?

El Tesoro de EE. UU. impulsa que las credenciales de identidad se integren en smart contracts, exigiendo KYC en cada interacción DeFi.

La próxima vez que falle la infraestructura, los usuarios no solo perderán acceso a operar—también perderán la capacidad de “probar su identidad” en el sistema financiero.

Una falla de 3 horas se convertirá en 3 horas sin poder cargar la pantalla de verificación humana—porque el servicio de verificación corre sobre infraestructura caída.

Los “guardarraíles” regulatorios solo sirven si la infraestructura está siempre online. El 18 de noviembre demostró que esa premisa es falsa.

Cuando el problema del “exceso de vigilancia” se vuelve obvio, los tecnólogos buscan “privacidad”.

Quizás ahora sea momento de incluir la “resiliencia de la infraestructura” en esa categoría.

No debería ser un “plus opcional”, sino un “requisito fundamental”—sin eso, nada más importa.

La próxima falla ya se está gestando—puede venir de AWS, Azure, Google Cloud o una nueva caída de Cloudflare.

Puede ser el mes que viene, o la semana que viene. La infraestructura no cambió, la dependencia tampoco, ni los incentivos de la industria.

Elegir lo centralizado sigue siendo más barato, rápido y fácil—hasta que deja de serlo.

Cuando el próximo cambio rutinario de Cloudflare active otro bug oculto en un servicio clave, veremos la misma “película”: pantallas de error 500, trading paralizado, blockchains funcionando pero inaccesibles, queriendo tuitear sobre “descentralización” pero Twitter caído, promesas empresariales de “mejorar la próxima vez” que nunca se cumplen.

Nada va a cambiar, porque la “conveniencia” siempre vence a la “prevención”—hasta que el costo de la conveniencia sea imposible de ignorar.

Esta vez, el “portero” estuvo caído 3 horas y media.

La próxima, la caída puede durar más; la próxima, puede ocurrir en medio de un crash donde cada segundo cuenta; la próxima, los sistemas de verificación de identidad pueden caer también.

Cuando la infraestructura de la que dependés colapsa justo cuando menos podés permitirlo, ¿de quién es la culpa?

Fuentes: The Guardian, Johnny Popov, PC Magazine, IT Professional, CNBC, Cloudflare, TechCrunch, Associated Press, CoinDesk, Tom’s Hardware, Dane Knecht, Tom’s Guide, Surya, Sheep Esports, TheBlock, Kraken, BitMEX, Ledger, Blockchain News, Statista, Sohu Computer, Jameson Lopp, Ben Schiller, Article 19, CoinTelegraph