Cloudflaren merkittävä 18. marraskuuta katkos - yhteenveto

Marraskuun 18. päivänä 2025 valtava pala internetiä kaatui.
Jos avasit ChatGPT:n, X:n (Twitter), League of Legendsin, Shopifyn, Coinbasen tai lukemattomia pienempiä sivustoja, sinua tervehti Cloudflare-merkkinen 5xx-virhesivu - tai sivustot eivät latautuneet lainkaan. Se, mikä aluksi näytti jälleen yhdeltä suurelta "internet on rikki" -hetkeltä, osoittautui hienovaraisemmaksi ja jollakin tapaa huolestuttavammaksi: itse aiheutettu virhe syvällä Cloudflaren omassa infrastruktuurissa.

Alla on yksityiskohtainen selvitys siitä , mitä eilisessä Cloudflaren käyttökatkoksessa (18. marraskuuta 2025) tapahtui, miksi se tapahtui, keitä se kosketti ja mitä infrastruktuuritiimien pitäisi ottaa siitä opiksi.

Mitä eilen oikeastaan tapahtui?

Tiistaina 18. marraskuuta 2025 myöhään aamulla UTC:n aikaan Cloudflare alkoi palauttaa suuria määriä HTTP 5xx -palvelinvirheitä sen verkon kautta kulkevasta liikenteestä. Loppukäyttäjille tämä tarkoitti "Internal Server Error" tai "Gateway Error" -sivuja, kun he yrittivät käyttää monia suosittuja verkkosivustoja ja sovelluksia.

Cloudflaren oman tapahtuman jälkeisen blogin mukaan katkos:

• Alkoi vaikuttaa asiakkaiden HTTP-liikenteeseen kello 11:28 UTC.

• Näimme laajalle levinneitä 5xx-virheitä keskeisissä CDN- ja tietoturvapalveluissa.

• Merkittäviä lieventäviä toimenpiteitä toteutettiin noin klo 13:05-14:30 UTC.

• 5xx-virheiden määrä palautui perustasolle klo 17:06 UTC Cloudflaren blogi.

Cloudflare itse kuvaili sitä pahimmaksi katkokseksi sitten vuoden 2019, koska se ei vaikuttanut vain yhteen ominaisuuteen tai kojelautaan - se häiritsi ydinproxy-kerrosta, joka reitittää suurimman osan asiakkaiden liikenteestä sen verkon kautta. Cloudflaren blogi

Kolmannen osapuolen seuranta tuki tätä. Cisco ThousandEyes näki Cloudflareen vaikuttavan maailmanlaajuisen katkoksen, jossa oli aikakatkaisuja ja 5xx-virheitä palveluissa, kuten X, OpenAI (ChatGPT) ja Anthropic, kun taas itse verkkopolut näyttivät terveiltä. Tämä viittasi vahvasti taustapalvelun vikaan, ei ISP-tason tai reititysongelmaan. ThousandEyes

Ketä asia koski?

Koska Cloudflare sijaitsee valtavan osan internetin edessä (noin 20 prosenttia verkon sivustoista luottaa Cloudflareen suorituskyvyn ja tietoturvan osalta), räjähdysalue oli valtava. AP News+1

Vaikutuksen kohteeksi ilmoitettiin muun muassa seuraavat palvelut:

• ChatGPT / OpenAI

• X (entinen Twitter)

• Canva, Shopify, Dropbox, Coinbase.

• League of Legends ja muut pelialustat

• Erilaiset julkisen liikenteen ja hallinnon sivustot, mukaan lukien New Jersey Transit ja Ranskan SNCF:n digitaaliset rautatiejärjestelmät AP News+1.

Downdetectorin kaltaiset käyttökatkosten seurantalaitteet kirjasivat huipussaan tuhansia samanaikaisia vikailmoituksia. Reuters raportoi, että pelkästään X:ssä oli jossain vaiheessa noin 5 000 käyttäjää, ennen kuin lukumäärät laskivat korjausten valmistuttua. Reuters

Käyttäjän näkökulmasta tämä ilmeni seuraavasti:

• Sivustot eivät lataudu lainkaan

• Kirjautumisvirrat takkuilivat tai epäonnistuivat (erityisesti jos kyseessä oli Cloudflare Access tai Turnstile).

• API:t vastasivat ajoittain tai 5xx-virheillä.

• kojelautojen ja hallintapaneelien toiminta keskeytyi

