Cloudflare 18 नवंबर 2025 आउटेज का पोस्टमॉर्टम विश्लेषण

• 18 नवंबर 2025 को 11:20 (UTC) पर Cloudflare नेटवर्क की मुख्य ट्रैफिक डिलीवरी क्षमता ठप हो गई, जिससे दुनिया भर के उपयोगकर्ताओं को error pages दिखाई दिए
• कारण डेटाबेस permission बदलाव की वजह से Bot Management सिस्टम की ‘feature file’ का असामान्य रूप से बड़ा हो जाना था, और इसका साइबर हमले से कोई संबंध नहीं था
• इस file size वृद्धि के कारण ट्रैफिक routing software अपनी सीमा से आगे निकलकर fail हो गया, और बड़े पैमाने पर HTTP 5xx errors हुए
• लगभग 14:30 पर समस्या वाली file की deployment रोकी गई और उसे पिछली स्थिर version से बदलकर मुख्य ट्रैफिक बहाल किया गया; 17:06 पर सभी सेवाएं सामान्य हो गईं
• Cloudflare ने इस घटना को 2019 के बाद की सबसे खराब outage बताया है और configuration file validation को मजबूत करने तथा global kill switch लागू करने जैसे पुनरावृत्ति-रोधी कदम आगे बढ़ा रहा है

---

आउटेज का सार

• लगभग 11:20 पर Cloudflare नेटवर्क में मुख्य ट्रैफिक डिलीवरी विफल हो गई, और उपयोगकर्ताओं को Cloudflare का internal error page दिखाई दिया
• साइबर हमला या दुर्भावनापूर्ण गतिविधि इसका कारण नहीं थी; डेटाबेस सिस्टम में permission बदलाव ही प्रत्यक्ष कारण था
• इस बदलाव के कारण Bot Management सिस्टम द्वारा इस्तेमाल की जाने वाली ‘feature file’ का आकार दोगुना हो गया और वह पूरे नेटवर्क में deploy हो गई
• ट्रैफिक routing software ने इस file को पढ़ते समय file size limit पार कर दी, जिससे system error हुआ
• शुरुआत में इसे बड़े DDoS हमले के रूप में गलत समझा गया, लेकिन कारण पता चलने के बाद पिछली सामान्य file से बदलकर recovery की गई

आउटेज की प्रगति और प्रभाव

• 11:20 से पहले 5xx error rate सामान्य स्तर पर था, लेकिन उसके बाद गलत feature file deployment से errors अचानक बढ़ गए
• ClickHouse database cluster के कुछ nodes पर गलत query results हर 5 मिनट में बन रहे थे, जिससे सामान्य और असामान्य files बारी-बारी deploy होती रहीं और system बार-बार recover और fail होता रहा
• 14:30 से समस्या वाली file generation रोकी गई और सामान्य file मैन्युअली insert की गई; core proxy restart के साथ recovery हुई
• 17:06 पर सभी सेवाएं सामान्य हो गईं

सेवा	प्रभाव
Core CDN और security services	HTTP 5xx errors हुए
Turnstile	load fail, login असंभव
Workers KV	gateway failure के कारण 5xx errors में तेज वृद्धि
Dashboard	Turnstile outage के कारण login असंभव
Email Security	spam detection accuracy में अस्थायी गिरावट, कुछ automatic moves fail
Access	बड़ी संख्या में authentication failures, मौजूदा sessions बने रहे

• आउटेज के दौरान CDN response latency बढ़ी, जिसका कारण debugging system का CPU usage अचानक बढ़ना था

आउटेज का कारण: Bot Management सिस्टम

• Cloudflare का Bot Management module हर request के लिए bot score बनाने हेतु machine learning models का उपयोग करता है
• model input के रूप में उपयोग होने वाली feature configuration file हर कुछ मिनट में पूरे नेटवर्क पर deploy की जाती है ताकि नए threats का जवाब दिया जा सके
• ClickHouse query behavior में बदलाव के कारण बहुत-सी duplicate feature rows शामिल हो गईं, जिससे file size बढ़ गया
• इसके कारण Bot Management module में error आया और उसने HTTP 5xx responses लौटाए, जिसका असर Workers KV और Access पर भी पड़ा
• नए proxy engine FL2 में 5xx errors हुए, जबकि पुराने version FL में bot score 0 पर सेट हो गया, जिससे false positives बढ़े

ClickHouse query behavior में बदलाव

