Cloudflare's Majoor 18 november - Een samenvatting

Op 18 november 2025 viel er een enorm stuk internet.
Als je ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase, of ontelbare kleinere sites hebt geopend, werd je begroet met een Cloudflare-branded 5xx error pagina of de sites gewoon niet zou laden op alle. Wat eerst leek op nog een ander groot internet is kapot geworden moment bleek iets subtieler en, in sommige opzichten, meer verontrustend: een zelf toegebrachte bug diep in Cloudflare eigen infrastructuur.

Hieronder volgt een gedetailleerde wandeling van wat er gisteren gebeurd is in Cloudflare outage (18 november 2025), waarom het gebeurde, wie het beïnvloedde, en welke lessen infrastructuur teams moeten wegnemen.

Wat is er gisteren gebeurd?

Aan dinsdag 18 november 2025, rond late ochtend UTC, Cloudflare begon terug te keren grote volumes van HTTP 5xx server fouten voor het verkeer dat via zijn netwerk is gegaan. Voor eindgebruikers, dat betekende "instant Server Fout" of "Gateway Fout" pagina's bij het proberen om toegang te krijgen tot vele populaire websites en apps.

Volgens Cloudflares eigen post-incident blog, de storing:

• Gestart impact klant HTTP verkeer op 11:28 UTC

• Zag wijdverbreide 5xx fouten over kern CDN en beveiligingsdiensten

• Had belangrijke mitigatie stappen rond 13:05

• Returned 5xx error volume to baseline by 17:06 UTC Het Cloudflare-blog

Cloudflare zelf beschreef het als de ergste uitval sinds 2019, omdat het niet alleen invloed op een functie of dashboard .. het verstoorde de kern proxy laag die het grootste deel van het klantenverkeer door zijn netwerk. Het Cloudflare-blog

Dit werd ondersteund door toezicht door derden. Cisco ThousandEyes zag een wereldwijde uitval invloed hebben op Cloudflare, met time-outs en 5xx fouten op diensten zoals X, OpenAI (ChatGPT) en Antropic, terwijl netwerkpaden zelf er gezond uitzagen. Dat wijst sterk op een backend-servicefout, geen ISP-niveau of routering probleem. Duizendoog

Wie was er getroffen?