Toisin sanoen: valtavat osat internetistä "tuntuivat olevan alhaalla", vaikka perussyy oli keskittynyt yhden palveluntarjoajan sisäisiin järjestelmiin.

Miten Cloudflare yleensä toimii (yksinkertaistetusti)?

Ymmärtääksemme, miksi tämä katkos oli niin vakava, on hyödyllistä tuntea pyynnön karkea reitti Cloudflaren verkon läpi.

Cloudflare toimii käänteisenä välityspalvelimena CDN:nä ja turvakerroksena:

1. Selaimesi tai sovelluksesi muodostaa yhteyden Cloudflareen sen sijaan, että ottaisit suoraan yhteyttä alkuperäiseen sivustoon.

2. Cloudflare päättää TLS:n ja HTTP:n sen reunalla.

3. Pyynnöt virtaavat Cloudflaren ydinproxyjärjestelmään, jota kutsutaan FL:ksi ("Frontline") ja sen uudemman sukupolven FL2:ksi.

4. Tämä ydinproxy:

   • Sovelletaan WAF-sääntöjä (web application firewall).

   • Suorittaa bottien hallintamalleja

   • Hoitaa DDoS-suojauksen, välimuistitallennuksen ja alkuperäisen lähteen poistumisen.

   • Reitittää liikenteen muihin sisäisiin tuotteisiin, kuten Workers, R2, Access jne. Cloudflaren blogi

Normaalissa toiminnassa tämä arkkitehtuuri on erittäin joustava: jos yhdessä datakeskuksessa on ongelma, liikenne ohjataan muiden kautta; konfiguraatiomuutokset otetaan käyttöön varovasti; yksittäisten ominaisuuksien pitäisi vikaantua hillityillä tavoilla.

Eilinen katkos oli juuri siksi huono, että vika oli itse yhteisessä välityspolussa, ja se oli tiukasti kytköksissä konfiguraatiotiedostoon, joka siirretään maailmanlaajuisesti usein ja automaattisesti.

Juurisyy: botinhallintaominaisuuksien tiedosto, joka on mennyt ryöstäytymään.

Cloudflaren virallinen selitys viittaa yhteen keskeiseen syylliseen:
Bottien hallintajärjestelmän käyttämä ominaisuuden konfigurointitiedosto. Cloudflaren blogi

Tässä on tapahtumaketju selkokielellä:

1. Bot Management käyttää "ominaisuustiedostoa".

   • Cloudflaren bottihavaintomalli perustuu joukon "ominaisuuksiin" - jokaista pyyntöä koskeviin signaaleihin, joiden perusteella päätetään, onko kyseessä ihminen vai botti.

   • Nämä ominaisuudet niputetaan konfigurointitiedostoon, joka luodaan uudelleen muutaman minuutin välein ja otetaan käyttöön maailmanlaajuisesti, jotta Cloudflare voi mukautua nopeasti uusiin hyökkäysmalleihin. Cloudflaren blogi

2. ClickHouse-kyselykäyttäytymisen muutos

   • Ominaisuustiedosto luodaan kyselyillä ClickHouse-tietokantaan.

   • Cloudflare teki muutoksen noin klo 11:05 UTC parantaakseen hajautettujen kyselyjen turvallisuutta ja käyttöoikeuksia - jolloin käyttäjät voivat nähdä metatietoja oletusskeeman lisäksi myös taustalla olevista r0-taulukoista. Cloudflaren blogi

   • Ominaisuusluettelon rakentava kysely ei suodattanut tietokannan nimen mukaan; yhtäkkiä se alkoi saada päällekkäisiä sarakkeita sekä oletus- että r0-taulukoista, mikä käytännössä kaksinkertaisti ominaisuusrivien määrän.

3. Ominaisuustiedoston koko kasvoi räjähdysmäisesti

   • Bottien hallintamoduulilla on kova raja sille, kuinka monta ominaisuutta se hyväksyy (asetettu 200:aan, mikä on huomattavasti enemmän kuin normaalisti käytössä olevat ~60).

   • Kun äskettäin luotu tiedosto ylitti tuon rajan, moduuli osui ylärajaan ja joutui paniikkiin Rust-koodin käsittelemättömän virheen takia, joka käytti Result::unwrap()-asetusta virhearvoon. Cloudflare-blogi

