Cloudflare slaagt erin om probleem met core proxy relatief snel te stabiliseren

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 kern­ver­keer. Voor data­cen­ters en online diensten, die in hoge mate steunen op Cloudflare’s CDN- en bevei­li­gings­dien­sten, was de impact direct zichtbaar: foutcodes, vast­lo­pende authen­ti­ca­ties en haperende dash­boards. 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 ogen­schijn­lijk kleine data­ba­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 func­ti­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 tege­lij­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-data­base­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 waar­schijn­lijk het is dat het van een bot afkomstig is. Door de data­ba­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 over­schreden, 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, dash­boards 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 tijdelijk te laten terug­vallen op een oudere versie van de proxy. Dat was geen volledige oplossing, maar genoeg om het aantal fout­mel­dingen te verlagen.

Het defi­ni­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 opge­schoond. Om 17:06 verklaarde Prince alle diensten weer volledig operationeel.

Wat het incident betekent voor datacenterprofessionals

Voor data­cen­ters en operators toont dit incident hoe kwetsbaar zelfs hoog­ge­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 moni­to­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 onac­cep­tabel is. Dat ons netwerk gedurende enige tijd geen verkeer kon door­sturen, 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 omge­vingen met hoge door­voer­vo­lumes en lage latency-eisen, maar kan onge­wenste neven­ef­fecten hebben wanneer bron­be­standen onbedoeld groeien.

Maatregelen om herhaling te voorkomen

Cloud­flare kondigt in de blog een reeks maat­re­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 nood­stop­scha­ke­laars intro­du­ceren en fout­af­han­de­ling beter isoleren zodat kernel­panic-achtige situaties 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, veer­krach­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 waar­de­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 dash­boards tijdelijk uitscha­kelden, is het lang geleden dat het kern­ver­keer in deze mate werd geraakt. Data­cen­ters en speci­a­listen zullen vooral geïn­te­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 defi­ni­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 fundament dient voor een groot deel van het web is dat geen over­bo­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.