• 11:05 पर ClickHouse की database access permission change deploy की गई
• पहले केवल default database का metadata query किया जा सकता था, लेकिन बदलाव के बाद r0 database का metadata भी exposed हो गया
• Bot Management की feature file generation query database name filter के बिना चली, और नतीजतन duplicate columns वापस आए
• इससे feature file में rows की संख्या दोगुने से अधिक हो गई और system limits पार हो गईं

memory pre-allocation और system panic

• Bot Management module अधिकतम 200 machine learning features की सीमा मानकर memory pre-allocate करता है
• गलत file में 200 से अधिक features होने पर Rust code में panic हुआ,
  thread fl2_worker_thread panicked: called Result::unwrap() on an Err value error output हुआ
• इसके कारण बड़े पैमाने पर HTTP 5xx errors हुए

अन्य प्रभाव और recovery प्रक्रिया

• Workers KV और Access core proxy पर निर्भर थे, जिससे outage का प्रभाव बढ़ गया
  • 13:04 पर Workers KV को proxy bypass कराने के लिए patch किया गया, जिससे error rate कम हुआ
• Dashboard, Turnstile और Workers KV पर निर्भर होने के कारण login नहीं कर पा रहा था
  • 11:30~13:10 और 14:40~15:30 के दौरान दो बार availability घटी
  • backlog और retry requests के कारण latency बढ़ी, और लगभग 15:30 पर recovery हुई
• 14:30 के बाद अधिकांश सेवाएं सामान्य हो गईं, और 17:06 पर पूर्ण recovery हुई

पुनरावृत्ति-रोधी उपाय

• Cloudflare द्वारा generated configuration files के input validation को मजबूत करना
• global feature kill switch का विस्तार
• error reporting के कारण system resource exhaustion को रोकना
• core proxy modules में error conditions की व्यापक समीक्षा

timeline सारांश (UTC)

समय	स्थिति	विवरण
11:05	सामान्य	database access control change deploy
11:28	प्रभाव शुरू	customer traffic में पहली error हुई
11:32–13:05	जांच जारी	Workers KV error के कारण का विश्लेषण, mitigation प्रयास
13:05	प्रभाव कम	Workers KV और Access के लिए bypass लागू
13:37	recovery कार्य पर फोकस	Bot Management configuration file rollback की तैयारी
14:24	समस्या वाली file deployment बंद	सामान्य file का परीक्षण पूरा
14:30	मुख्य प्रभाव समाप्त	सामान्य file का global deployment, service recovery शुरू
17:06	पूर्ण recovery	सभी सेवाएं पूरी तरह सामान्य

निष्कर्ष

• यह outage Bot Management configuration file generation logic और database permission change के परस्पर प्रभाव से हुआ
• Cloudflare ने इसे 2019 के बाद का सबसे गंभीर network disruption बताया
• आगे system resiliency बढ़ाने के लिए संरचनात्मक सुधार और automated defense mechanisms को मजबूत किया जाएगा

[t7vonn]

कॉन्फ़िगरेशन फ़ाइल से जुड़ी आउटेज तो कहीं भी हो जाती हैं।

[princox]

Cloudflare काम नहीं कर रहा था, इसलिए हर तरह की सेवाएं बंद हो गईं — सचमुच नर्क जैसा लग रहा था..

[epdlemflaj]

लगता है root cause analysis दस्तावेज़ काफ़ी जल्दी जारी कर दिया गया था, हाहा

[epdlemflaj]

वैसे, यह लेख लिखने वाला CEO था।

[GN⁺]

Hacker News राय

