Cloudflare 5 दिसंबर 2025 की आउटेज

 (blog.cloudflare.com)
1 पॉइंट द्वारा GN⁺ 2025-12-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 5 दिसंबर 2025 को 08:47 UTC पर Cloudflare नेटवर्क के कुछ हिस्सों में गंभीर आउटेज हुआ और लगभग 25 मिनट बाद, यानी 09:12 UTC पर, इसे पूरी तरह ठीक कर दिया गया
  • कुल लगभग 28% HTTP ट्रैफिक प्रभावित हुआ, और केवल वे ग्राहक प्रभावित हुए जो कुछ विशिष्ट शर्तों को पूरा कर रहे थे
  • कारण था React Server Components कमजोरी (CVE-2025-55182) के लिए कार्रवाई के दौरान किया गया WAF (body parsing logic) परिवर्तन, जो किसी साइबर अटैक या दुर्भावनापूर्ण गतिविधि से जुड़ा नहीं था
  • FL1 proxy की कोड त्रुटि के कारण HTTP 500 errors आए, जबकि नए Rust आधारित FL2 proxy में यही त्रुटि नहीं दिखी
  • Cloudflare ने 18 नवंबर की आउटेज के बाद भी इसी तरह की समस्या दोबारा होने को स्वीकार किया और डिप्लॉयमेंट सेफ्टी व रेज़िलिएन्स बढ़ाने के प्रोजेक्ट को शीर्ष प्राथमिकता के रूप में आगे बढ़ा रहा है

आउटेज का अवलोकन

  • 5 दिसंबर 2025 को 08:47 UTC पर Cloudflare नेटवर्क के एक हिस्से में आउटेज हुआ
    • 09:12 UTC पर सभी सेवाएं बहाल हो गईं, कुल प्रभाव अवधि लगभग 25 मिनट रही
    • कुल HTTP ट्रैफिक का करीब 28% प्रभावित हुआ
  • आउटेज साइबर अटैक या किसी malicious action का नतीजा नहीं था; यह आंतरिक सेटिंग बदलाव के दौरान हुआ
  • React Server Components की नई कमजोरी को हैंडल करने के लिए किया गया WAF body parsing logic अपडेट इसका मूल कारण था

कारण और तकनीकी पृष्ठभूमि

  • Cloudflare WAF, malicious payloads खोजने के लिए HTTP request body को memory में buffer करता है
    • मौजूदा buffer आकार 128KB से बढ़ाकर 1MB किया जा रहा था
  • नया buffer size आंतरिक टेस्ट टूल के लिए समर्थित नहीं था, इसलिए दूसरा बदलाव कर टेस्ट टूल को disable किया गया
    • यह बदलाव global settings system के जरिए तुरंत सभी servers पर propagate किया गया
  • FL1 proxy में इस बदलाव ने error state उत्पन्न की, जिससे HTTP 500 responses आईं
    • error संदेश: attempt to index field 'execute' (a nil value)
  • समस्या तुरंत पहचान ली गई और 09:12 UTC पर बदलाव वापस ले लिया गया

प्रभाव का दायरा

  • केवल वही ग्राहक प्रभावित हुए जो FL1 proxy उपयोग कर रहे थे और जिन पर Cloudflare Managed Ruleset लागू था
    • उन साइटों पर सभी requests ने HTTP 500 error लौटाई
    • /cdn-cgi/trace जैसे कुछ टेस्ट endpoints इससे अपवाद थे
  • चीन नेटवर्क और अन्य कॉन्फ़िगरेशन वाले ग्राहकों पर कोई प्रभाव नहीं पड़ा

रनटाइम त्रुटि का विवरण

  • Cloudflare का rulesets सिस्टम प्रत्येक request पर rules evaluate करता है
    • एक rule में filter और action दोनों होते हैं, और execute action अन्य rule सेट को invoke करता है
  • आंतरिक logging सिस्टम execute का उपयोग करके टेस्ट rules evaluate करता है
  • killswitch सिस्टम गलत तरीके से काम कर रही rules को disable करने के लिए डिजाइन किया गया है, लेकिन
    • execute action वाले rules पर killswitch लगाने की यह पहली बार की घटना थी
  • जब execute object मौजूद नहीं था तब उसे access करने पर Lua error हुई
  • यह एक साधारण code bug था जो वर्षों से मौजूद था लेकिन पकड़ में नहीं आया
    • Rust में लिखे गए FL2 proxy में यह त्रुटि दोहराई नहीं गई

