Fallo de Cloudflare: desvela la falsa descentralización de la industria cripto

4 grandes fallos en 18 meses: ¿por qué es tan difícil resolver 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 interrupción de la red.

No fue una interrupción gradual, ni hubo señales de advertencia. Un segundo antes estabas usando tu móvil, haciendo trading o chateando con una IA; al siguiente, todo lo que veías eran páginas de error 500.

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

Incluso Downdetector —el sitio al que recurres para comprobar fallos cuando todo lo demás falla— tampoco cargaba, incapaz de decirte que “todos los servicios están caídos”.

El 20% de la red global desapareció de la nada, todo porque Cloudflare, que se supone protege Internet de ataques, accidentalmente “se atacó a sí misma”.

Un cambio rutinario de configuración (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 fuera.

En octubre, cuando Amazon Web Services (AWS) provocó la caída de Coinbase, los usuarios de Twitter en el mundo cripto se burlaban abiertamente de los males de la “centralización”.

¿Pero qué pasó cuando estalló el fallo de Cloudflare en noviembre? Al menos durante las primeras horas, todo el sector cripto guardó silencio.

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

Varios servicios críticos quedaron paralizados (sistemas de transporte caídos), algunas interfaces empresariales fallaron, y exploradores blockchain como Arbiscan y DeFiLlama mostraban errores 500 —pero la blockchain en sí no mostró signos de interrupción de consenso.

Cuando la revolución “descentralizada” que promueves puede ser detenida por el tamaño de un archivo de configuración de una empresa, ¿quién tiene realmente el control?

Línea temporal del fallo: de un “cambio de configuración” al “colapso total de la red”

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 se propaga al entorno de usuario y aparecen los primeros errores en el tráfico HTTP de los usuarios.

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

Hasta las 11:48 UTC, la página oficial de estado de Cloudflare finalmente reconoció un “fallo en los servicios internos”, lo que en lenguaje corporativo significa: “todo está fuera de control y todos lo pueden ver”.

El efecto dominó fue inmediato: el cambio rompió la capa de gestión de bots de Cloudflare y, al cargar un archivo de funciones duplicado en tamaño, el servicio 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 global se disparó y, con el aumento de carga en las herramientas de monitorización, el uso de CPU alcanzó máximos.

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

Al principio, Cloudflare pensó que estaba bajo ataque, y que era un ataque DDoS masivo.

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

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

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

“Decepcionamos a nuestros clientes y a los usuarios de Internet en general”, escribió Knecht, “un bug latente en uno de los servicios que soportan nuestra protección contra bots colapsó tras un cambio rutinario de configuración, provocando una gran interrupción en nuestra red y otros servicios. No fue un ataque externo”.

En el pico del fallo, Downdetector recibió hasta 11.183 reportes.

Este “apagón digital” duró más de 5 horas y media; hasta las 17:06 UTC se restableció el servicio 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 del fallo: de Web2 al sector cripto, nadie se salva

Plataformas Web2, las primeras afectadas

La plataforma X recibió 9.706 reportes de fallo.

Los usuarios no veían su timeline habitual, sino el mensaje de error “Vaya, algo salió mal”.

ChatGPT se “quedó mudo” a mitad de conversación y dejó de responder a cualquier instrucción.

Spotify interrumpió su servicio de streaming, Canva bloqueó a los diseñadores, Uber y Door Dash también experimentaron fallos.

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

Incluso se reportó que las máquinas de autoservicio de McDonald’s mostraban errores —justo en la hora punta del almuerzo y con la infraestructura fallando.

El sector cripto tampoco se libró.

Parálisis masiva en plataformas cripto

El frontend de Coinbase colapsó por completo; los usuarios solo veían una página de inicio de sesión que no cargaba.

La web y la app móvil de Kraken también “cayeron” —consecuencia directa del fallo global de Cloudflare.

BitMEX publicó en su página de estado: “Investigando la causa del fallo, el rendimiento de la plataforma ha disminuido, pero los fondos de los usuarios están seguros”. El mismo guion, solo cambia el 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 al fallo de Cloudflare, la disponibilidad de algunos servicios se había visto reducida.

La única “excepción”: los propios protocolos blockchain

Pero los siguientes sistemas no se vieron afectados:

Según los informes, Binance, OKX, Bybit, Crypto.com, KuCoin y otros exchanges principales no sufrieron fallos en el frontend y las transacciones on-chain continuaron con normalidad —mientras tanto, la blockchain seguía funcionando 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 la gente usa para acceder a ella.

Si la blockchain sigue funcionando pero nadie puede acceder a ella, ¿realmente las criptomonedas siguen “en línea”?

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

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

Su papel es el de “intermediario” —entre el usuario e Internet, da servicio a 24 millones de sitios web y, a través de nodos en 120 países y 330 ciudades, gestiona el 20% del tráfico global.

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

En la práctica: domina el 82% del mercado de protección DDoS, su ancho de banda total en nodos perimetrales alcanza los 449 Tbps y está conectado a la mayoría de los principales ISP y proveedores de nube del mundo.

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

El CTO de Cloudflare, Dane Knecht, fue claro en la plataforma X:

“Lo diré sin rodeos: hoy, debido a un problema en la red de Cloudflare, gran parte del tráfico que depende de nosotros se vio afectado. Decepcionamos a nuestros clientes y a los usuarios de Internet en general.”

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

“Hoy ha sido el peor fallo de Cloudflare desde 2019... En más de 6 años, nunca habíamos tenido una interrupción que impidiera que la mayoría del tráfico central pasara por nuestra red.”

Raíz técnica del fallo

Todo comenzó con una actualización rutinaria de permisos en la base de datos. A las 11:05 UTC, Cloudflare realizó un cambio en su clúster de bases de datos ClickHouse para mejorar la seguridad y fiabilidad —permitiendo que los usuarios con permisos “implícitos” pudieran ver metadatos de tablas de forma “explícita”.

¿Dónde estuvo el problema? La consulta que generaba el archivo de configuración del servicio de protección contra bots de Cloudflare no filtraba por “nombre de base de datos”.

La consulta que gestionaba el tráfico sospechoso empezó a devolver entradas duplicadas —una del database por defecto y otra de la base de datos de almacenamiento r0. Esto duplicó el tamaño del archivo de funciones, de unos 60 atributos a más de 200.

Cloudflare había fijado un límite codificado de 200 atributos para la preasignación de memoria, pensando que “era mucho más de los 60 atributos que usamos actualmente”. Es el típico pensamiento ingenieril: pones un margen de seguridad “suficiente” hasta que ocurre lo inesperado.

El archivo sobredimensionado activó ese límite, el código Rust colapsó y arrojó el error: “thread fl2_worker_thread panicked: called Result::unwrap () on an Err value” (el hilo fl2_worker_thread colapsó: se llamó a Result::unwrap () sobre un valor Err).

El sistema de protección contra bots es un componente central del control de Cloudflare. Cuando colapsa, el sistema de chequeo de salud que indica al balanceador de carga “qué servidores están operativos” también falla.

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

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

Esta “oscilación” llevó a los ingenieros a pensar que era un ataque DDoS —los errores internos raramente provocan ciclos de “recuperación y colapso”.

Finalmente, cuando todos los nodos ClickHouse se actualizaron, cada archivo generado era erróneo. La “oscilación” cesó, dando paso a un “fallo total y estable”.

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

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

“No fue un ataque externo”, recalcó Knecht, “no hubo comportamiento malicioso ni ataque DDoS. Solo una consulta a la base de datos sin filtro, que coincidió con una actualización de permisos y desencadenó el fallo”.

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

Así fue, en efecto.

La historia se repite: 4 grandes fallos en 18 meses, ¿por qué es irresoluble el dilema de la centralización?

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

29 de octubre de 2025 —Fallo de Microsoft Azure. Un problema de sincronización de configuración en Azure Front Door dejó fuera de línea Microsoft 365, colapsó Xbox Live e interrumpió servicios empresariales.

Julio de 2024 —Un bug en el paquete de actualización de Windows de CrowdStrike (empresa de seguridad). El fallo paralizó vuelos, retrasó procesos médicos y congeló servicios financieros; la recuperación total llevó días.

Junio de 2022 —El anterior gran fallo de Cloudflare. Varios exchanges cripto suspendieron servicios —el mismo patrón, solo otro año.

Julio de 2019 —Un fallo anterior de Cloudflare. Coinbase cayó, CoinMarketCap inaccesible —la primera “señal de advertencia” ignorada por todos.

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

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

Cuatro fallos 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 hacen falta para que el sector pase de “suponer que los fallos pueden ocurrir” a “diseñar sistemas asumiendo que los fallos ocurrirán”?

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

Te pintaron este panorama:

“Finanzas descentralizadas, monedas resistentes a la censura, sistemas sin confianza, sin puntos únicos de fallo, ‘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 fallo en Cloudflare bastó para paralizar parte de los servicios del sector cripto durante horas.

La verdad técnica:

No se reportó fallo en ningún protocolo blockchain. La red de bitcoin funcionó con normalidad, la de ethereum también —la cadena en sí no tuvo problemas.

La realidad en el uso:

Interfaces de exchanges caídas, exploradores blockchain paralizados, interfaces de wallets inservibles, plataformas de análisis de datos caídas, errores 500 en las interfaces de trading.

Los usuarios no podían acceder a la blockchain “descentralizada” que supuestamente “poseían”. El protocolo funcionaba —siempre que pudieras “alcanzarlo”.

Estas afirmaciones pueden resultar incómodas para muchos…

El COO de SovereignAI, David Schwed, fue tajante:

“El fallo de Cloudflare hoy, el de AWS hace unas semanas, demuestran que no podemos delegar la ‘resiliencia’ de la infraestructura en un solo proveedor. Si tu organización necesita operar 24/7, debes construir la infraestructura asumiendo que los fallos ocurrirán. Si tu plan de continuidad es solo ‘esperar a que el proveedor lo arregle’, eso es pura negligencia.”

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

Jameson Lopp lo resumió así:

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

Lo que Ben Schiller dijo tras el último fallo de AWS sigue vigente:

“Si tu blockchain cae porque AWS falla, no es lo suficientemente descentralizada.”

Cambia “AWS” por “Cloudflare” y el problema es idéntico —el sector nunca aprende la lección.

¿Por qué elegir la “conveniencia” sobre los “principios”?

Construir infraestructura propia implica: comprar hardware caro, asegurar energía estable, mantener ancho de banda dedicado, contratar expertos en seguridad, redundancia geográfica, sistemas de recuperación ante desastres, monitorización 24/7 —todo requiere grandes recursos.

Usar Cloudflare solo requiere: hacer clic, introducir la tarjeta de crédito y desplegar en minutos.

La protección DDoS la gestiona otro, la disponibilidad la garantiza otro, la escalabilidad la resuelve otro.

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

Hasta que la “conveniencia” deja de ser conveniente.

El fallo de AWS en octubre provocó interminables debates sobre “descentralización” en Twitter.

¿Y el fallo de Cloudflare en noviembre? Silencio absoluto.

No por “silencio filosófico”, ni por “reflexión profunda”.

Sino porque quienes querían quejarse descubrieron que su plataforma habitual (Twitter) también estaba caída por el fallo de infraestructura.

Cuando el “punto único de fallo” es la plataforma que usas para burlarte de los “puntos únicos de fallo”, no tienes dónde quejarte.

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

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

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

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

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

El sector cripto, que debería ser la solución a la “centralización”, depende ahora 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, aunque construyó su infraestructura sobre AWS, también sufrió el fallo de la CDN de Cloudflare.

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

Hay una diferencia clave entre los fallos de octubre y noviembre:

Cuando falló AWS, la plataforma X (antes Twitter) seguía operativa, permitiendo a los usuarios cripto burlarse de la “fragilidad de la infraestructura”.

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

Cuando la plataforma que usas para “burlarte de los puntos únicos de fallo” es parte del propio “punto único de fallo”, ya no puedes reírte.

Esta ironía hizo que el debate sectorial quedara paralizado desde el principio.

Tres grandes fallos en 30 días han llamado la atención de los reguladores.

Cuestiones clave para los reguladores

• ¿Son estas empresas “instituciones de importancia sistémica”?
• ¿Deberían los servicios backbone de Internet ser regulados como “servicios públicos”?
• ¿Qué riesgos surgen cuando la infraestructura tecnológica es “demasiado grande para caer”?
• Si Cloudflare gestiona el 20% del tráfico global, ¿es esto un problema de monopolio?

Corinne Cath-Speth, de la organización Article 19, ya lo advirtió tras el último fallo de AWS: “Cuando un proveedor cae, los servicios críticos también caen —los medios quedan inaccesibles, Signal y otras apps seguras dejan de funcionar, la infraestructura que sostiene la sociedad digital se desmorona. Necesitamos urgentemente diversificar la nube”.

En otras palabras: los gobiernos empiezan a darse cuenta de que unas pocas empresas pueden paralizar Internet.

De hecho, las alternativas descentralizadas existen desde hace tiempo, pero nadie quiere adoptarlas.

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

¿Por qué las soluciones descentralizadas no despegan?

El rendimiento es inferior al de las soluciones centralizadas, y los usuarios perciben la latencia.

La adopción es bajísima y, comparado con la experiencia de “hacer clic en ‘desplegar en AWS’”, el proceso de las soluciones descentralizadas es engorroso.

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

La realidad es:

Construir infraestructura verdaderamente 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 la opción centralizada siempre es más fácil y barato —hasta que 4 fallos en 18 meses demuestran el alto precio oculto de la “simplicidad y bajo coste”.

El CEO de OORT, Dr. Max Li, lo denunció en una columna reciente en CoinDesk:

“Para una industria que presume de ‘descentralización’ y de sus ventajas, depender tan fuertemente de plataformas cloud centralizadas y frágiles es pura hipocresía.”

Su propuesta: una estrategia de nube híbrida, dispersando los sistemas críticos de los exchanges en redes descentralizadas.

Las plataformas cloud centralizadas tienen ventajas insustituibles en rendimiento y escala —pero cuando hay miles de millones de dólares en juego y cada segundo cuenta, su resiliencia es muy inferior a la de las soluciones distribuidas.

Solo cuando el coste de la “conveniencia” sea tan alto que cambie el comportamiento del sector, los “principios” superarán a la “conveniencia”.

Evidentemente, el fallo del 18 de noviembre no fue lo suficientemente grave, ni el de AWS el 20 de octubre, ni el de CrowdStrike en julio de 2024.

¿Cuánto más tendrá que pasar para que la “infraestructura descentralizada” pase de ser un “tema de conversación” a un “requisito imprescindible”?

El 18 de noviembre, el sector cripto no “fracasó” —la blockchain funcionó perfectamente.

El verdadero “fracaso” fue la mentira colectiva: creer que se pueden construir “aplicaciones imparables” sobre una infraestructura que puede colapsar; creer que la “resistencia a la censura” tiene sentido cuando tres empresas controlan el “canal de acceso”; creer que la “descentralización” es real cuando un archivo de configuración de Cloudflare decide si millones pueden o no operar.

Si la blockchain sigue generando bloques pero nadie puede enviar transacciones, ¿realmente está “en línea”?

El sector no tiene ningún plan de contingencia.

Cuando hay un fallo, solo queda esperar a que Cloudflare lo arregle, que AWS restablezca el servicio, que Azure despliegue el parche.

Ese es el “plan de recuperación ante desastres” actual del sector.

Imagina: ¿qué pasará si la identidad digital se integra profundamente con la blockchain?

El Tesoro de EE. UU. está impulsando la integración de credenciales de identidad en smart contracts, exigiendo KYC en cada interacción DeFi.

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

Un fallo de 3 horas se convertirá en 3 horas sin poder cargar la interfaz de verificación humana —solo porque el servicio de verificación corre sobre infraestructura caída.

Los “guardarraíles” regulatorios requieren que la infraestructura esté siempre en línea. El fallo del 18 de noviembre demostró que esa premisa es falsa.

Cuando el problema del “exceso de vigilancia” se haga evidente, los tecnólogos buscarán “protección de la privacidad”.

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

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

El próximo fallo ya se está gestando —puede venir de AWS, de Azure, de Google Cloud o de un nuevo fallo en Cloudflare.

Puede ser el mes que viene, o la próxima semana. La infraestructura no ha cambiado, las dependencias tampoco, ni los incentivos del sector.

Elegir la opción centralizada sigue siendo más barato, rápido y cómodo —hasta que deja de serlo.

Cuando el próximo cambio rutinario de configuración de Cloudflare active un bug oculto en un servicio crítico, volveremos a ver el mismo “guion”: páginas de error 500 por todas partes, trading paralizado, blockchain funcionando pero inaccesible, queriendo tuitear sobre “descentralización” pero con Twitter caído, promesas empresariales de “la próxima vez lo haremos mejor” que nunca se cumplen.

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

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

La próxima vez, el fallo podría durar más; la próxima vez, podría ocurrir en pleno colapso de mercado, cuando cada segundo de trading es vital; la próxima vez, el sistema de verificación de identidad podría verse también afectado.

Cuando la infraestructura de la que dependes colapse en el peor momento posible, ¿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, Sihou Computer, Jameson Lopp, Ben Schiller, Article 19, CoinTelegraph