• यह कई मिलियन डॉलर की .unwrap() दुर्घटना-कथा है
  इंटरनेट के मुख्य इन्फ्रास्ट्रक्चर path में .unwrap() कॉल करना लगभग यह घोषित करने जैसा है कि “यह कभी fail नहीं होगा, और अगर हुआ तो तुरंत thread को मार दो”
  Rust compiler इस बात को मजबूर करता है कि failure की संभावना को स्पष्ट रूप से व्यक्त किया जाए, लेकिन यहाँ इसे graceful तरीके से handle करने के बजाय panic चुना गया
  मुझे लगता है कि यह “parse, don’t validate” anti-pattern का एक क्लासिक उदाहरण है

  • बहुत से लोगों के .unwrap() को लेकर blind spot हैं। शायद इसलिए क्योंकि यह example code में अक्सर दिखता है
    असली production code में .unwrap() या .expect() को panic की तरह review किया जाना चाहिए
    अगर production code में .unwrap() इस्तेमाल करते हैं, तो उसके साथ ज़रूर “INFALLIBILITY” comment होना चाहिए, और clippy::unwrap_used से इसे enforce किया जा सकता है
  • इस लेख का मुख्य बिंदु शायद किसी एक कारण से ज़्यादा सामान्य components के संयोजन के कारण समस्या पैदा होना है
    मामला सिर्फ .unwrap() का नहीं था, बल्कि query ने database को अलग नहीं किया, जिससे payload बड़ा हो गया, और ClickHouse ने ज़्यादा DB expose कर दिए
    इसे केवल “unwrap की वजह से” कहना ठीक नहीं होगा; मेरे हिसाब से global kill switch या ऐसे design improvements ज़्यादा महत्वपूर्ण हैं जो system resources को overwhelm होने से रोकें
  • असल में यह Rust path के बाहर भी fail हुआ। क्योंकि bot management system ने सारे traffic को bot के रूप में classify कर दिया
    FL2 layer पर हर component के panic को पकड़ना चाहिए, लेकिन fail-open हमेशा बेहतर नहीं होता
    FL2 level पर logic जोड़ना चाहिए ताकि यह explicitly तय हो सके कि panic को पकड़कर handle करना है या नहीं
  • अगर इसे graceful तरीके से handle किया गया होता, तो शायद performance degradation होती (फिर भी reliability degradation से तो बेहतर ही होता)
    अगर यह sharded system है, तो यह भी सवाल है कि gradual rollout और monitoring क्यों नहीं थी
  • Swift में implicit ! unwrap और explicit ? unwrap होते हैं
    मैं implicit unwrap लगभग कभी इस्तेमाल नहीं करता। value guaranteed हो तब भी मैं इसे हमेशा explicitly handle करता हूँ
    उदाहरण के लिए, @IBOutlet weak var someView! की जगह @IBOutlet weak var someView? define करता हूँ
    यह एक तरह का belt & suspenders approach है

• outage के 24 घंटे पूरे होने से पहले ही post mortem प्रकाशित करना वाकई काबिले-तारीफ़ है

  • मैं जानना चाहूँगा कि इतनी तेज़ी और transparency के साथ publish करने की internal policy क्या है
    ज़्यादातर बड़ी कंपनियों में कई stakeholder reviews की वजह से code disclosure लगभग नामुमकिन होता है
  • ऊपर से लेख खुद भी बहुत अच्छी तरह लिखा गया है। AWS के postmortem से तुलना करें तो यह लगभग साहित्य जैसा लगता है

• Cloudflare की outage explanation पढ़ते हुए मेरे मन में आया, “recovery में इतना समय क्यों लगा?”
  outage का कारण समझ में आया, लेकिन अगर network का अधिकांश हिस्सा down था, तो हाल का configuration change rollback करना सबसे पहली प्राथमिकता नहीं होना चाहिए था?
  बेशक बाद में यह साफ़ दिखता है, लेकिन 7 मिनट में investigation शुरू कर देना प्रभावशाली था

  • शुरुआत में इसे attack समझ लिया गया था। बाद में issue समझ में आ गया, लेकिन corrupted file को queue में replace करने का कोई तरीका नहीं था, और दुनिया भर की बड़ी संख्या में machines को restart करना पड़ा

• यह घटना CrowdStrike incident जैसी लगती है
  auto-generated configuration file ने software को खराब किया, और वह पूरे network में फैल गया
  यह समझ आता है कि fast deployment की ज़रूरत होती है, लेकिन इस घटना ने gradual rollout और rollback strategy की कमी दिखा दी

  • इसे CI/CD deployment की बजाय distributed bot detection system के control channel के रूप में देखना ज़्यादा सही होगा
  • simulator के बिना सीधे production में push कर देना चौंकाने वाला है
  • फिर भी उम्मीद है कि इस घटना के बाद सुधार होंगे

• Cloudflare द्वारा घोषित future improvement plans में,

  • Cloudflare-generated configuration files की validation मज़बूत करना
  • global kill switch जोड़ना
  • core dump या error reports की वजह से resource exhaustion रोकना
  • proxy module के error modes की समीक्षा
    जैसी बातें शामिल हैं
    लेकिन canary deployment या gradual config deployment इसमें नहीं है
    global switch जोखिमभरा हो सकता है, और एक bug से पूरा system रुक सकता है
  • bot management settings को तेज़ी से propagate होना चाहिए, लेकिन अगर पहले एक instance पर test किया गया होता, तो panic पहले पकड़ में आ जाता
    यह भी सवाल है कि ClickHouse को feature flag store के रूप में क्यों इस्तेमाल किया गया। ClickHouse deduplication docs में भी जोखिम बताए गए हैं
  • config service में gradual rollout था, लेकिन consuming services बहुत ज़्यादा बार auto-update हो रही थीं, इसलिए error का छोटा प्रतिशत भी पूरे सिस्टम को प्रभावित कर गया
  • global config तेज़ response के लिए उपयोगी है, लेकिन fast rollback system अनिवार्य है
    अगर services के बीच dependency mapping होती, तो root cause ढूँढना कहीं आसान होता
  • आखिरकार ज़्यादातर बड़े outages की वजह config push ही होते हैं
    code deployment सावधानी से होता है, लेकिन config deployment उतनी सावधानी से नहीं। यह समझना ज़रूरी है कि config भी code है

