في 18 نوفمبر 2025 في الساعة 11:20 بالتوقيت العالمي ، بدأت شبكة Cloudflare تعاني من فشل كبير في توصيل حركة مرور الشبكة الأساسية.  يظهر هذا لمستخدمي الإنترنت الذين يحاولون الوصول إلى مواقع عملائنا كصفحة خطأ تشير إلى فشل في شبكة Cloudflare.

لم تكن المشكلة ناجمة، بشكل مباشر أو غير مباشر، عن هجوم إلكتروني أو نشاط ضار من أي نوع.  وبدلا من ذلك، تم تشغيله عن طريق تغيير في أحد أذونات أنظمة قواعد البيانات لديها مما تسبب في إخراج قاعدة البيانات إدخالات متعددة في “ملف الاعدادات” الذي يستخدمه نظام إدارة البوت.  هذا الملف، بدوره، تضاعف في الحجم.  ثم تم نشر ملف الأكبر من المتوقع إلى جميع الأجهزة التي تشكل الشبكة.

هذا الملف الذي يتم تشغيله على هذه الأجهزة بتوجيه حركة المرور عبر الشبكة الخاصة ب Cloudflare بقراءة ملف الميزات هذا للحفاظ على تحديث نظام إدارة بوت الخاص بنا مع التهديدات المتغيرة باستمرار.  كان للبرنامج حد أقصى لحجم ملف الميزات الذي كان أقل من حجمه المزدوج.  مما تسبب في فشل التشغيل.

بعد أن اشتبهو بالخطأ في بداية الامر أنه  هجوم DDoS واسع على Cloudflare، حددو المشكلة الأساسية بشكل صحيح وتمكنو من إيقاف انتشار الملف ومن المتوقع واستبداله بإصدار سابق من الملف.  كانت حركة المرور الأساسية تتدفق إلى حد كبير كالمعتاد بحلول الساعة 14:30. عملو على مدى الساعات القليلة التالية لهذا التوقيت على تخفيف الحمل المتزايد على أجزاء مختلفة من الشبكة مع عودة حركة المرور إلى الإنترنت.  اعتبارا من عام 17:06 كانت جميع الأنظمة في Cloudflare تعمل كالمعتاد.

نعتذر عن تأثر عملائنا وعلى الإنترنت بشكل عام.  نظرا لأهميةو Cloudflare في النظام البيئي للإنترنت فإن أي انقطاع في أي من أنظمتنا غير مقبول.  أن تكون هناك فترة من الوقت حيث لم تكن الشبكة قادرة على توجيه حركة المرور أمر مؤلم للغاية لكل عضو في فريقنا.  نحن نعلم أننا خذلناك اليوم.

هذا المقال هو إعادة توضيح عميقة لما حدث بالضبط وما فشلت فيه الأنظمة والعمليات.  وهي أيضا البداية، وإن لم تكن النهاية، لما نخطط للقيام به من أجل التأكد من عدم حدوث انقطاع كهذا مرة أخرى.

انقطاع التيار الكهربائي

يوضح الرسم البياني أدناه حجم رموز حالة HTTP لخطأ 5xx التي تخدمها شبكة Cloudflare.  عادة، يجب أن يكون هذا منخفضا جدا، وكان ذلك صحيحا حتى بداية الانقطاع.

الحجم قبل 11:20 هو خط الأساس المتوقع لأخطاء 5xx التي تمت ملاحظتها عبر شبكتنا.  يظهر الارتفاع المفاجئ والتقلبات اللاحقة فشل النظام بسبب تحميل الملف غير الصحيح.  والملفت للنظر هنا هو أن النظام سوف يتعافى لفترة من الوقت.  كان هذا سلوكا غير اعتيادي بسبب خطأ داخلي.

استمرت الأخطاء حتى تم تحديد المشكلة الأساسية وحلها بدءا من الساعة 14:30. لقد تم حل المشكلة عن طريق إيقاف إنشاء الملفات وتبديله بملف جديد في قائمة انتظار توزيع ملفات الميزات.  ومن ثم فرض إعادة تشغيل الأساسي.