Want Cloudflare zit voor een groot deel van het internet (rond 20% van de websites De straal was enorm. AP Nieuws+1

Onder de diensten die als beïnvloed zijn gerapporteerd:

• ChatGPT / OpenAI

• X (voorheen Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends en andere gamingplatforms

• Diverse openbaar vervoer en overheidsterreinen, met inbegrip van New Jersey Transit en Franse SNCF-systemen AP Nieuws+1

Uitgangsvolgers zoals Downdetector opgenomen Duizenden gelijktijdig uitgebrachte rapporten op het hoogtepunt. Reuters meldde ongeveer 5.000 getroffen gebruikers voor X alleen op een punt, voordat de tellingen daalde als fixes uitgerold. Reuters

Vanuit een gebruikersperspectief manifesteerde dit zich als:

• Plaatsen die helemaal niet geladen zijn

• Login stromen hangen of falen (vooral waar Cloudflare Access of Turnstile betrokken waren)

• API's reageren intermitterend of met 5xx fouten

• Dashboards en admin panelen timing uit

Met andere woorden: enorme delen van het internet "voelt naar beneden," hoewel de oorzaak was geconcentreerd in een enkele provider.

Hoe Cloudflare normaal werkt (in eenvoudige termen)

Om te begrijpen waarom deze uitval zo ernstig was, helpt het om het ruwe pad van een verzoek te kennen via Cloudflares netwerk.

Cloudflare fungeert als een omgekeerde proxy CDN en beveiligingslaag:

1. Uw browser of app verbindt met Cloudflare in plaats van rechtstreeks met de oorsprongssite.

2. Cloudflare beëindigt TLS en HTTP aan de rand.

3. Verzoeken stromen naar Cloudflare kernproxysysteem, geroepen FL ( en zijn nieuwere generatie FL2.

4. Die kernproxy:

   • Geldt WAF (webapplicatie firewall) regels

   • Runs Botbeheer modellen

   • Handvatten DDoS-bescherming, caching, uitgang naar oorsprong

   • Routes verkeer naar andere interne producten zoals Werknemers, R2, Toegang, enz. Het Cloudflare-blog

In normale werking is deze architectuur zeer veerkrachtig: als één datacenter een probleem heeft, wordt het verkeer door anderen geleid; configuratiewijzigingen worden zorgvuldig uitgerold; individuele kenmerken moeten falen op een bepaalde manier.

Gisteren was de uitval precies slecht omdat de fout zat in het gemeenschappelijke proxy pad zelf, en het was strak gekoppeld aan een configuratiebestand dat wereldwijd wordt gepusht vaak en automatisch.

De root oorzaak: een bot-management feature bestand verdwenen schurk

De officiële verklaring van Cloudflare wijst op één belangrijke schuldige:
een functie configuratiebestand gebruikt door hun Bot Management systeem. Het Cloudflare-blog

Hier is de keten van gebeurtenissen in gewone taal:

1. Bot Management gebruikt een "feature file"

   • Cloudflare

2. Deze functies zijn gebundeld in een configuratiebestand dat wordt geregenereerd elke paar minuten Cloudflare kan zich snel aanpassen aan nieuwe aanvalspatronen. Het Cloudflare-blog

3. Een verandering in het ClickHouse-querygedrag

   • Het functiebestand wordt gegenereerd door vragen tegen een ClickHouse database.

4. Cloudflare maakte een verandering rond 11:05 UTC om de beveiliging en machtigingen voor gedistribueerde vragen te verbeteren . . waardoor gebruikers om metadata te zien niet alleen van een default schema maar ook van onderliggende r0 Tafels. Het Cloudflare-blog

5. De query die de functielijst bouwt heeft niet gefilterd op databasenaam; plotseling begon het te krijgen dubbele kolommen van beide default en r0, effectief verdubbelen van het aantal feature-rijen.

6. Het functiebestand explodeerde in grootte

   • De Bot Management module heeft een hard limit over hoeveel functies het zal accepteren (ingesteld op 200, ruim boven de ~60 normaal in gebruik).

   • Wanneer het nieuw gegenereerde bestand die limiet overschreed, raakte de module de cap en paniek, als gevolg van een niet-afgehandelde fout in Rust code die gebruikt Result::unwrap() op een foutwaarde. Het Cloudflare-blog

7. Core proxy services begonnen 5xx fouten terug te geven

   • Omdat Bot Management is geïntegreerd in de kern proxy pad, de paniek verscheen als HTTP 5xx antwoorden voor elk verkeer dat afhankelijk was van die module.

   • Op het nieuwe FL2 motor, klanten zagen expliciete 5xx fouten.

   • Ouderen FL Motor, bot scoort stilletjes ging naar nul, wat kan leiden tot valse positieven in bot-blokkering regels. Het Cloudflare-blog

8. Het echt vervelende deel: het bestand bleef flippen tussen

   • De ClickHouse cluster was geleidelijk bijgewerkt, en het feature-bestand werd elke vijf minuten gerecupereerd.

   • Soms liep de query op bijgewerkte knooppunten (het produceren van een slecht bestand), soms op niet-bijgewerkte knooppunten (het produceren van een goed bestand).

   • Dat betekende voor een tijdje, Cloudflare Het Cloudflare-blog

Deze oscillatie maakte de situatie zeer verwarrend intern. In eerste instantie vermoedden Cloudflare's teams een massale DDoS-aanval omdat het foutpatroon er niet uitzag als een eenvoudige software crash. Zelfs de wolkvlok statuspagina, die wordt gehost buiten hun eigen infrastructuur, kort liet fouten .. een toeval dat verder het vermoeden van een externe aanval brandstof. Het Cloudflare-blog+1

Pas toen ze beseften dat de gemeenschappelijke factor was de bot feature bestand werd het beeld duidelijk.

Tijdslijn van het incident

Op basis van de rapporten van Cloudflare... en van derden... kunnen we een ruwe tijdlijn samenstellen voor 18 november 2025: Het Cloudflare-blog+2Duizendoog+2

• 11:05 UTC Een database toegangscontrole verandering wordt ingezet in ClickHouse.

• 11:20 Slechte versies van de Bot Management functie bestand beginnen te worden gegenereerd en verspreid.

• 11:28 UTC Eerste klant impact: verhoogde HTTP 5xx fouten gezien op het klantenverkeer.

• 11.30 uur 11.30 uur 32 UTC Externe bewakingsinstrumenten en geautomatiseerde tests beginnen met het detecteren van intermitterende storingen.

• 11:35 UTC Cloudflare opent een interne oproep voor incidenten; onderzoek begint.

• ~11:48 UTC Cloudflare publiceert een status update die een incident bevestigt. Opnieuw verzenden

• 11.30 uur 13:05 uur Teams focussen zich op wat lijkt te zijn afgebroken Werknemers KV gedrag en onderzoeken meerdere mogelijke oorzaken (inclusief aanval scenario's).

• 13:05 UTC Belangrijkste beperking: Werknemers KV en Cloudflare Access worden verschoven om de kernproxy te omzeilen; impact wordt verminderd. Het Cloudflare-blog

• 14:30 UTC Een bekend-goed configuratiebestand wordt handmatig ingevoegd en de kernproxy wordt herstart. Het meeste verkeer is weer normaal. Het Cloudflare-blog

• 15:30 UTC Dashboard en login problemen blijven hangen als Turnstile en achterstand van authenticatie pogingen maken secundaire belasting pieken. Het Cloudflare-blog

• 17:06 UTC Foutpercentages keren terug naar baseline; Cloudflare verklaart systemen volledig normaal. Het Cloudflare-blog

Vanuit het oogpunt van de gebruiker, de storing voelde het ergste in de late ochtend tot vroege middag UTC, hoewel exacte impact vensters variëren per regio en waardoor Cloudflare producten elke dienst afhankelijk van.

Waarom deze uitval zo belangrijk is

Centraliseringsrisico

Cloudflare is onderdeel van een kleine set van centrale internetinfrastructuuraanbieders, naast de grote cloud platforms (AWS, Azure, GCP) en andere grote CDN's. Wanneer een van deze spelers faalt, is de impact breed en vaak niet duidelijk.

Deze storing:

• Kwam niet van een BGP routing ongeluk of een ISP kabel gesneden.

• Kwam niet van een kwaadaardige aanval (ondanks aanvankelijke vermoedens).

• Komt van een enkele configuratie en limiet bug in een intern onderdeel.

Dat is belangrijk omdat het laat zien hoe complexe, strak gekoppelde systemen kan catastrofaal falen, zelfs zonder externe interferentie. Wanneer veel organisaties bouwen op dezelfde provider, die provider wordt een de-facto systemisch belangrijk stukje internet.

De afhankelijkheden doen ook pijn.

Sommige van de getroffen diensten waren niet alleen met behulp van Cloudflare als een domme CDN. Ze waren:

• Gebruik Toegang tot cloudflare voor authenticatie en toegang tot nul vertrouwen.

• Gebruik Werknemers KV als onderdeel van interne controlevliegtuigen.

• Vertrouwen op Turnstile voor bot-resistente logins. Het Cloudflare-blog+1

Toen die producten mislukten, was het niet alleen website-inhoud die ging naar beneden logins, admin-functies en interne API's Ook blut. Dat maakt herstel complexer: uw status pagina, incident tooling, of admin UI kan ook vertrouwen op de provider die gewoon mislukt.

Wat Cloudflare zegt dat het zal veranderen

Cloudflares blog schetst verschillende herstel stappen die het bedrijf al neemt om het risico van iets dergelijks terugkerende te verminderen: Het Cloudflare-blog

1. Harde opname van automatisch gegenereerde configuratiebestanden
   Behandel intern gegenereerde configuraties met hetzelfde scepticisme en validatie als door de gebruiker geleverde invoer, inclusief strikte schema en groottecontrole voor uitrol.

2. Meer wereldwijde kill switches
   Maak het makkelijker om snel problematische interne modules (zoals Bot Management) op het netwerk uit te schakelen, zodat ze falen open in plaats van het hele proxy pad in paniek te brengen.

3. Bescherm systeembronnen tegen foutstormen
   Zorg ervoor dat core dumps, debug metadata en observability tooling niet kunnen overweldigen CPU en geheugen wanneer fouten beginnen te pieken.

4. Beoordelen van foutmodi tussen kernproxymodules
   Systematisch controleren hoe elke interne module zich gedraagt onder onverwachte input of configuratie, en zorgen voor sierlijke degradatie in plaats van globale mislukking.

5. Verfijn uitrol en isolatie
   Hoewel niet gespeld in enorme detail, het incident suggereert Cloudflare zal waarschijnlijk verder segment hoe nieuwe configuraties en DB gedrag zich voortplanten, om de kans te verminderen dat een enkele slechte verandering de hele vloot beïnvloedt.

Ze omlijsten het incident ook als een absolute mislukking van hun veerkracht verwachtingen, noemen het onacceptabel ... en expliciet erkennen van de pijn die het veroorzaakte zowel klanten als gewone internetgebruikers. Het Cloudflare-blog

Lessen voor infrastructuur & SRE-teams

Zelfs als je niet iets zo groots als Cloudflare draait, zijn er een aantal zeer praktische ontwerp en operationele lessen in deze storing:

Behandel interne configuratie als onbetrouwbare invoer

Het is gemakkelijk om aan te nemen dat onze eigen gegenereerde configuratie altijd correct is. Gisteren laat zien waarom dat gevaarlijk is:

• Altijd valideren grootte, vorm en grenzen van configuratiebestanden voordat ze worden toegepast.

• Overweeg kanarietoepassing van config naar een kleine subset van verkeer of knooppunten eerst, met automatische terugrol op anomalieën.

• Blijf streng bovengrens en stroomonderbrekers rond functie telt, geheugen voortoewijzing, en CPU gebruik.

Ontwerp voor sierlijk gedeeltelijk falen

Een fout in de Bot Management module zou niet in staat moeten zijn om het gehele proxypad in paniek brengen:

• Standaard fail-open vs fail-closed in sommige lagen van beveiliging wanneer het alternatief volledig uitval is.

• Bouw helder, getest schakelschakelaars voor niet-kernfuncties.

• Zorg ervoor dat kritieke subsystemen (auth, statuspagina, incident tooling) kunnen werken in gedegradeerde modus of via alternatieve routes.

Observeer de rechts signalen

De oscillatie tussen de goede configuratie en de slechte configuratie liet het signaal er elke vijf minuten uitzien als aanvalsverkeer of luidruchtig extern gedrag:

• Zorg ervoor dat u perversie of per-config correlatie in uw waarnemingspijplijn.

• Bouw dashboards die configuratiewijzigingen visueel duidelijk maken bovenop foutgrafieken.

• Sterk opnemen synthetische tests vanuit een extern uitkijkpunt, zodat u snel interne storingen kunt onderscheiden van netwerk/path problemen.

Doe niet al je eieren in één infra mand

Voor organisaties die Cloudflare gebruiken:

• Overweeg multi-CDN setups voor echt missie-kritische eigenschappen.

• Vermijd het maken van statuspagina volledig afhankelijk van dezelfde provider als uw primaire stack (Cloudflare doet dit, maar er was toevallige problemen met hun status pagina host gisteren die verwarde dingen verder). Het Cloudflare-blog+1

• Denk twee keer na voordat u uw authenticatie, API-besturingsvliegtuigenen frontend levering aan dezelfde leverancier zonder terugval paden.

Het grotere geheel

Alleen al in de laatste paar maanden hebben we grote uitval gezien bij Microsoft Azure, Amazon Web Services, en nu Cloudflare, die allemaal tijdelijk grote stukken consumenten- en zakelijke diensten offline hebben geslagen. AP Nieuws+2De Washington Post+2

Het patroon is duidelijk:

• Het internet wordt steeds meer afhankelijk van een handvol gigantische infrastructuurleveranciers.

• Uitval is vaak zelf toegebracht, afkomstig van complexe interne veranderingen in plaats van externe aanvallen.

• Zelfs aanbieders met SRE-praktijken van wereldklasse kunnen nog steeds worden gestruikeld door onverwachte interacties tussen configuratie, databasegedrag en moeilijk gecodeerde grenzen.

Gisteren is Cloudflare incident een grimmige herinnering dat De wolk is geen magie.. Aan de onderkant, is het nog steeds software geschreven door mensen, onderworpen aan dezelfde klassen van bugs als elke andere applicatie.

Voor gebruikers, het incident zal meestal worden herinnerd als die ochtend wanneer X en ChatGPT zou niet laden.
Voor ingenieurs zal het waarschijnlijk worden bestudeerd als een schoolvoorbeeld van hoe subtiele configuratie bugs in een kern gedistribueerd systeem kan rimpelen uit in een wereldwijde internet gebeurtenis.