De wereld­wijde inter­net­in­fra­struc­tuur kreeg op 18 november 2025 een stevige klap te verwerken toen Cloud­flare urenlang problemen had met het verwerken van kernver­keer. Voor datacen­ters en online diensten, die in hoge mate steunen op Cloudflare’s CDN- en bevei­li­gings­dien­sten, was de impact direct zicht­baar: foutcodes, vastlo­pende authen­ti­ca­ties en haperende dashboards. In een uitge­breide blogpost blikte CEO Matthew Prince terug op wat hij omschreef als “de ergste storing sinds 2019” en legde hij uit hoe een ogenschijn­lijk kleine databa­se­wij­zi­ging kon uitgroeien tot een versto­ring die het wereld­wijde inter­net­ver­keer beïnvloedde.

Een storing die zich vreemd gedroeg

De problemen begonnen om 11:20 UTC, toen gebrui­kers foutpagina’s te zien kregen voor sites die via Cloud­flare liepen. Al snel bleek dat het verkeer in de kernproxy – het systeem dat elk inkomend verzoek verwerkt voordat het naar de juiste dienst wordt geleid – niet goed meer functi­o­neerde. In zijn blog schrijft Prince dat het Cloud­flare-team aanvan­ke­lijk dacht aan een groot­scha­lige DDoS-aanval, mede omdat tegelij­ker­tijd ook de status­pa­gina uitviel, een combi­natie die volgens hem “in eerste instantie alle alarm­bellen deed afgaan”.

Wat volgde was een onvoor­spel­baar patroon van uitval en herstel: het systeem leek de ene minuut te stabi­li­seren, om enkele minuten later opnieuw te falen. De reden bleek later verbluf­fend technisch maar tegelijk eenvoudig: het confi­gu­ra­tie­be­stand van Cloudflare’s botbe­heer­sys­teem werd elke vijf minuten opnieuw samen­ge­steld door een Click­House-database­cluster dat net een toegangs­rech­te­nup­date kreeg. Alleen de shards waar die update al actief was, leverden foutieve data op. Daardoor wisselde het netwerk voort­du­rend tussen goede en slechte configuraties.

De oorzaak: een configuratiebestand dat te groot werd

De kern van de storing lag in het bestand dat wordt gebruikt om bots te detec­teren. Dit zogeheten ‘feature-bestand’ voedt een machine-learning­model dat voor elk verzoek bepaalt hoe waarschijn­lijk het is dat het van een bot afkom­stig is. Door de databa­se­wij­zi­ging ontstonden er dupli­caten in de dataset, waardoor het bestand meer dan twee keer zo groot werd. De software die de confi­gu­ra­ties verwerkt, heeft een harde limiet op het aantal kenmerken om geheu­gen­pro­blemen te voorkomen. Die limiet werd overschreden, waarna de proxy­soft­ware in paniek stopte.

Prince noemt dit een fout in het ontwerp: “Onze systemen moeten bestand zijn tegen verkeerde of onver­wachte input, zeker als die input uit onze eigen infra­struc­tuur komt.”

Het gevolg was dat de kernproxy voor een aanzien­lijk deel van het verkeer 5xx-fouten begon terug te geven. Voor diensten die op die proxy steunen – zoals Workers KV, Access en Turnstile – had dit verstrek­kende gevolgen. Authen­ti­ca­ties liepen vast, dashboards konden niet geladen worden en sommige botscore-regels bij klanten sloegen volledig door.

Patchwork om het verkeer overeind te houden

Rond 13:05 wist Cloud­flare de impact te beperken door Workers KV en Access tijde­lijk te laten terug­vallen op een oudere versie van de proxy. Dat was geen volle­dige oplos­sing, maar genoeg om het aantal foutmel­dingen te verlagen.