أما الذيل الطويل المتبقي في الرسم البياني أعلاه فهو أن فريقنا يعيد تشغيل الخدمات المتبقية التي دخلت في حالة سيئة، مع عودة حجم رمز الخطأ 5xx إلى الوضع الطبيعي عند الساعة 17:06.

وقد تأثرت الخدمات التالية:

الخدمة/ المنتج	وصف التأثير
CDN وخدمات الأمان الأساسية	رموز حالة HTTP 5xx.  تعرض لقطة الشاشة في أعلى هذا المنشور صفحة خطأ نموذجية يتم تسليمها إلى المستخدمين النهائيين.
Turnstile	فشل تحميل الباب الدوار.
كيلو فولت للعمال	إرجاع kV للعمال مستوى مرتفع بشكل ملحوظ من أخطاء HTTP 5xx مع فشل الطلبات إلى بوابة “الواجهة الأمامية” لـ kV بسبب فشل الوكيل الأساسي.
Dashboard	بينما كانت لوحة المعلومات تعمل في الغالب، لم يتمكن معظم المستخدمين من تسجيل الدخول بسبب عدم توفر Turnstile على صفحة تسجيل الدخول.
أمان البريد الإلكتروني	على الرغم من أن معالجة البريد الإلكتروني وتسليمه لم يتأثرا، إلا أننا لاحظنا فقدانا مؤقتا للوصول إلى مصدر سمعة IP مما أدى إلى انخفاض دقة اكتشاف البريد العشوائي ومنع بعض عمليات اكتشاف المجال الجديد من التشغيل، مع عدم ملاحظة أي تأثير مهم على العملاء.  رأينا أيضا إخفاقات في بعض إجراءات Auto Move (النقل التلقائي)؛  تمت مراجعة كل الرسائل المتأثرة ومعالجتها.
Access (الوصول)	كانت حالات فشل المصادقة واسعة الانتشار بالنسبة لمعظم المستخدمين، بدءا من بداية الحادث وحتى بدء التراجع في الساعة 13:05. لم تتأثر أي جلسات وصول موجودة. أدت كل محاولات المصادقة الفاشلة إلى ظهور صفحة خطأ، مما يعني أن أيا من هؤلاء المستخدمين لم يصل إلى التطبيق المستهدف أثناء فشل المصادقة.  تم تسجيل تسجيلات الدخول الناجحة خلال هذه الفترة بشكل صحيح أثناء هذه الحادثة. أي تحديثات تكوين Access تمت محاولتها في ذلك الوقت إما أن تفشل بشكل مباشر أو يتم نشرها ببطء شديد.  يتم الآن استرداد جميع تحديثات التكوين.

بالإضافة إلى إرجاع أخطاء HTTP 5xx، لاحظنا زيادة كبيرة في زمن الاستجابة من CDN خلال فترة التأثير.  كان هذا بسبب استهلاك كميات كبيرة من وحدة المعالجة المركزية من قبل أنظمة التصحيح والمراقبة لدينا، والتي تعمل تلقائيا على تحسين الأخطاء غير المكتشفة مع معلومات تصحيح إضافية.

كيف تعالج Cloudflare الطلبات، وكيف حدث خطأ اليوم

كل طلب إلى Cloudflare يأخذ مسارا محددا جيدا عبر الشبكة.  يمكن أن يكون من متصفح يقوم بتحميل صفحة ويب، أو تطبيق جوال يتصل بواجهة برمجة تطبيقات، أو حركة مرور تلقائية من خدمة أخرى.  تنتهي هذه الطلبات أولا عند طبقة HTTP وTLS، ثم تتدفق إلى نظام الوكيل الأساسي (الذي نسميه FL لـ “Frontline”)، وأخيرا من خلال Pingora، الذي يجري عمليات بحث في ذاكرة التخزين المؤقت أو يجلب البيانات من الأصل إذا لزم الأمر.

شاركنا سابقا المزيد من التفاصيل حول كيفية عمل الوكيل الأساسي.