4. Ydinproxy-palvelut alkoivat palauttaa 5xx-virheitä

   • Koska Bot Management on integroitu core-välityspalvelupolkuun, paniikki ilmeni HTTP 5xx -vastauksina kaikessa liikenteessä, joka oli riippuvainen kyseisestä moduulista.

   • Uudessa FL2-moottorissa asiakkaat näkivät nimenomaisia 5xx-virheitä.

   • Vanhemmassa FL-moottorissa bottien pistemäärät menivät hiljaa nollaan, mikä saattoi aiheuttaa vääriä positiivisia tuloksia bottien estosäännöissä. Cloudflaren blogi

5. Todella ikävä osa: tiedosto vaihteli jatkuvasti "hyvän" ja "huonon" välillä.

   • ClickHouse-klusteria päivitettiin vähitellen, ja ominaisuustiedosto luotiin uudelleen viiden minuutin välein.

   • Joskus kysely suoritettiin päivitetyissä solmuissa (tuottaen huonon tiedoston), joskus päivittämättömissä solmuissa (tuottaen hyvän tiedoston).

   • Tämä tarkoitti sitä, että Cloudflaren verkko vaihteli jonkin aikaa normaalin toiminnan ja vian välillä, kun tiedoston eri versioita levitettiin. Cloudflaren blogi

Tämä heilahtelu teki tilanteesta sisäisesti erittäin sekavan. Aluksi Cloudflaren tiimit epäilivät massiivista DDoS-hyökkäystä, koska virhemalli ei näyttänyt yksinkertaiselta ohjelmiston kaatumiselta. Jopa Cloudflaren tilasivu, jota isännöidään heidän oman infrastruktuurinsa ulkopuolella, näytti hetkeksi virheitä - sattuma, joka lisäsi entisestään epäilyjä ulkoisesta hyökkäyksestä. Cloudflare-blogi+1

Vasta kun he tajusivat, että yhteinen tekijä oli botin ominaisuustiedosto, kuva kirkastui.

Välikohtauksen aikajana

Cloudflaren jälkipuinnin ja kolmansien osapuolten raporttien perusteella voimme koota karkean aikajanan 18. marraskuuta 2025: Cloudflare-blogi+2ThousandEyes+2

• 11:05 UTC - ClickHousessa otetaan käyttöön tietokannan käyttöoikeuksien hallinnan muutos.

• 11:20-11:30 UTC - Bot Management -ominaisuustiedoston huonoja versioita aletaan luoda ja levittää.

• 11:28 UTC - Ensimmäinen asiakasvaikutus: asiakasliikenteessä havaitaan kohonneita HTTP 5xx -virheitä.

• 11:30-11:32 UTC - Ulkoiset valvontatyökalut ja automaattiset testit alkavat havaita ajoittaisia vikoja.

• 11:35 UTC - Cloudflare avaa sisäisen häiriöpuhelun; tutkinta alkaa.

• ~11:48 UTC - Cloudflare julkaisee tilapäivityksen, jossa vahvistetaan häiriö. Lähetä uudelleen

• 11:30-13:05 UTC - Ryhmät keskittyvät siihen, mikä vaikuttaa heikentyneeltä Workers KV -käyttäytymiseltä, ja tutkivat useita mahdollisia syitä (mukaan lukien hyökkäysskenaariot).

• 13:05 UTC - Keskeinen lieventäminen: Workers KV ja Cloudflare Access on siirretty ohittamaan ydinproxy; vaikutus on vähentynyt. Cloudflaren blogi

• 14:30 UTC - Juurisyy tunnistettu; huonojen ominaisuustiedostojen luominen ja levittäminen lopetetaan. Tunnetusti hyvä konfiguraatiotiedosto lisätään manuaalisesti ja ydinproxy käynnistetään uudelleen. Suurin osa ydinliikenteestä palautuu normaaliksi. Cloudflare-blogi

• 14:40-15:30 UTC - Dashboard- ja kirjautumisongelmat jatkuvat, kun Turnstile ja autentikointiyritysten ruuhkauttavat toissijaisia kuormituspiikkejä. Cloudflaren blogi

• 17:06 UTC - Virhemäärät palaavat perustasolle; Cloudflare julistaa järjestelmät täysin normaaleiksi. Cloudflare-blogi

Käyttäjän näkökulmasta katkos tuntui pahimmalta myöhään aamulla ja varhain iltapäivällä UTC, vaikka tarkat vaikutusikkunat vaihtelivat alueittain ja sen mukaan, mistä Cloudflaren tuotteista kukin palvelu oli riippuvainen.

Miksi tämä katkos on niin tärkeä

Keskittämisriski