नवंबर 18 के बाद सुधार की स्थिति

  • 18 नवंबर को भी समान global deployment से व्यापक आउटेज हुआ था
  • उस समय कई सौ ग्राहकों से सीधे संवाद कर single-update blast radius को रोकने की योजना साझा की गई थी
  • यह सुधारात्मक काम अभी पूरा नहीं हुआ था, इसलिए इसका असर इस आउटेज में भी दिखा
  • Cloudflare ने इसे कंपनी स्तर पर टॉप-प्रायोरिटी मिशन घोषित किया है

चल रहे लचीलापन सुधार प्रोजेक्ट

  • Enhanced Rollouts & Versioning
    • threat-response data और configuration बदलावों पर भी gradual rollout, health validation और fast rollback लागू करना
  • Streamlined Break Glass Capabilities
    • internal services और control plane interactions के दौरान भी emergency override संभव बनाना
  • Fail-Open error handling
    • यदि config file में गलती हो तो request block न करके fallback default safe mode में जाना या traffic पास करना
    • कुछ सेवाओं के लिए fail-open / fail-closed विकल्प उपलब्ध कराने की योजना है
  • अगले एक सप्ताह के भीतर सभी resilience प्रोजेक्ट्स के detailed status updates सार्वजनिक किए जाएंगे
  • उस अवधि तक network बदलावों को lock/lockdown मोड में रोक कर रखा जाएगा

टाइमलाइन (UTC)

  • 08:47 – कॉन्फ़िगरेशन बदलाव deploy और network propagation शुरू
  • 08:48 – पूर्ण प्रभाव शुरू
  • 08:50 – automated alert के ज़रिए incident घोषित
  • 09:11 – बदलाव revert शुरू
  • 09:12 – पूर्ण recovery, सभी ट्रैफिक सामान्य