• status page के down हो जाने से इसे attack समझ लिया गया, यह हिस्सा दिलचस्प है
  कहा गया कि यह Cloudflare infrastructure से पूरी तरह अलग है, फिर भी यह साथ में क्यों गिर गया, इसकी कोई व्याख्या नहीं है

  • शायद traffic spike की वजह से infrastructure scale-up fail हुआ होगा
  • संभव है कि उन्हें लगा हो कि वास्तविक रूप से Cloudflare dependency नहीं है, लेकिन इंटरनेट का बड़ा हिस्सा CloudFront पर निर्भर होने के कारण यह पूरी तरह स्वतंत्र नहीं रहा हो
  • कारण जानने के लिए statuspage.io के postmortem की ज़रूरत होगी। यह Atlassian की service है
  • या फिर सिर्फ़ Cloudflare का scale इतना बड़ा था कि traffic उसी वजह से उमड़ पड़ा

• मैंने Turnstile को fail-open strategy के साथ integrate किया था, और इस outage में उसका फ़ायदा मिला
  अगर JS load नहीं होता, तो dummy token के साथ submit की अनुमति दी जाती है, और backend में validation fail होने पर भी fail-open की तरह handle किया जाता है
  कुछ users फिर भी block हुए, लेकिन कुल असर कम हुआ
  यह तरीका इसलिए संभव है क्योंकि दूसरी bot mitigation measures भी मौजूद हैं

  • तो सवाल उठता है कि अगर attacker script को block कर दे, तो क्या CAPTCHA bypass नहीं हो जाएगा?
    लेकिन लगता है कि यह केवल तब काम करेगा जब targeted attack न हो

• यह सवाल भी है कि Cloudflare code में .unwrap() की अनुमति क्यों थी
  कम से कम expect("यह कभी नहीं होगा") तो इस्तेमाल करना चाहिए था
  errors को values की तरह treat करने की philosophy ही ऐसी समस्याओं को रोकने के लिए है, और इससे diagnosis भी बहुत आसान हो जाता

  • मैं Cloudflare employee नहीं हूँ, लेकिन Rust काफ़ी इस्तेमाल करता हूँ
    network calls वाले code में failure की संभावनाएँ बहुत ज़्यादा होती हैं
    development के दौरान मैं .unwrap() इस्तेमाल करता हूँ, लेकिन production में कभी-कभी expect() छोड़ देता हूँ, क्योंकि कुछ स्थितियों में आगे बढ़ने का कोई रास्ता नहीं होता

• असली सबक यह है कि बहुत ज़्यादा features कुछ गिने-चुने players पर निर्भर हो गए हैं
  winner-takes-all ढांचा गहराता जा रहा है, और systems की resilience घट रही है
  बेशक उन्होंने यह जगह अपनी क्षमता से हासिल की है, लेकिन यह मान लेना कि इंटरनेट हमेशा “सामान्य रूप से काम” करेगा, कुछ ज़्यादा उम्मीद लगती है

• “Rust हो तो सब सुरक्षित है” जैसी बात बढ़ा-चढ़ाकर कही जाती है
  कोई भी language हो, गलत तरीके से इस्तेमाल करें तो वह अपनी ही टांग पर बंदूक तानने जैसा है

[barca105]

CF जितनी बड़ी कंपनी में भी .unwrap() इस्तेमाल होता है, वाह।
वो कोड आखिर production में कैसे लागू हो गया?

[skageektp]

लगता है कि समस्या unwrap नहीं है

[barca105]

मूल समस्या गलत query है।
लेकिन मुझे यह भी लगता है कि unwrap के साथ समस्या validation को छोड़ देना भी एक समस्या थी।
अंदरूनी तौर पर समस्या होती भी, अगर error handling की गई होती तो ट्रैफ़िक डाउन नहीं होता।