Cloudflare on osa pientä joukkoa keskitettyjä internetinfrastruktuuripalveluntarjoajia suurten pilvialustojen (AWS, Azure, GCP) ja muiden suurten CDN:ien ohella. Kun yksi näistä toimijoista kaatuu, vaikutus on laaja ja usein ei ole ilmeinen.

Tämä katkos:

• Se ei johtunut BGP-reititysongelmasta tai Internet-palveluntarjoajan kaapelin katkaisusta.

• Se ei johtunut pahantahtoisesta hyökkäyksestä (huolimatta alkuperäisistä epäilyistä).

• Se johtui sisäisen komponentin yksittäisestä konfiguraatio- ja rajoitusvirheestä.

Tämä on tärkeää, koska se osoittaa, miten monimutkaiset, tiukasti kytketyt järjestelmät voivat epäonnistua katastrofaalisesti jopa ilman ulkoisia häiriöitä. Kun monet organisaatiot rakentavat saman palveluntarjoajan varaan, palveluntarjoajasta tulee tosiasiallisesti järjestelmän kannalta tärkeä osa internetiä.

Myös "pehmeät" riippuvuudet vahingoittavat

Osa vahingoittuneista palveluista ei käyttänyt Cloudflarea vain tyhmänä CDN:nä. Ne käyttivät:

• Käyttivät Cloudflare Accessia todennukseen ja nollaluotettavuuteen.

• Käyttivät Workers KV: tä osana sisäisiä valvontatasoja.

• Luotettiin Turnstileen botteja kestäviä kirjautumisia varten. Cloudflaren blogi+1

Kun nämä tuotteet pettivät, ei vain verkkosivuston sisältö mennyt rikki - myös kirjautumiset, hallintatoiminnot ja sisäiset API:t menivät rikki. Tämä tekee toipumisesta monimutkaisempaa: tilasivusi, häiriötilanteiden työkalut tai ylläpitäjän käyttöliittymä saattavat myös luottaa juuri siihen palveluntarjoajaan, joka juuri epäonnistui.

Mitä Cloudflare sanoo muuttavansa

Cloudflaren blogissa hahmotellaan useita korjaustoimenpiteitä, joita yritys on jo toteuttamassa vähentääkseen riskiä, että jokin vastaava toistuu: Cloudflaren blogi

1. Automaattisesti luotujen konfiguraatiotiedostojen sisäänotto kovetetaan.
   Käsittele sisäisesti luotuja konfiguraatiotiedostoja samalla skeptisyydellä ja validoinnilla kuin käyttäjän antamaa syötettä, mukaan lukien tiukka skeeman ja koon tarkistus ennen käyttöönottoa.

2. Lisää globaaleja tappokytkimiä
   Helpota ongelmallisten sisäisten moduulien (kuten bottien hallinnan) nopeaa poistamista käytöstä koko verkossa, jotta ne epäonnistuvat auki sen sijaan, että koko välityspolku joutuisi paniikkiin.

3. Suojaa järjestelmäresursseja virhemyrskyiltä
   Varmista, etteivät core-dumpsit, virheenkorjausmetatiedot ja havainnointityökalut voi kuormittaa prosessoria ja muistia, kun virheet alkavat lisääntyä.

4. Tarkastele vikatiloja kaikissa ydinproxy-moduuleissa
   Tarkasta järjestelmällisesti, miten kukin sisäinen moduuli käyttäytyy odottamattoman syötteen tai kokoonpanon yhteydessä, ja varmista, että globaalin vikaantumisen sijasta tapahtuu pehmeä hajoaminen.

5. Tarkenna käyttöönottoja ja eristämistä
   Tapahtuman perusteella Cloudflare aikoo todennäköisesti segmentoida tarkemmin, miten uudet konfiguraatiot ja DB-käyttäytyminen leviävät, jotta voidaan vähentää mahdollisuutta, että yksittäinen huono muutos vaikuttaa koko laivastoon, vaikka sitä ei olekaan eritelty yksityiskohtaisesti.

Flflare kutsui tapausta myös joustavuusodotustensa täydelliseksi epäonnistumiseksi, kutsui sitä "mahdottomaksi hyväksyä" ja myönsi nimenomaisesti, että se aiheutti tuskaa sekä asiakkaille että tavallisille internetin käyttäjille. Cloudflaren blogi

Oppia infrastruktuuri- ja SRE-tiimeille

Vaikka et pyörittäisikään jotain yhtä suurta kuin Cloudflare, tämä katkos sisältää joitakin hyvin käytännöllisiä opetuksia suunnittelusta ja toiminnasta:

Käsittele sisäistä konfiguraatiota kuin epäluotettavaa syötettä.

On helppo olettaa, että "oma" luotu konfiguraatio on aina oikea. Eilinen osoittaa, miksi se on vaarallista:

• Varmista aina konfiguraatiotiedostojen koko, muoto ja rajat ennen niiden käyttöä.

• Harkitse konfiguraation varhaista soveltamista ensin pieneen osajoukkoon liikennettä tai solmuja ja automaattista palautusta poikkeustapauksissa.

• Pidä tiukat ylärajat ja katkaisijat ominaisuuksien lukumäärän, muistin ennakkoallokaation ja suorittimen käytön suhteen.

Suunnittele armollinen osittainen vikaantuminen

Yksi vika bottien hallintamoduulissa ei saisi aiheuttaa paniikkia koko välityspolulle:

• Oletusarvoisesti on fail-open vs. fail-closed joillakin tietoturvatasoilla, kun vaihtoehtona on täydellinen katkos.

• Rakennetaan selkeät, testatut tappokytkimet muille kuin ydinominaisuuksille.

• Varmistetaan, että kriittiset alijärjestelmät (auth, tilasivu, häiriötilanteiden työkalut) voivat toimia heikentyneessä tilassa tai vaihtoehtoisten reittien kautta.

Huomioi oikeat signaalit

Viiden minuutin välein tapahtuva vaihtelu "hyvän konfiguraation" ja "huonon konfiguraation" välillä sai signaalin näyttämään hyökkäysliikenteeltä tai ulkoiselta häiriökäyttäytymiseltä:

• Varmista, että havaittavuusputkistossasi on versio- tai konfiguraatiokohtainen korrelaatio.

• Rakenna kojelautoja, jotka tekevät konfiguraatiomuutokset visuaalisesti ilmeisiksi virhekaavioiden päälle.

• Sisällytä vahvoja synteettisiä testejä ulkoisesta näkökulmasta, jotta voit nopeasti erottaa sisäisen vian verkko-/polkuongelmista.

Älä laita kaikkia munia yhteen infrastruktuurikoriin.

Cloudflarea käyttäville organisaatioille:

• Harkitse useanDN:n kokoonpanoja todella kriittisiä ominaisuuksia varten.

• Vältä tekemästä tilasivuasi täysin riippuvaiseksi samasta palveluntarjoajasta kuin ensisijainen pinosi (Cloudflare tekee näin, mutta heidän tilasivunsa isännän kanssa oli eilen sattumalta ongelmia, jotka sekoittivat asioita entisestään). Cloudflare-blogi+1

• Mieti kahdesti, ennen kuin kytket todennuksen, API-ohjaustasot ja etusivun toimituksen tiukasti samaan toimittajaan ilman varapolkuja.

Suurempi kuva

Pelkästään viime kuukausina olemme nähneet suuria katkoksia Microsoft Azuressa, Amazon Web Servicesissä ja nyt Cloudflaressa, jotka kaikki ovat ajaneet tilapäisesti suuria osia kuluttaja- ja yrityspalveluista pois käytöstä. AP News+2TheWashington Post+2

Kuvio on selvä:

• Internet on yhä riippuvaisempi muutamasta jättimäisestä infrastruktuuripalveluntarjoajasta.

• Katkokset johtuvat usein itse aiheutetuista monimutkaisista sisäisistä muutoksista eivätkä niinkään ulkoisista hyökkäyksistä.

• Jopa palveluntarjoajat, joilla on maailmanluokan SRE-käytännöt, voivat silti kompastua yllättäviin vuorovaikutuksiin konfiguraation, tietokantojen käyttäytymisen ja kovakoodattujen rajoitusten välillä.

Eilinen Cloudflare-tapaus on selkeä muistutus siitä, että "pilvi" ei ole taikuutta. Pohjimmiltaan se on edelleen ihmisten kirjoittama ohjelmisto, joka altistuu samoille vikaluokille kuin mikä tahansa muukin sovellus - vain että siitä on riippuvainen kertaluokkaa enemmän ihmisiä.

Käyttäjät muistavat tapauksen useimmiten sanoilla "se aamu, kun X ja ChatGPT eivät latautuneet".
Insinöörit tulevat todennäköisesti tutkimaan sitä oppikirjaesimerkkinä siitä, miten hienovaraiset konfigurointivirheet keskeisessä hajautetussa järjestelmässä voivat levitä maailmanlaajuiseksi internet-tapahtumaksi.