निष्कर्ष

  • Cloudflare ने लगातार दो outages की गंभीरता स्वीकार की और ग्राहकों तथा पूरी इंटरनेट कम्युनिटी से माफ़ी मांगी
  • आगे deployment safety, error tolerance और resilience बढ़ाकर ऐसे incidents रोकने की योजना पर काम करेगा

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-12-06
Hacker News की राय

  • इस Cloudflare आउटेज ने सिर्फ एक साधारण Lua बग नहीं, बल्कि एक बुनियादी आर्किटेक्चर समस्या को उजागर किया
    मूल distributed web संरचना ऐसे global outages के सामने कहीं ज़्यादा मज़बूत थी। इसके विपरीत Cloudflare जैसे एकरूप केंद्रीकृत सिस्टम में एक ही गलती से दुनिया भर की सेवाएँ एक साथ रुक सकती हैं। Rust में लिखा हो तब भी इंसान गलती करते हैं। आखिरकार मज़बूत डिज़ाइन ही सबसे अहम है

    • इसका मतलब यह है कि Cloudflare या AWS जैसे बड़े प्रदाताओं पर जितनी ज़्यादा निर्भरता होगी, web की स्थिरता उतनी कम होगी
    • “1,000 ततैया बनाम 1 कुत्ता” वाली उपमा की तरह, global outage हो या regional outage, दर्द का रूप बस अलग होता है। Cloudflare रुक जाए तो सैकड़ों engineers तुरंत प्रतिक्रिया देते हैं, लेकिन मेरा server बंद हो जाए तो ज़िम्मेदार व्यक्ति शायद पहाड़ों के किसी cabin में हो सकता है
    • monopoly खराब है या नहीं, यह बहस अलग है; लेकिन Cloudflare की दीर्घकालिक availability देखें तो यह अक्सर individual sites द्वारा अपनी infrastructure चलाने से बेहतर लगती है। उपयोगकर्ता के नज़रिए से सभी सेवाओं का एक साथ 1 घंटे रुकना, हर सेवा के अलग-अलग 1 घंटे रुकने से बेहतर माना जा सकता है। हालांकि अगर Cloudflare की स्थिरता औसत से नीचे चली जाए, तो उसका यह मूल्य खत्म हो जाता है
    • अगर पैमाना प्रति सेकंड 8 करोड़ requests संभालने का है, तो शायद एक ही प्रोडक्ट का इतना बड़ा हो जाना ही मूल समस्या है
    • Cloudflare अब भी दुनिया में कहीं भी सबसे तेज़ी से global infrastructure को recover करने वाली कंपनियों में से एक है। इस बार भी उसने 28% network outage को 25 मिनट में ठीक किया, और दूसरी cloud सेवाओं की तुलना में objectively कम downtime रहा है

  • कल रात कई sites पर Cloudflare 500 errors दिखे। लेकिन status page पर उसका कोई ज़िक्र नहीं था, सिर्फ scheduled maintenance की सूचना थी

    • ज़्यादातर status pages की तरह, असली समस्या पहचानने और update होने में समय लगता है। पूरी तरह automation होने तक Cloudflare भी अपवाद नहीं है। इससे ज़्यादा चिंता की बात यह है कि हाल में AWS, Azure, Cloudflare लगातार डाउन हुए हैं। मेरा अंदाज़ा है कि LLM उपयोग में बढ़ोतरी, स्टाफ की कमी, महामारी के असर, और राजनीतिक अस्थिरता जैसे कई कारण साथ काम कर रहे हैं
    • लगता है कि status page जैसी समस्याएँ सिर्फ सार्वजनिक आलोचना से ही सुधरेंगी। “Cloudflare को आउटेज detect करना भी ठीक से नहीं आता” जैसी प्रतिक्रिया ज़्यादा आनी चाहिए

  • लगता है Cloudflare की quality engineering प्रोडक्शन की रफ्तार का साथ नहीं दे पा रही

    • सुना है कि पहले defense industry में quality टीम हमेशा ज़्यादा अनुभवी होती थी, लेकिन software उद्योग में शायद उल्टा है
    • defense industry का एक किस्सा याद आता है, जहाँ memory leak पता होने के बावजूद यह कहकर अनदेखा किया गया कि “उपयोग समय के भीतर समस्या नहीं होगी”
    • अगर ऐसा एक महीने में दो बार हुआ है, तो यह “सराहने वाली बात” नहीं है। बार-बार होना किसी बहाने के लायक नहीं

  • इंटरनेट की packet switching संरचना मूल रूप से ऐसे global outages झेलने के लिए डिज़ाइन की गई थी
    Cold War के दौर में DARPA network का उद्देश्य परमाणु हमले की स्थिति में भी command structure बनाए रखना था।
    अब समय है कि इंटरनेट के local-first paradigm की ओर वापस लौटा जाए

  • हाल में लगता है Cloudflare इंटरनेट को और धीमा और असुविधाजनक बना रहा है। “साबित करें कि आप इंसान हैं” जैसी प्रक्रियाएँ बढ़ गई हैं, और page loading भी धीमी हुई है।
    यह site protection से ज़्यादा उसकी AI crawling billing policy की वजह लगती है (Pay-per-crawl परिचय)

    • ऐसी human verification प्रक्रियाएँ पुराने browsers के साथ compatible नहीं होतीं, इसलिए कुछ sites तक पहुँचना पूरी तरह असंभव हो जाता है
    • लेकिन AI द्वारा बिना अनुमति content scrape करना भी समस्या है। Cloudflare इस तरह site owners को content protection options दे रहा है, और चाहें तो इसे बंद भी किया जा सकता है
    • “अब ये हमें चुपचाप निगरानी भी नहीं कर पाएँगे” जैसी व्यंग्यात्मक प्रतिक्रिया भी आई

  • Cloudflare की global configuration system बिना gradual rollout के कुछ ही सेकंड में पूरे network में फैल जाती है, इसलिए यह जोखिम भरी है।
    configuration changes से गलती होने पर तुरंत correlation समझने वाली व्यवस्था होनी चाहिए

    • असली समस्या यह थी कि alert बहुत देर से आया। 2 मिनट में notification आया, जबकि detection seconds में होना चाहिए था।
      deployment का ज़िम्मेदार व्यक्ति real-time metrics देखते हुए तुरंत rollback button दबा देना चाहिए था।
      logs में code line तक साफ़ दिख रही थी, लेकिन deployment team और code को समझने वाली team के बीच शायद disconnect था
    • warning signal देखकर rollback की कोशिश की गई, लेकिन लगता है उसी प्रक्रिया ने उल्टा समस्या पैदा कर दी
    • internal tools में अक्सर false positives बहुत होते हैं, और कई बार वे खुद भी टूटे हुए होते हैं
    • यह उस मज़ाक जैसा लगता है: “engine warning light बार-बार जल रही थी, तो हमने bulb ही निकाल दिया”

  • Cloudflare की availability 99.9% से नीचे चली गई है। यह तो मेरे घर के PC से भी खराब है

    • AWS का भी यही हाल है। अगर cloud का मतलब “ज़्यादा availability” है, और वह महँगा भी हो और अस्थिर भी, तो self-hosting के लिए पर्याप्त वजह है
    • लेकिन self-hosting में hardware failure या backup failure होने पर recovery में कई दिन लग सकते हैं
    • जहाँ regional power outages आम हैं, वहाँ laptop और battery के सहारे टिके रहना भी मुश्किल है। कभी-कभी self-sufficient infrastructure का सपना आता है
    • जानना चाहता हूँ कि Cloudflare के मौजूदा uptime statistics ठीक-ठीक कहाँ देखे जा सकते हैं
    • फिर भी personal PC और Cloudflare की सीधी तुलना करना बेमानी उपमा है

  • Cloudflare के पैमाने पर test environment होना अनिवार्य है।
    हर बदलाव को isolated model environment में simulation के बाद धीरे-धीरे deploy करना चाहिए।
    strong type systems से ज़्यादा महत्वपूर्ण हैं procedural safety rails

    • हमारी कंपनी तीन-चरण deployment system इस्तेमाल करती है: development → internal integration → production।
      जिन teams से गलतियाँ ज़्यादा होती हैं, उनकी गति धीमी रखी जाती है, और जिनकी reliability अधिक है, वे तेज़ी से आगे बढ़ती हैं।
      आखिरकार तकनीकी गति भी एक choice है। अगर SLA को खतरा हो, तो गति कम करके testing बढ़ानी चाहिए
    • free users को test bed की तरह इस्तेमाल करना, और paid customers को stable version देना भी एक तरीका हो सकता है
    • “strong type system तुम्हें बचा नहीं सकता” का मतलब है कि procedural failure के सामने language की शक्ति भी बेअसर हो जाती है

  • लगता है Cloudflare की software quality डगमगा रही है।
    enterprise-only feature की access validation सिर्फ अंतिम चरण में होने वाला bug भी था

    • मैंने भी Cloudflare API में ऐसी settings देखी हैं जिन्हें rollback नहीं किया जा सकता था।
      support team के जरिए ही बदलाव संभव था, और उसे ठीक करने में कई दिन लगे
      संबंधित उदाहरण लिंक
    • मुझे लगता है ऐसे bugs शायद AI द्वारा लिखे गए code से भी आए हो सकते हैं
    • “सिर्फ अंतिम चरण में check होता है” से उनका क्या मतलब है, इसे और विस्तार से सुनना चाहूँगा

  • Cloudflare की operational culture को लेकर जिज्ञासा है।
    security issue के जवाब में गलती हुई, लेकिन rollback की जगह फिर से global deployment किया गया, यह जोखिम भरा फैसला लगता है।
    यह “संदेह हो तो rollback करो” जैसे बुनियादी सिद्धांत के खिलाफ है

    • हालांकि इस बार मामला React Server RCE vulnerability के response जैसा urgent था।
      deployment में देरी होती तो customers वास्तव में hack हो सकते थे, इसलिए यह ऐसा मामला था जहाँ speed ही security थी
    • rollback हमेशा सही जवाब नहीं होता। अगर process की आदत न हो, तो वही खुद एक risk बन जाता है
    • वास्तव में दोनों deployments अलग-अलग components के लिए थे।
      पहले fix ने दूसरे के latent bug को सामने ला दिया, इसलिए कभी-कभी rollback से ज़्यादा roll forward व्यावहारिक होता है
    • Cloudflare ने तेज़ growth के दौरान काफी technical debt जमा किया होगा।
      हाल के बार-बार के outages शायद उसी debt के सामने आने का संकेत हैं