در تاریخ 18 نوامبر 2025 ساعت 11:20 UTC، شبکه Cloudflare شروع به تجربهٔ خطاهای گسترده در تحویل ترافیک اصلی کرد که کاربران اینترنت هنگام مراجعه به سایتهای مشتریان ما با صفحهٔ خطایی مواجه میشدند که نشاندهندهٔ اشکال در شبکهٔ Cloudflare بود. ⚠️
این اختلال ناشی از حملهٔ سایبری یا فعالیت مخرب نبود. مشکل از تغییر در دسترسیهای یکی از سیستمهای پایگاهدادهٔ ما آغاز شد که باعث شد آن پایگاهداده تعداد زیادی رکورد تکراری را در یک فایل پیکربندی «feature file» تولید کند که برای سیستم Bot Management استفاده میشود. نتیجهٔ این تغییر، دو برابر شدن اندازهٔ آن feature file بود و فایل بزرگتر به تمام ماشینهای شبکهٔ ما منتشر شد.
نرمافزاری که روی این ماشینها برای مسیردهی ترافیک اجرا میشود مرتباً آن feature file را میخواند تا Bot Management را با تهدیدهای جدید بهروز نگه دارد. آن نرمافزار محدودیتی روی اندازهٔ فایل داشت که پایینتر از اندازهٔ دوبرابر شده بود و همین باعث شکست آن شد.
در ابتدا برخی از علائم را به اشتباه به یک حملهٔ hyper-scale DDoS نسبت دادیم، اما بعداً علت اصلی را شناسایی کردیم: انتشار فایل feature فایل بزرگتر از حد انتظار. توانستیم این انتشار را متوقف کنیم و فایل را با نسخهٔ قبلی جایگزین کنیم. ترافیک اصلی تا حدود ساعت 14:30 بهطور عمده به حالت عادی بازگشت و در چند ساعت بعد برای کاهش بار افزایش یافتهٔ بخشهایی از شبکه کار کردیم. در نهایت تا ساعت 17:06 تمامی سیستمها به حالت عادی برگشتند. 🙏
از تأثیر این اختلال بر مشتریان و اینترنت عذرخواهی میکنیم. با توجه به اهمیت Cloudflare در اکوسیستم اینترنت، هر اختلالی در سیستمهای ما غیرقابل قبول است و برای تمام تیم ما این تجربه بسیار دردناک بود. این گزارش جزئیاتی از آنچه رخ داده و شکستهای سیستمها و فرآیندها را توضیح میدهد و شروع برنامههایی است که برای جلوگیری از تکرار چنین حادثهای در پیش گرفتهایم.
نمودار زیر حجم کدهای وضعیت HTTP 5xx که توسط شبکهٔ Cloudflare سرو شده را نشان میدهد. در شرایط عادی این مقدار باید بسیار پایین باشد و دقیقاً تا شروع اختلال نیز همینطور بود. 📈
حجم قبل از ساعت 11:20 همان خط مبنای مورد انتظار 5xx در شبکه است. جهش و نوسانات بعدی نشاندهندهٔ شکست سیستم بهخاطر بارگذاری فایل feature نادرست است. نکتهٔ قابل توجه این بود که سیستم گاهی بازیابی میشد و سپس دوباره سقوط میکرد؛ رفتاری که برای یک خطای داخلی غیرمعمول بود.
توضیح این نوسان این است که فایل هر پنج دقیقه توسط یک query روی یک خوشهٔ ClickHouse تولید میشد؛ خوشهای که بهطور تدریجی برای بهبود مدیریت permissions بهروز میشد. دادههای بد فقط زمانی ایجاد میشد که query روی بخشی از خوشه اجرا میشد که قبلاً بهروز شده بود. بنابراین هر پنج دقیقه شانس تولید مجموعهٔ صحیح یا ناصحیح فایلهای پیکربندی وجود داشت و آنها سریع در سراسر شبکه منتشر میشدند.
این نوسان تشخیص مشکل را سخت کرد، چون گاهی فایل خوب، گاهی فایل بد منتشر میشد و سیستم بهطور متناوب بازیابی و سپس دوباره دچار مشکل میشد. در نهایت همهٔ گرههای ClickHouse فایل خطا را تولید کردند و وضعیت بهصورت پایدار در حالت خطا قرار گرفت. خطاها تا زمانی که مشکل پایهای شناسایی و از ساعت 14:30 شروع به حل شد ادامه داشت.
راهحل این بود که تولید و انتشار فایل feature خراب را متوقف کنیم و بهصورت دستی یک فایل معتبر را در صف توزیع فایلهای feature قرار دهیم و سپس proxy هستهای را مجبور به راهاندازی مجدد کنیم. دماغهٔ طولانیترِ نمودار بازتاب راهاندازی مجدد سرویسهایی است که وارد حالت بد شده بودند و در نهایت حجم خطاهای 5xx در ساعت 17:06 به حالت عادی برگشت.
سرویسها و محصولات آسیبدیده شامل موارد زیر بودند:
– Core CDN and security services: بازگشت کدهای وضعیت HTTP 5xx؛ تصویری که در ابتدای پست میبینید صفحهٔ خطای معمولی را نشان میدهد.
– Turnstile: بارگذاری Turnstile موفقیتآمیز نبود.
– Workers KV: سطح قابل توجهی از خطاهای HTTP 5xx بازگشت، چون درخواستها به درگاه «front end» KV بهخاطر شکست proxy هستهای با خطا روبهرو شدند.
– Dashboard: در حالی که داشبورد تا حدی کار میکرد، اکثر کاربران بهدلیل در دسترس نبودن Turnstile در صفحهٔ ورود، قادر به لاگین نبودند.
– Email Security: پردازش و تحویل ایمیلها تحت تأثیر قرار نگرفت، اما دسترسی موقت به یک منبع شهرت IP از دست رفت که دقت تشخیص اسپم را کاهش داد و برخی از تشخیصهای مبتنی بر سن دامنه را غیرفعال کرد؛ هیچ تأثیر بحرانی روی مشتریان مشاهده نشد. همچنین برخی از Auto Moveها دچار خطا شدند که همهٔ پیامهای متاثر بررسی و اصلاح شدند.
– Access: شکستهای احراز هویت برای اکثر کاربران گسترده بود، از آغاز حادثه تا زمانی که rollback در ساعت 13:05 شروع شد. جلسههای Access موجود تحت تأثیر قرار نگرفتند.
تمام تلاشهای ناموفق برای احراز هویت باعث نمایش صفحهٔ خطا شد؛ یعنی هیچیک از این کاربران در زمان خرابی به هدف واقعی (target application) نرسیدند. لاگ رویدادهای لاگین موفق در طول این حادثه بهدرستی ثبت شدند. هر بهروزرسانی پیکربندی Access در آن زمان یا کاملاً شکست میخورد یا خیلی کند منتشر میشد؛ اکنون تمام بهروزرسانیها بازیابی شدهاند.
علاوه بر بازگشت 5xx، در طول دورهٔ اختلال تأخیر پاسخ CDN ما نیز بهطور قابل توجهی افزایش یافت. این افزایش تا حدی ناشی از مصرف زیاد CPU توسط سیستمهای debugging و observability ما بود که بهطور خودکار اطلاعات اشکالزدایی اضافی را برای خطاهای ثبتنشده جمعآوری میکردند.
چگونگی پردازش درخواستها در Cloudflare و علت خطا
هر درخواستی که به Cloudflare میرسد یک مسیر مشخص را طی میکند: ابتدا در لایهٔ HTTP و TLS خاتمه مییابد، سپس وارد core proxy ما میشود (که آن را FL یا “Frontline” مینامیم)، و در نهایت از طریق Pingora عبور میکند که cache را بررسی یا در صورت نیاز از origin واکشی میکند.
در حین عبور درخواست از core proxy، محصولات امنیتی و عملکردی مختلف روی آن اجرا میشوند؛ پروکسی پیکربندی و تنظیمات هر مشتری را اعمال میکند، از قوانین WAF و محافظت در برابر DDoS گرفته تا مسیردهی ترافیک به Developer Platform و R2. این کار از طریق مجموعهای از ماژولهای domain-specific انجام میشود که پیکربندی و قوانین سیاستی را روی ترافیک اعمال میکنند.
یکی از این ماژولها، Bot Management، منشاء اختلال امروز بود. Bot Management شامل یک مدل machine learning است که برای تولید bot score برای هر درخواست استفاده میشود؛ مشتریان از این bot scoreها برای تصمیمگیری دربارهٔ دسترسی روباتها به سایتها استفاده میکنند.
مدل ورودیاش را از یک فایل پیکربندی feature میگیرد؛ هر feature یک ویژگی مجزا است که مدل را برای پیشبینی اتوماتیک بودن یا نبودن درخواست تغذیه میکند. فایل feature مجموعهای از این featureهاست و هر چند دقیقه یکبار تازه میشود و در سراسر شبکه منتشر میگردد تا بتوانیم به تغییرات سریع در رفتار ترافیک و تاکتیکهای جدید botها واکنش نشان دهیم.
تغییری در رفتار query پایهای که این فایل را تولید میکرد (که در ادامه در مورد ClickHouse توضیح میدهم) باعث شد که تعداد زیادی ردیف تکراری feature تولید شود. این کار اندازهٔ پیشینِ تثبیتشدهٔ فایل را تغییر داد و ماژول bots را به خطا کشاند.
در نتیجه، کدهای وضعیت HTTP 5xx توسط core proxy برگردانده شدند برای ترافیکی که وابسته به ماژول bots بود. این موضوع همچنین Workers KV و Access را که به core proxy وابستهاند تحت تأثیر قرار داد.
بهطور جداگانه ما در حال مهاجرت ترافیک مشتریان به نسخهٔ جدیدی از سرویس proxy هستیم که بهصورت داخلی آن را FL2 مینامیم. هر دو نسخه تحت تأثیر قرار گرفتند، اما اثرات متفاوتی دیده شد: مشتریانی که روی FL2 بودند، خطاهای HTTP 5xx را مشاهده کردند؛ مشتریان روی FL هم خطای 5xx ندیدند اما bot scoreها درست تولید نمیشد و همهٔ ترافیک bot score صفر گرفت که برای مشتریانی که قوانین بلاک باتها را داشتند موجب false positiveهای گسترده شد. مشتریانی که از bot score در قواعدشان استفاده نمیکردند، تأثیری ندیدند.
یکی از علائمی که ما را گمراه کرد و باعث شد فکر کنیم ممکن است حمله باشد این بود که status page ما هم از دسترس خارج شد. آن صفحه کاملاً خارج از زیرساخت Cloudflare میزبانی میشود و وابستگی به Cloudflare ندارد. هرچند این همزمانی تصادفی بود، اما برخی تیمها را به این نتیجه رساند که ممکن است حملهای همزمان به سیستمهای ما و status page در حال وقوع باشد. بازدیدکنندگان آن زمان با پیام خطا مواجه شدند، و در چت داخلی حادثه نگران بودند که این ممکن است ادامهٔ موج اخیر DDoSهای حجیم باشد.
چه اتفاقی در ClickHouse افتاد و چرا فایل feature دوبرابر شد
تغییراتی که برای مدیریت permissions روی خوشهٔ ClickHouse انجام شد باعث شد رفتار query که فایل feature را تولید میکرد تغییر کند. وقتی این query روی گرههایی اجرا میشد که بهروز شده بودند، ردیفهای تکراری تولید میشدند و size فایل افزایش مییافت. چون انتشار فایل هر چند دقیقه انجام میشد و آپدیتِ خوشه تدریجی بود، بعضی زمانها فایل درست و بعضی زمانها فایل خراب منتشر میشد که همین باعث ناپایداری رفتوبرگشتی سیستم شد.
برای رفع مشکل، تولید و انتشار فایل خراب را متوقف کردیم، نسخهٔ معتبر و شناختهشدهای را به صف توزیع فرستادیم و core proxy را دوباره راهاندازی کردیم تا پخش درست فایل تضمین شود. سپس تیمها سرویسهایی را که وارد حالت بد شده بودند ریاستارت کردند تا حالت شانس خطا کاهش پیدا کند.
اقدامات بعدی و درسهایی که آموختیم 🔧
ما از این حادثه درسهای مشخصی گرفتیم و برنامههایی برای کاهش ریسک تکرار آن در حال اجرا داریم، از جمله: بهبود کنترل روی تولید فایلهای پیکربندی حساس مانند feature file، اضافه کردن آلارمهای اندازهٔ فایل و limit-aware handling در کدهایی که فایل را مصرف میکنند، بازبینی فرآیندهای تغییر permissions و استراتژیهای rollout تدریجیِ مطمئنتر در خوشههای ClickHouse، و کاهش وابستگی حلقههای debug و observability به منابع CPU در مسیرهای اصلی درخواست.
همچنین در مستندات داخلی و رویههای incident response تغییراتی خواهیم داد تا تشخیص اولیهٔ علائم نوسانیِ ناشی از انتشار پیکربندی نادرست راحتتر شود و از فرض حملهٔ خارجی بهعنوان تشخیص اولیهٔ قطعی خودداری کنیم؛ بهخصوص وقتی سیستمهای خارجی مثل status page همزمان دچار مشکل میشوند.
از همهٔ تیمها و مشتریان بابت صبوری و همکاریشان سپاسگزاریم. ما این اعلان را بهعنوان شروعِ شفافسازی و مسئولیتپذیری منتشر کردیم و بهزودی جزئیات بیشتر دربارهٔ تغییرات فنی و عملیاتی که برای جلوگیری از تکرار ارائه خواهیم داد را اعلام میکنیم. 🙇♂️
چرا اختلال cloudflare cloudflare رخ داد و چه درسهایی آموختیم
در این مطلب، تمرکز اصلی روی cloudflare cloudflare و پیامدهای آن برای کاربران، مشتریان و تیمهای فنی است تا بتوانیم با شفافیت بیشتری به این رویداد نگاه کنیم.
برای اطلاعات بیشتر External، میتوانید به صفحه وضعیت خدمات Cloudflare مراجعه کنید.
برای اطلاعات بیشتر در مورد مصرف منابع و بهینهسازی، به مقاله داخلی ما مراجعه کنید: درک و بهینهسازی مصرف منابع در Prometheus.