Het defini­tieve herstel kwam pas toen het team de distri­butie van nieuwe confi­gu­ra­tie­be­standen stopzette en handmatig een eerdere, goede versie injec­teerde. Om 14:30 UTC stroomde het grootste deel van het verkeer weer normaal. Daarna volgden nog uren waarin systemen die in een slechte toestand waren geraakt opnieuw moesten worden opgestart of opgeschoond. Om 17:06 verklaarde Prince alle diensten weer volledig operationeel.

Wat het incident betekent voor datacenterprofessionals

Voor datacen­ters en opera­tors toont dit incident hoe kwets­baar zelfs hoogge­au­to­ma­ti­seerde infra­struc­tuur­ke­tens kunnen zijn wanneer een intern systeem op onver­wachte wijze faalt. Het laat ook zien hoe breed de effecten kunnen uitwaai­eren: niet alleen latency en foutcodes, maar ook authen­ti­catie, debug­ging­tools en zelfs monito­ring­plat­forms kunnen rol na rol omvallen wanneer de kernproxy hapert. Prince erkent dit openlijk: “Onze rol in het inter­ne­te­co­sys­teem betekent dat elke storing onaccep­tabel is. Dat ons netwerk gedurende enige tijd geen verkeer kon doorsturen, is pijnlijk voor ieder lid van ons team.”

Daarnaast benadrukt het incident het belang van grenzen binnen confi­gu­ra­tie­sys­temen. De limieten die waren ingesteld om geheugen te beschermen, bleken uitein­de­lijk de directe trigger voor de fouten. Dit type bescher­mings­me­cha­nisme is gangbaar in omgevingen met hoge doorvoer­vo­lumes en lage latency-eisen, maar kan ongewenste neven­ef­fecten hebben wanneer bronbe­standen onbedoeld groeien.

Maatregelen om herhaling te voorkomen

Cloud­flare kondigt in de blog een reeks maatre­gelen aan om het systeem robuuster te maken. Het bedrijf wil de input­va­li­datie van interne confi­gu­ra­tie­be­standen versterken, globale noodstop­scha­ke­laars intro­du­ceren en foutaf­han­de­ling beter isoleren zodat kernel­panic-achtige situa­ties in de proxy in de toekomst worden vermeden. Ook worden limieten en faalmodi van alle proxy-modules opnieuw geëvalueerd.

Prince zegt hierover dat het incident “nieuwe, veerkrach­tiger systemen zal opleveren, net zoals eerdere storingen dat hebben gedaan.” Het past in een bredere Cloud­flare-strategie om de stap te maken naar FL2, een nieuwe generatie van de kernproxy. Deze proxy werd eveneens getroffen, maar op andere manieren dan de oude FL-engine. Het incident biedt het bedrijf daarmee waarde­volle inzichten in beide platforms.

Een zeldzame maar ingrijpende storing

Hoewel Cloud­flare de afgelopen jaren herhaal­de­lijk kleine storingen had die functies of dashboards tijde­lijk uitscha­kelden, is het lang geleden dat het kernver­keer in deze mate werd geraakt. Datacen­ters en speci­a­listen zullen vooral geïnte­res­seerd zijn in de vraag hoe Cloud­flare struc­tu­reel kan voorkomen dat fouten in confi­gu­ra­tie­ge­ne­ratie zich razend­snel wereld­wijde verspreiden. De blog van Prince biedt daar nog geen defini­tieve antwoorden op, maar wel de eerste contouren.

Met een uitge­breid excuus sluit hij zijn blog af: “Namens het hele team willen we ons veront­schul­digen voor de problemen die we vandaag op internet hebben veroorzaakt.”

Voor een infra­struc­tuur die als funda­ment dient voor een groot deel van het web is dat geen overbo­dige luxe. Maar uitein­de­lijk gaat het er vooral om wat Cloud­flare nu leert van dit incident – en hoe het netwerk wordt versterkt voordat een verge­lijk­bare fout opnieuw onver­wacht toeslaat.