عند نقل الطلب للوكيل الأساسي، نقوم بتشغيل منتجات الأمان والأداء المتنوعة المتوفرة في شبكتنا.  يطبق الوكيل التكوين والإعدادات الفريدة لكل عميل، من فرض قواعد WAF وحماية DDoS إلى توجيه حركة المرور إلى منصة المطور وR2. وهي تحقق ذلك من خلال مجموعة من الوحدات النمطية الخاصة بالمجال والتي تطبق قواعد التكوين والسياسة على حركة المرور التي تعبر الوكيل.

واحدة من هذه الوحدات، إدارة بوت، كانت مصدر انقطاع اليوم.

تتضمن إدارة بوت Cloudflare، من بين أنظمة أخرى، نموذجا للتعلم الآلي نستخدمه لتوليد درجات بوت لكل طلب يعبر شبكتنا.  يستخدم عملاؤنا درجات البوت للتحكم في برامج الروبوت المسموح لها بالوصول إلى مواقعهم — أو لا.

يأخذ النموذج ملف تكوين “ميزة” كمدخل.  الميزة، في هذا السياق، هي سمة فردية يستخدمها نموذج التعلم الآلي للتنبؤ بما إذا كان الطلب آليا أم لا.  ملف تكوين الميزات عبارة عن مجموعة من الميزات الفردية.

يتم تحديث ملف الميزات هذا كل بضع دقائق ويتم نشره على شبكتنا بالكامل ويسمح لنا بالتفاعل مع التغيرات في تدفقات حركة المرور عبر الإنترنت.  إنها تسمح لنا بالتفاعل مع أنواع جديدة من الروبوتات وهجمات الروبوتات الجديدة.  لذا فمن الأهمية بمكان أن يتم نشر هذا البرنامج بشكل متكرر وسريع مع تغيير الجهات الفاعلة السيئة بسرعة.

أدى التغيير الذي طرأ على سلوك الاستعلام الأساسي الخاص بـ ClickHouse (الموضح أدناه) والذي يؤدي إلى إنشاء هذا الملف إلى احتوائه على عدد كبير من صفوف “الميزات” المكررة.  أدى ذلك إلى تغيير حجم ملف تكوين ميزة الحجم الثابت سابقا، مما تسبب في تشغيل وحدة برامج الروبوت الفرعية لخطأ.

ونتيجة لذلك، تم إرجاع رموز خطأ HTTP 5xx بواسطة نظام الوكيل الأساسي الذي يتعامل مع معالجة حركة المرور لعملائنا، لأي حركة مرور تعتمد على وحدة الروبوتات.  كما أثر هذا أيضا على kV وAccess العاملين، اللذين يعتمدان على الوكيل الأساسي.

في ما يتعلق بهذه الحادثة، كنا وما زلنا نقوم حاليا بترحيل حركة مرور العملاء إلى إصدار جديد من خدمة الوكيل، المعروفة داخليا باسم . وقد تأثر كلا الإصدارين بالمشكلة، على الرغم من أن التأثير الذي لوحظ كان مختلفا.

لاحظ العملاء الذين تم نشرهم على محرك الوكيل FL2 الجديد أخطاء HTTP 5xx.  لم ير العملاء على محرك الوكيل القديم، المعروف باسم FL، أخطاء، ولكن لم يتم إنشاء نقاط البوت بشكل صحيح، مما أدى إلى حصول جميع الزيارات على درجة صفر.  كان العملاء الذين لديهم قواعد تم نشرها لمنع الروبوتات ليشهدوا أعدادا كبيرة من الإيجابيات الكاذبة.  لم يلاحظ العملاء الذين لم يستخدموا درجة البوت في قواعدهم أي تأثير.

كان إلقاء بنا وجعلنا نعتقد أن هذا قد يكون هجوما عرضا واضحا آخر لاحظناه: انخفضت صفحة حالة Cloudflare.  تتم استضافة صفحة الحالة بالكامل خارج البنية الأساسية لـ Cloudflare دون أي اعتماد على Cloudflare.  وعلى الرغم من أن الأمر كان من قبيل المصادفة، إلا أنه دفع بعض أعضاء الفريق الذين قاموا بتشخيص المشكلة إلى الاعتقاد بأن أحد المهاجمين قد يستهدف أنظمتنا وصفحة الحالة الخاصة بنا.  تم استقبال زائري صفحة الحالة في ذلك الوقت برسالة خطأ:

في غرفة محادثة الحوادث الداخلية، كنا قلقين من أن يكون هذا استمرارا للموجة الأخيرة من   هجمات Aisuru DDoS الضخمة:

يتغير سلوك الاستعلام

لقد ذكرت أعلاه أن التغيير في سلوك الاستعلام الأساسي أدى إلى احتواء ملف الميزات على عدد كبير من الصفوف المكررة.  يستخدم نظام قاعدة البيانات المعني برنامج ClickHouse.

بالنسبة للسياق، من المفيد معرفة كيفية عمل الاستعلامات الموزعة على ClickHouse.  تتكون مجموعة ClickHouse من العديد من القطع.  للاستعلام عن البيانات من كافة القطع، لدينا ما يسمى الجداول الموزعة (مشغل بواسطة مشغل الجدول  الموزع) في قاعدة بيانات تسمى  افتراضي.  يستعلم المحرك الموزع عن الجداول الأساسية في قاعدة البيانات  R0. الجداول الأساسية هي حيث يتم تخزين البيانات على كل قطعة من مجموعة ClickHouse.

يتم تشغيل الاستعلامات إلى الجداول الموزعة عبر حساب نظام مشترك.  كجزء من الجهود المبذولة لتحسين أمان الاستعلامات الموزعة وموثوقيتها، هناك عمل جار لجعلها تعمل ضمن حسابات المستخدمين الأولية بدلا من ذلك.

قبل اليوم، كان مستخدمو ClickHouse يشاهدون الجداول الموجودة في   قاعدة البيانات الافتراضية فقط عند الاستعلام عن بيانات تعريف الجدول من جداول نظام ClickHouse مثل  system.tables  أو system .columns.

نظرا لأن المستخدمين لديهم بالفعل حق وصول ضمني إلى الجداول الأساسية في  R0، فقد أجرينا تغييرا على 11:05 لجعل هذا الوصول واضحا، بحيث يمكن للمستخدمين رؤية بيانات التعريف الخاصة بهذه الجداول أيضا.  من خلال التأكد من إمكانية تشغيل كافة الاستعلامات الفرعية الموزعة ضمن المستخدم الأولي، يمكن تقييم حدود الاستعلام ومنح الوصول بطريقة أكثر دقة، مع تجنب استعلام فرعي سيئ من مستخدم يؤثر على الآخرين.

أدى التغيير الموضح أعلاه إلى وصول جميع المستخدمين إلى بيانات تعريف دقيقة حول الجداول التي يمكنهم الوصول إليها. لسوء الحظ، كانت هناك افتراضات في الماضي، مفادها أن قائمة الأعمدة التي يرجعها استعلام كهذا ستتضمن قاعدة البيانات “الافتراضية” فقط:

حدد الاسم، واكتب من system.columns حيث الجدول = ‘http_requests_features’ ترتيب بالاسم؛

لاحظ كيف لا يقوم الاستعلام بتصفية اسم قاعدة البيانات.  مع طرح المنح الصريحة تدريجيا لمستخدمي مجموعة ClickHouse معينة، بعد التغيير في 11:05 بدأ الاستعلام أعلاه بإرجاع “تكرارات” الأعمدة لأن هذه كانت للجداول الأساسية المخزنة في قاعدة بيانات R0.

لسوء الحظ، كان هذا هو نوع الاستعلام الذي تم إجراؤه بواسطة منطق إنشاء ملف ميزة إدارة بوت لإنشاء كل “ميزة” إدخال للملف المذكور في بداية هذا القسم.

سيرجع الاستعلام أعلاه جدول أعمدة مثل ذلك المعروض (مثال مبسط):

ومع ذلك، وكجزء من الأذونات الإضافية التي تم منحها للمستخدم، تحتوي الاستجابة الآن على جميع البيانات الوصفية   لمخطط R0 بشكل فعال أكثر من مضاعفة الصفوف في الاستجابة التي تؤثر في النهاية على عدد الصفوف (أي الميزات) في إخراج الملف النهائي.

