El 18 de novembre de 2025, una gran part d'Internet es va col·lapsar.
Si obríeu ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase o innombrables llocs més petits, us apareixia una pàgina d'error 5xx de la marca Cloudflare, o els llocs simplement no es carregaven gens. El que al principi semblava un altre gran moment de "Internet està trencat" va resultar ser quelcom més subtil i, en certa manera, més preocupant: un error autoinfligit a l'interior de la pròpia infraestructura de Cloudflare.
A continuació, es mostra un resum detallat del que va passar durant l'interrupció de Cloudflare d'ahir (18 de novembre de 2025), per què va passar, a qui va afectar i quines lliçons n'haurien d'aprendre els equips d'infraestructura.
Què va passar realment ahir?
El dimarts 18 de novembre de 2025, cap a última hora del matí UTC, Cloudflare va començar a retornar grans volums d'errors del servidor HTTP 5xx per al trànsit que passava per la seva xarxa. Per als usuaris finals, això significava pàgines d'"Error intern del servidor" o "Error de passarel·la" en intentar accedir a molts llocs web i aplicacions populars.
Segons el propi blog posterior a l'incident de Cloudflare, la interrupció:
Va començar a afectar el trànsit HTTP dels clients a les 11:28 UTC
Va veure errors 5xx generalitzats a la CDN principal i als serveis de seguretat
Va tenir importants mesures de mitigació al voltant de les 13:05-14:30 UTC
Va retornar el volum d'errors 5xx a la línia base a les 17:06 UTC The Cloudflare Blog
El mateix Cloudflare la va descriure com la seva pitjor interrupció des del 2019, perquè no només va afectar una funció o un tauler de control, sinó que va interrompre la capa de proxy principal que encamina la major part del trànsit dels clients a través de la seva xarxa. The Cloudflare Blog
La supervisió de tercers ho va respaldar. Cisco ThousandEyes va patir una interrupció global que va afectar Cloudflare, amb temps d'espera i errors 5xx en serveis com X, OpenAI (ChatGPT) i Anthropic, mentre que les rutes de xarxa semblaven estar en bon estat. Això apuntava fermament a una fallada del servei de backend, no a un problema de nivell d'ISP o d'encaminament. ThousandEyes
Qui es va veure afectat?
Com que Cloudflare es troba davant d'una gran part d'Internet (al voltant del 20% dels llocs web depenen de Cloudflare per al rendiment i la seguretat), el radi de l'explosió va ser enorme. AP News+1
Entre els serveis que es van reportar com a afectats:
ChatGPT / OpenAI
X (anteriorment Twitter)
Canva, Shopify, Dropbox, Coinbase
League of Legends i altres plataformes de jocs
Diversos llocs de transport públic i governamentals, inclosos New Jersey Transit i els sistemes digitals ferroviaris SNCF de França AP News+1
Els rastrejadors d'interrupcions com Downdetector van registrar milers d'informes de problemes simultanis en el punt àlgid. Reuters va informar d'uns 5.000 usuaris afectats només per a X en un moment donat, abans que els recomptes disminuïssin a mesura que es desplegaven les solucions. Reuters
Des de la perspectiva d'un usuari, això es va manifestar com:
Llocs web que no es carreguen en absolut
Els fluxos d'inici de sessió es bloquegen o fallen (especialment quan hi havia Cloudflare Access o Turnstile implicats)
Les API responen de manera intermitent o amb errors 5xx
Els taulers de control i els panells d'administració s'esgoten
En altres paraules: grans parts d'Internet "es van sentir caigudes", tot i que la causa principal es concentrava en els sistemes interns d'un sol proveïdor.
Com funciona normalment Cloudflare (en termes senzills)
Per entendre per què aquesta interrupció va ser tan greu, és útil conèixer la ruta aproximada d'una sol·licitud a través de la xarxa de Cloudflare.
Cloudflare actua com a CDN de proxy invers i capa de seguretat:
El vostre navegador o aplicació es connecta a Cloudflare en lloc de directament al lloc d'origen.
Cloudflare finalitza TLS i HTTP a la vora.
Les sol·licituds flueixen cap al sistema de proxy principal de Cloudflare, anomenat FL ("Frontline") i la seva generació més recent de FL2.
Aquest proxy principal:
Aplica regles de WAF (firewall d'aplicacions web)
Executa models de gestió de bots
Gestiona la protecció DDoS, l'emmagatzematge en memòria cau i la sortida a l'origen
Dirigeix el trànsit a altres productes interns com ara Workers, R2, Access, etc. El blog de Cloudflare
En funcionament normal, aquesta arquitectura és altament resistent: si un centre de dades té un problema, el trànsit es dirigeix a través d'altres; els canvis de configuració es despleguen amb cura; les funcions individuals haurien de fallar de manera continguda.
L'interrupció d'ahir va ser precisament dolenta perquè l'error es va produir dins de la ruta de proxy comuna i estava estretament relacionat amb un fitxer de configuració que s'envia a tot el món amb freqüència i automàticament.
La causa principal: un fitxer de funció de gestió de bots que s'ha tornat inadequat
L'explicació oficial de Cloudflare apunta a un culpable clau:
un fitxer de configuració de funcions utilitzat pel seu sistema de gestió de bots. El blog de Cloudflare
Aquí teniu la cadena d'esdeveniments en llenguatge planer:
La gestió de bots utilitza un "fitxer de funcions"
El model de detecció de bots de Cloudflare es basa en un conjunt de "funcions", és a dir, senyals sobre cada sol·licitud que s'utilitzen per decidir si és humana o un bot.
Aquestes funcions s'agrupen en un fitxer de configuració que es regenera cada pocs minuts i es desplega globalment, de manera que Cloudflare es pot adaptar ràpidament als nous patrons d'atac. El blog de Cloudflare
Un canvi en el comportament de les consultes de ClickHouse
El fitxer de funcions es genera mitjançant consultes contra una base de dades de ClickHouse.
Cloudflare va fer un canvi al voltant de les 11:05 UTC per millorar la seguretat i els permisos per a les consultes distribuïdes.
usuaris de Wing per veure metadades no només d'un esquema per defecte, sinó també de les taules r0 subjacents. El blog de Cloudflare
La consulta que crea la llista de funcions no filtrava per nom de la base de dades; de sobte va començar a obtenir columnes duplicades tant de la versió per defecte com de la r0, duplicant efectivament el nombre de files de funcions.
El fitxer de funcions va explotar en mida
El mòdul Bot Management té un límit estricte sobre quantes funcions acceptarà (establert a 200, molt per sobre de les ~60 que normalment s'utilitzen).
Quan el fitxer recentment generat va superar aquest límit, el mòdul va arribar al límit i va entrar en pànic, a causa d'un error no gestionat al codi Rust que utilitzava Result::unwrap() en un valor d'error. El blog de Cloudflare
Els serveis de proxy principals van començar a retornar errors 5xx
Com que Bot Management està integrat a la ruta del proxy principal, el pànic va aparèixer com a respostes HTTP 5xx per a qualsevol trànsit que depengués d'aquest mòdul.
Al nou motor FL2, els clients van veure errors 5xx explícits.
Al motor FL més antic, les puntuacions dels bots baixaven silenciosament a zero, cosa que podia causar falsos positius en les regles de bloqueig de bots. El blog de Cloudflare
La part realment desagradable: el fitxer continuava alternant entre "bo" i "dolent"
El clúster ClickHouse s'actualitzava gradualment i el fitxer de funcions es regenerava cada cinc minuts.
De vegades, la consulta s'executava en nodes actualitzats (produint un fitxer dolent), de vegades en nodes no actualitzats (produint un fitxer bo).
Això va significar que durant un temps la xarxa de Cloudflare oscil·lava entre el funcionament normal i l'error a mesura que es propagaven diferents versions del fitxer. El blog de Cloudflare
Aquesta oscil·lació va fer que la situació fos extremadament confusa internament. Al principi, els equips de Cloudflare van sospitar d'un atac DDoS massiu perquè el patró d'error no semblava un simple bloqueig de programari. Fins i tot la pàgina d'estat de Cloudflare, que està allotjada fora de la seva pròpia infraestructura, va mostrar breument errors, una coincidència que va alimentar encara més la sospita d'un atac extern. El blog de Cloudflare+1
Només quan es van adonar que el factor comú era el fitxer de funcions del bot, la imatge es va aclarir.
Cronologia de l'incident
A partir de l'anàlisi post mortem de Cloudflare i dels informes de tercers, podem elaborar una cronologia aproximada per al 18 de novembre de 2025: The Cloudflare Blog+2ThousandEyes+2
11:05 UTC: s'implementa un canvi de control d'accés a la base de dades a ClickHouse.
11:20–11:30 UTC: comencen a generar-se i propagar-se versions incorrectes del fitxer de la funció Bot Management.
11:28 UTC: primer impacte en el client: s'observen errors HTTP 5xx elevats al trànsit del client.
11:30–11:32 UTC: les eines de supervisió externes i les proves automatitzades comencen a detectar errors intermitents.
11:35 UTC: Cloudflare obre una trucada d'incident interna; comença la investigació.
~11:48 UTC: Cloudflare publica una actualització d'estat confirmant un incident. Reenviar
11:30–13:05 UTC – Els equips se centren en el que sembla ser un comportament degradat de Workers KV i investiguen múltiples causes possibles (inclosos escenaris d'atac).
13:05 UTC – Mitigació clau: Workers KV i Cloudflare Access es desplacen per ometre el proxy principal; l'impacte es redueix. El bloc de Cloudflare
14:30 UTC – S'identifica la causa arrel; s'atura la generació i propagació de fitxers de funcions defectuosos. S'insereix manualment un fitxer de configuració que se sap que és correcte i es reinicia el proxy principal. La major part del trànsit principal torna a la normalitat. El bloc de Cloudflare
14:40–15:30 UTC – Els problemes del tauler de control i d'inici de sessió persisteixen, ja que Turnstile i l'acumulació d'intents d'autenticació creen pics de càrrega secundaris. El bloc de Cloudflare
17:06 UTC – Les taxes d'error tornen a la línia base; Cloudflare declara que els sistemes són completament normals. El blog de Cloudflare
Des del punt de vista de l'usuari, la interrupció va ser més greu entre finals del matí i principis de la tarda UTC, tot i que les finestres d'impacte exactes van variar segons la regió i els productes de Cloudflare dels quals depenia cada servei.
Per què aquesta interrupció és tan important
Risc de centralització
Cloudflare forma part d'un petit conjunt de proveïdors d'infraestructura d'Internet central, juntament amb les principals plataformes de núvol (AWS, Azure, GCP) i altres grans CDN. Quan un d'aquests actors falla, l'impacte és ampli i sovint no evident.
Aquesta interrupció:
No va provenir d'un error d'encaminament BGP ni d'un tall de cable d'ISP.
No va provenir d'un atac maliciós (malgrat les sospites inicials).
Va provenir d'una única configuració i limita un error en un component intern.
Això és important perquè mostra com els sistemes complexos i estretament acoblats poden fallar catastròficament fins i tot sense interferències externes. Quan moltes organitzacions es basen en el mateix proveïdor, aquest proveïdor es converteix en una peça sistèmicament important de facto d'Internet.
Les dependències "suaus" també van perjudicar
Alguns dels serveis afectats no només utilitzaven Cloudflare com una CDN ximple. Estaven:
Utilitzaven Cloudflare Access per a l'autenticació i l'accés zero-trust.
Utilitzaven Workers KV com a part dels plans de control intern.
Confiaven en Turnstile per a inicis de sessió resistents als bots. El blog de Cloudflare+1
Quan aquests productes fallaven, no només el contingut del lloc web va caure: els inicis de sessió, les funcions d'administració i les API internes també es van trencar. Això fa que la recuperació sigui més complexa: la vostra pàgina d'estat,
Les eines d'incidents o la interfície d'usuari d'administració també poden dependre del mateix proveïdor que acaba de fallar.
Què diu Cloudflare que canviarà
El blog de Cloudflare descriu diversos passos de remediació que l'empresa ja està prenent per reduir el risc que es repeteixi alguna cosa similar: The Cloudflare Blog
Endurir la ingestió de fitxers de configuració generats automàticament
Tractar les configuracions generades internament amb el mateix escepticisme i validació que l'entrada proporcionada per l'usuari, incloent-hi una comprovació estricta d'esquema i mida abans del desplegament.
Més interruptors de tancament globals
Facilitar la desactivació ràpida dels mòduls interns problemàtics (com ara Bot Management) a través de la xarxa, de manera que fallin en obrir-se en lloc de provocar el pànic a tota la ruta del proxy.
Protegir els recursos del sistema de les tempestes d'errors
Assegurar-se que els abocaments de memòria, les metadades de depuració i les eines d'observabilitat no puguin sobrecarregar la CPU i la memòria quan els errors comencin a augmentar.
Revisar els modes d'error als mòduls del proxy principal
Auditar sistemàticament com es comporta cada mòdul intern sota una entrada o configuració inesperada i garantir una degradació elegant en lloc d'un error global.
Refinar els desplegaments i l'aïllament
Tot i que no s'explica amb gran detall, l'incident suggereix que Cloudflare probablement segmentarà encara més com es propaguen les noves configuracions i els comportaments de les bases de dades, per reduir la possibilitat que un sol canvi incorrecte afecti tota la flota.
També van emmarcar l'incident com un fracàs absolut de les seves expectatives de resiliència, qualificant-lo d'"inacceptable" i reconeixent explícitament el dolor que va causar tant als clients com als usuaris d'Internet ordinaris. El blog de Cloudflare
Lliçons per a equips d'infraestructura i SRE
Encara que no executeu alguna cosa tan gran com Cloudflare, hi ha algunes lliçons de disseny i operació molt pràctiques en aquesta interrupció:
Tracteu la configuració interna com una entrada no fiable
És fàcil assumir que la "nostra" configuració generada sempre és correcta. Ahir demostra per què això és perillós:
Valideu sempre la mida, la forma i els límits dels fitxers de configuració abans d'aplicar-los.
Considereu primer l'aplicació canary de la configuració a un petit subconjunt de trànsit o nodes, amb una reversió automatitzada de les anomalies.
Mantingueu límits superiors estrictes i interruptors de circuit al voltant del recompte de funcions, la preasignació de memòria i l'ús de la CPU.
Disseny per a una fallada parcial elegant
Un error al mòdul de gestió de bots no hauria de poder fer entrar en pànic tota la ruta del proxy:
Per defecte, obertura per error vs. tancament per error en algunes capes de seguretat quan l'alternativa és una interrupció completa.
Crear interruptors de tancament clars i provats per a funcions no bàsiques.
Assegurar-se que els subsistemes crítics (autenticació, pàgina d'estat, eines d'incidents) puguin funcionar en mode degradat o a través de rutes alternatives.
Observar els senyals correctes
L'oscil·lació entre "bona configuració" i "mala configuració" cada cinc minuts feia que el senyal semblés trànsit d'atac o comportament extern sorollós:
Assegurar-se que teniu correlació per versió o per configuració al vostre pipeline d'observabilitat.
Crear quadres de comandament que facin que els canvis de configuració siguin visualment evidents a sobre dels gràfics d'errors.
Incloure proves sintètiques sòlides des d'un punt de vista extern, de manera que pugueu distingir ràpidament la fallada interna dels problemes de xarxa/ruta.
No poseu tots els ous en una sola cistella d'infraestructura
Per a organitzacions que utilitzen Cloudflare:
Considereu configuracions multi-CDN per a propietats realment crítiques.
Eviteu fer que la vostra pàgina d'estat depengui completament del mateix proveïdor que la vostra pila principal (Cloudflare ho fa, però ahir hi va haver problemes casuals amb l'amfitrió de la pàgina d'estat que van confondre encara més les coses). El blog de Cloudflare+1
Penseu-vos-ho dues vegades abans d'acoblar estretament l'autenticació, els plans de control de l'API i el lliurament del frontend al mateix proveïdor sense rutes de reserva.
El panorama general
Només en els darrers mesos, hem vist interrupcions importants a Microsoft Azure, Amazon Web Services i ara Cloudflare, totes les quals han deixat fora de servei temporalment grans parts dels serveis de consum i empresarials. AP News+2The Washington Post+2
El patró és clar:
Internet depèn cada cop més d'un grapat de proveïdors d'infraestructura gegants.
Les interrupcions sovint són autoinfligides, provinents de canvis interns complexos en lloc d'atacs externs.
Fins i tot els proveïdors amb pràctiques SRE de classe mundial encara poden ensopegar amb interaccions inesperades entre la configuració, el comportament de la base de dades i els límits codificats.
L'incident de Cloudflare d'ahir és un clar recordatori que "el núvol" no és màgia. En el fons, continua sent programari escrit per humans, subjecte a les mateixes classes d'errors que qualsevol altra aplicació, només que amb ordres de magnitud més de gent que en depèn.
Per als usuaris, l'incident es recordarà principalment com "aquell matí en què X i ChatGPT no es carregaven".
Per als enginyers, probablement s'estudiarà com un exemple de llibre de text de com els errors de configuració subtils en un sistema distribuït central poden convertir-se en un esdeveniment global d'Internet.
10471 
IT Pro 