التخصيص المسبق للذاكرة

كل وحدة تعمل على خدمة الوكيل لديها عدد من القيود المعمول بها لتجنب استهلاك الذاكرة غير المحدود وتخصيص الذاكرة مسبقا لتحسين الأداء.  في هذه الحالة المحددة، يكون لنظام إدارة البوت حد أقصى لعدد ميزات تعلم الآلة التي يمكن استخدامها في وقت التشغيل.  تم تعيين هذا الحد حاليا إلى 200، أي أعلى بكثير من استخدامنا الحالي للميزات التي يبلغ عددها 60 تقريبا.  مرة أخرى، يوجد الحد لأنه لأسباب تتعلق بالأداء نقوم بتخصيص الذاكرة مسبقا للميزات.

عندما تم نشر الملف السيئ الذي يحتوي على أكثر من 200 ميزة إلى خوادمنا، تم الوصول إلى هذا الحد – مما أدى إلى إصابة النظام بالذعر.  يظهر أدناه كود الصدأ FL2 الذي يقوم بالفحص والذي كان مصدر الخطأ الذي لم تتم معالجته:

أدى ذلك إلى الذعر التالي الذي أدى بدوره إلى خطأ 5xx:

Thread fl2_worker_thread farised: called result::unwrap() على قيمة Err

تأثير آخر أثناء الحادث

تأثرت الأنظمة الأخرى التي تعتمد على وكيلنا الأساسي أثناء الحادث.  وشمل ذلك وصول العمال إلى KV و Cloudflare.  تمكن الفريق من تقليل التأثير على هذه الأنظمة عند الساعة 13:04، عندما تم إجراء تصحيح للعاملين kV لتجاوز الوكيل الأساسي.  وفي وقت لاحق، لاحظت جميع أنظمة النقل التي تعتمد على kV الخاصة بالعمال (مثل Access نفسه) انخفاض معدل الخطأ.

كما تأثرت لوحة معلومات Cloudflare بسبب استخدام كل من العاملين kV داخليا ونشر Cloudflare Turnstile كجزء من تدفق تسجيل الدخول.

تأثر الباب الدوار بهذا الانقطاع، مما أدى إلى عدم تمكن العملاء الذين لم يكن لديهم جلسة لوحة معلومات نشطة من تسجيل الدخول. وقد ظهر هذا كانخفاض في التوافر خلال فترتين زمنيتين: من 11:30 إلى 13:10، وبين 14:40 إلى 15:30، كما هو موضح في الرسم البياني أدناه.

كانت الفترة الأولى، من 11:30 إلى 13:10، بسبب التأثير على العمال kV، والتي تعتمد عليها بعض وظائف لوحة التحكم ولوحة القيادة.  تمت استعادة هذا في الساعة 13:10، عندما تجاوز العمال kV نظام الوكيل الأساسي.  حدثت فترة التأثير الثانية على لوحة المعلومات بعد استعادة بيانات تكوين الميزة.  بدأت محاولات تسجيل الدخول المتراكمة تطغى على لوحة المعلومات.  أدت هذه الأعمال المتراكمة، بالإضافة إلى محاولات إعادة المحاولة، إلى زيادة زمن الانتقال، مما يقلل من توفر لوحة المعلومات.  تزامن مستوى التحكم في التوسع مع استعادة التوفر عند الساعة 15:30 تقريبا.

خطوات المعالجة والمتابعة

الآن بعد أن عادت أنظمتنا إلى الإنترنت وتعمل بشكل طبيعي، بدأ العمل بالفعل على كيفية تشديدها ضد إخفاقات كهذه في المستقبل.  نحن على وجه الخصوص:

• تصلب استيعاب ملفات التكوين التي تم إنشاؤها بواسطة Cloudflare بنفس الطريقة التي نتعامل بها مع المدخلات التي تم إنشاؤها بواسطة المستخدم
• تمكين المزيد من مفاتيح القتل العمومية للميزات
• القضاء على قدرة عمليات التفريغ الأساسية أو تقارير الأخطاء الأخرى على تجاوز موارد النظام
• مراجعة أوضاع الفشل بحثا عن حالات الخطأ عبر جميع وحدات الوكيل الأساسية

كان اليوم أسوأ انقطاع في Cloudflare  منذ عام 2019.  كان لدينا انقطاع في العمل مما جعل  لوحة المعلومات غير متوفرة.  بعضها تسبب في   عدم توفر ميزات أحدث لفترة من الوقت.  ولكن في السنوات الـ 6 الماضية لم يكن لدينا انقطاع آخر تسبب في توقف غالبية حركة المرور الأساسية عن التدفق عبر شبكتنا.

انقطاع مثل هذا اليوم غير مقبول.  لقد صممنا أنظمتنا لتكون عالية المرونة في مواجهة الفشل لضمان استمرار تدفق حركة المرور دائما.  عندما كان لدينا انقطاع في الماضي كان دائما يقودنا لبناء أنظمة جديدة أكثر مرونة.

بالنيابة عن الفريق بأكمله في Cloudflare، أود أن أعتذر عن الألم الذي سببناه للإنترنت اليوم.

الوقت (UTC)	الحالة	الوصف
11:05	Normal.	تم نشر تغيير عنصر تحكم الوصول إلى قاعدة البيانات.
11:28	يبدأ التأثير.	يصل النشر إلى بيئات العملاء، حيث تتم ملاحظة الأخطاء الأولى على نقل بيانات HTTP للعميل.
11:32-13:05	حقق الفريق في مستويات حركة المرور المرتفعة والأخطاء في خدمة kV للعاملين.	يبدو أن العرض الأولي كان انخفاض معدل استجابة kV للعمال مما تسبب في تأثير سلبي على خدمات Cloudflare الأخرى. تمت محاولة التخفيف مثل التلاعب بحركة المرور والحد من الحساب لإعادة خدمة kV للعمال إلى مستويات التشغيل العادية. اكتشف الاختبار الآلي الأول المشكلة في الساعة 11:31 وبدأ التحقيق اليدوي في الساعة 11:32. تم إنشاء مكالمة الحادث في الساعة 11:35.
13:05	تم تنفيذ تجاوز الوصول kV وCloudflare للعمال – تم تقليل التأثير.	أثناء التحقيق، استخدمنا طرق تجاوز النظام الداخلية للوصول إلى kV و Cloudflare للعمال حتى يعودوا إلى إصدار سابق من الوكيل الأساسي.  على الرغم من أن المشكلة كانت موجودة أيضا في الإصدارات السابقة من الوكيل، إلا أن التأثير كان أصغر كما هو موضح أدناه.
13:37	ركز العمل على إرجاع ملف تكوين Bot Management إلى آخر إصدار معروف.	كنا على ثقة من أن ملف تكوين Bot Management كان السبب وراء الحادث.  عملت الفرق على طرق لإصلاح الخدمة في مسارات عمل متعددة، مع أسرع مسار عمل هو استعادة إصدار سابق من الملف.
14:24	إيقاف إنشاء ملفات تكوين Bot Management الجديدة ونشرها.	حددنا أن وحدة إدارة البوت كانت مصدر أخطاء 500 وأن هذا كان بسبب ملف تهيئة سيء.  أوقفنا النشر التلقائي لملفات تكوين إدارة بوت الجديدة.
14:24	اكتمل اختبار الملف الجديد.	لاحظنا عملية استرداد ناجحة باستخدام الإصدار القديم من ملف التكوين ثم ركزنا على تسريع عملية الإصلاح بشكل عام.
14:30	تم حل التأثير الرئيسي.  بدأت الخدمات المتأثرة في مرحلة ما بعد النقل تلاحظ انخفاضا في الأخطاء.	تم نشر ملف تكوين Bot Management صحيح بشكل عام وبدأت معظم الخدمات تعمل بشكل صحيح.
17:06	تم حل جميع الخدمات.  ينتهي التأثير.	تمت إعادة تشغيل جميع خدمات النقل إلى الخارج واستعادة جميع العمليات بالكامل.