چرا کلودفلیر در ۱۸ نوامبر ۲۰۲۵ از کار افتاد؟ (درس‌هایی از بزرگترین اختلال اینترنت)

زمان مطالعه : 8 دقیقه

در اکوسیستم اینترنت مدرن، شبکه تحویل محتوا (CDN) نقش حیاتی ایفا می‌کند. از میان این شبکه‌ها، کلودفلیر (Cloudflare) یکی از مهم‌ترین ستون‌های ثبات، امنیت، و سرعت اینترنت جهانی محسوب می‌شود. به همین دلیل، هنگامی که این شبکه دچار اختلال می‌شود، تقریباً نیمی از کاربران اینترنت در سراسر جهان اثرات آن را مستقیماً احساس می‌کنند.

در ۱۸ نوامبر ۲۰۲۵، در ساعت ۱۱:۲۰ به وقت جهانی (UTC)، شبکه کلودفلیر دچار یک قطعی گسترده و قابل توجه شد که منجر به ناتوانی در ارائه ترافیک شبکه اصلی به مشتریان گشت. این وضعیت برای کاربران نهایی، به شکل صفحات خطای سیستمی (Error Page) ظاهر می‌شد که نشان‌دهنده شکست در شبکه داخلی کلودفلیر بود.

این مقاله، به عنوان یک تحلیل‌گر و معلم فنی شما، قصد دارد نه‌تنها اتفاقات آن روز را به‌طور کامل تشریح کند، بلکه مفاهیم فنی پیچیده‌ای که پشت این شکست قرار داشتند را با زبانی ساده و روان توضیح دهد تا «مطلب به‌طور کامل برای کاربر جا بیفتد».

https://www.youtube.com/watch?v=1bgKZkTD_Ek

۱. علائم اولیه: سه‌ساعت پراضطراب و معمای کدهای خطای ۵xx

نشانه‌ی اصلی این اختلال، افزایش ناگهانی و چشمگیر کدهای وضعیت HTTP 5xx بود که توسط شبکه کلودفلیر سرو می‌شد.

مفهوم ساده‌سازی شده: کدهای خطای ۵xx چیست؟

قیاس ساده: تصور کنید شما یک گارسون (مرورگر شما) را به آشپزخانه رستوران (سرور کلودفلیر) می‌فرستید تا غذای شما را بیاورد. کدهای وضعیت HTTP، همان پاسخ آشپزخانه هستند.

• پاسخ ۲۰۰: «بفرمایید، غذا آماده است.» (موفقیت)
• پاسخ ۴۰۴: «غذا اینجا نیست.» (خطای مشتری/آدرس اشتباه)
• پاسخ ۵xx (مانند ۵۰۰ یا ۵۰۳): «ما نتوانستیم غذای شما را آماده کنیم چون مشکل از وسایل یا سیستم داخلی آشپزخانه است.»

در این اختلال، افزایش ناگهانی کدهای ۵xx به معنای آن بود که مشکل نه از سرورهای مشتریان کلودفلیر، بلکه از درون شبکه داخلی کلودفلیر بود.

این نمودار نشان می‌دهد که حجم خطاهای ۵xx تا قبل از ساعت ۱۱:۲۰ (UTC) بسیار پایین و در حد انتظار بود، اما پس از شروع قطعی، با یک جهش بزرگ مواجه شد و سپس دچار نوسانات شدید گردید.

۲. ریشه مشکل: یک تغییر ساده با اثر فاجعه‌بار

برخلاف گمانه‌زنی‌های اولیه و حتی شک اولیه خود تیم کلودفلیر، این مشکل مستقیماً یا غیرمستقیم ناشی از یک حمله سایبری یا فعالیت مخرب نبود.

علت اصلی این بود: یک تغییر در مجوزهای دسترسی به یکی از سیستم‌های پایگاه داده (Database Systems) کلودفلیر، باعث شد که آن پایگاه داده چندین ورودی تکراری را در یک «فایل مشخصه» (Feature File) خروجی دهد. این فایل توسط سیستم مدیریت ربات (Bot Management) کلودفلیر استفاده می‌شود.

نتیجه این شد که حجم فایل مشخصه تقریباً دو برابر شد. این فایل بزرگ‌تر از حد انتظار، به‌سرعت در تمام ماشین‌هایی که شبکه کلودفلیر را تشکیل می‌دهند، توزیع شد.

مفهوم ساده‌سازی شده: سیستم مدیریت ربات و فایل مشخصه

Bot Management (مدیریت ربات): کلودفلیر با استفاده از مدل‌های یادگیری ماشین (Machine Learning)، برای هر درخواستی که از شبکه عبور می‌کند، یک امتیاز ربات (Bot Score) تولید می‌کند. مشتریان از این امتیاز برای تصمیم‌گیری در مورد مجاز بودن یا نبودن یک ربات برای دسترسی به سایت خود استفاده می‌کنند.

فایل مشخصه (Feature File): این فایل، ورودی مدل یادگیری ماشین است. «مشخصه» در این زمینه، یک ویژگی یا خصیصه فردی است که مدل از آن برای پیش‌بینی خودکار یا نبودن درخواست استفاده می‌کند (مانند مرورگر کاربر، سرعت ارسال درخواست و …). این فایل هر چند دقیقه یک‌بار به‌روزرسانی شده و در کل شبکه منتشر می‌شود تا کلودفلیر بتواند به تاکتیک‌های جدید مهاجمان به‌سرعت واکنش نشان دهد.

جریان شکست: نرم‌افزاری که برای مسیریابی ترافیک در شبکه اجرا می‌شود، این فایل مشخصه را می‌خواند تا سیستم مدیریت ربات را به‌روز نگه دارد. اما این نرم‌افزار، حدی برای اندازه فایل مشخصه داشت که از اندازه دو برابر شده‌ی جدید کوچک‌تر بود. رسیدن به این حد باعث شد که نرم‌افزار از کار بیفتد و در نتیجه ترافیک متوقف شود.

۳. تجزیه و تحلیل فنی عمیق: چگونگی پردازش درخواست‌ها و خطای پروکسی

هر درخواستی که به کلودفلیر می‌رسد، مسیری مشخص را طی می‌کند. ابتدا درخواست در لایه HTTP و TLS خاتمه می‌یابد، سپس وارد سیستم پروکسی اصلی (Core Proxy System) که کلودفلیر آن را FL (مخفف Frontline) می‌نامد، می‌شود.

مفهوم ساده‌سازی شده: پروکسی اصلی (Core Proxy – FL)

قیاس ساده: پروکسی اصلی (FL) را مانند دروازه‌بان و مسئول پذیرش یک ساختمان بزرگ تصور کنید. تمام ترافیک باید ابتدا از طریق او عبور کند. این دروازه‌بان قوانین ساختمان (WAF، DDoS Protection) و مسیر حرکت به بخش‌های مختلف (Developer Platform، R2) را بر اساس تنظیمات هر مشتری اعمال می‌کند.

شکست در پروکسی: سیستم پروکسی اصلی، مجموعه‌ای از ماژول‌ها (ماژول مدیریت ربات، ماژول WAF و …) دارد که قوانین و پیکربندی‌ها را اعمال می‌کنند. ماژول مدیریت ربات منشأ قطعی بود.

هنگامی که فایل مشخصه معیوب با تعداد زیادی ردیف تکراری منتشر شد: ۱. اندازه فایل ثابت قبلی تغییر کرد. ۲. ماژول ربات‌ها به دلیل این تغییر اندازه، یک خطا را فعال کرد. ۳. در نتیجه، سیستم پروکسی اصلی (FL2) برای ترافیکی که به ماژول ربات‌ها وابسته بود، کدهای خطای ۵xx برگرداند.

کلودفلیر در حال مهاجرت ترافیک مشتریان به نسخه جدید پروکسی به نام FL2 بود. هر دو نسخه تحت تأثیر قرار گرفتند، اما به شکل‌های متفاوت:

• مشتریان FL2: خطاهای HTTP 5xx مشاهده کردند.
• مشتریان FL (نسخه قدیمی): خطایی ندیدند، اما امتیاز ربات به‌درستی تولید نشد و تمام ترافیک امتیاز صفر گرفت. این امر باعث شد مشتریانی که قوانین مسدودسازی ربات‌ها را داشتند، با تعداد زیادی مثبت کاذب (False Positives) مواجه شوند (یعنی کاربران واقعی را ربات تشخیص دهند و مسدود کنند).

۴. معمای نوسانات و پایگاه داده ClickHouse

یکی از رفتارهای غیرعادی در این قطعی، نوسانات مشاهده‌شده در نمودار خطا بود (افزایش خطا، بازیابی برای مدتی کوتاه، و دوباره شکست).

دلیل این نوسان این بود که فایل مشخصه توسط یک کوئری (Query) که بر روی یک خوشه پایگاه داده کلیک‌هاوس (ClickHouse Database Cluster) اجرا می‌شد، هر پنج دقیقه تولید می‌گردید.

تغییر مجوزها در این پایگاه داده به‌تدریج اعمال می‌شد. داده‌های بد (فایل بزرگ) فقط زمانی تولید می‌شدند که کوئری بر روی بخشی از خوشه که به‌روز شده بود، اجرا می‌شد. در نتیجه، هر پنج دقیقه شانس تولید یک مجموعه فایل پیکربندی «خوب» یا «بد» وجود داشت. همین امر باعث شد تیم کلودفلیر در ابتدا تصور کند با یک حمله (Attack) مواجه هستند.

۵. ریشه‌یابی فنی: تغییر در کنترل دسترسی پایگاه داده (Database Access Control)

سیستم پایگاه داده مورد بحث از نرم‌افزار کلیک‌هاوس (ClickHouse) استفاده می‌کند.

مفهوم ساده‌سازی شده: کوئری‌های توزیع شده در ClickHouse

خوشه کلیک‌هاوس از چندین شارد (Shard) یا بخش تشکیل شده است. برای کوئری گرفتن از تمام این شاردها، ما جداول توزیع‌شده (Distributed Tables) داریم که قدرت خود را از جداول زیرین در پایگاه داده‌ای به نام r0 می‌گیرند. داده‌ها به‌طور فیزیکی در همان جداول r0 ذخیره می‌شوند.

تغییر فاجعه‌آمیز: تیم کلودفلیر در حال بهبود امنیت و قابلیت اطمینان کوئری‌های توزیع‌شده بود. قبل از این تغییر، کاربران هنگام کوئری گرفتن از ابرداده‌های (Metadata) جداول سیستمی ClickHouse (مانند system.tables)، فقط جداول موجود در پایگاه داده default را مشاهده می‌کردند.

در ساعت ۱۱:۰۵ (UTC)، تغییری اعمال شد تا دسترسی کاربران به ابرداده‌های جداول زیرین در r0 نیز صریح (Explicit) شود. هدف این بود که کوئری‌های فرعی توزیع‌شده تحت حساب‌های کاربری اولیه اجرا شوند تا ارزیابی محدودیت‌ها و مجوزها دقیق‌تر باشد.

اما مشکل اینجا بود: منطق تولید فایل مشخصه مدیریت ربات از کوئری زیر استفاده می‌کرد:

SELECT name, type FROM system.columns WHERE table = 'http_requests_features' order by name;

این کوئری هیچ فیلتری برای نام پایگاه داده نداشت. با اعمال تغییر مجوز جدید، این کوئری ناگهان شروع به برگرداندن تکرار ستون‌ها کرد، زیرا اکنون ابرداده‌های مربوط به جداول زیرین ذخیره شده در پایگاه داده r0 را نیز شامل می‌شد.

این امر باعث شد خروجی کوئری بیش از دو برابر شود، و در نهایت تعداد ردیف‌ها (یعنی مشخصه‌ها یا Features) در فایل نهایی تولید شده افزایش یافت.

۶. نقطه شکست نهایی: پیش‌تخصیص حافظه (Memory Preallocation)

هر ماژولی که در سرویس پروکسی (FL/FL2) اجرا می‌شود، برای جلوگیری از مصرف نامحدود حافظه و بهینه‌سازی عملکرد، دارای محدودیت‌هایی است.

سیستم مدیریت ربات یک محدودیت سخت برای تعداد مشخصه‌های یادگیری ماشین که می‌توانند در زمان اجرا استفاده شوند، داشت. این حد در حال حاضر روی ۲۰۰ تنظیم شده بود، در حالی که استفاده عادی حدود ۶۰ مشخصه بود. این محدودیت به این دلیل وجود داشت که حافظه برای عملکرد بهتر، پیش‌تخصیص (Preallocate) می‌شد.

هنگامی که فایل معیوب با بیش از ۲۰۰ مشخصه به سرورها رسید، این حد فعال شد و در نتیجه سیستم دچار وحشت (Panic) گردید.

کد راست (Rust) در FL2 که این بررسی را انجام می‌داد، منجر به خطای رسیدگی نشده (unhandled error) و در نهایت به خطای ۵xx منجر شد:

 thread fl2_worker_thread panicked: called Result::unwrap() on an Err value

کدی که خطا را ایجاد کرده است

۷. تأثیرات جانبی و فرعی بر سایر سرویس‌ها

سرویس‌های دیگری که به پروکسی اصلی وابسته بودند نیز تحت تأثیر قرار گرفتند.

• Workers KV: این سرویس دچار افزایش قابل توجه کدهای خطای HTTP 5xx شد، زیرا درخواست‌ها به «جبهه پایانی» (Front end) آن به دلیل شکست پروکسی اصلی، با مشکل مواجه شدند.
• Cloudflare Access: شکست‌های احراز هویت (Authentication failures) برای اکثر کاربران گسترده بود و تا ساعت ۱۳:۰۵ (UTC) ادامه یافت.
• Cloudflare Turnstile: این سیستم که وظیفه تأیید انسان بودن کاربران را دارد، قادر به بارگیری نبود.
• داشبورد (Dashboard): اگرچه بیشتر عملکردی بود، اما بسیاری از کاربران به دلیل در دسترس نبودن Turnstile در صفحه ورود، قادر به ورود نبودند.

یک نکته جالب اینکه صفحه وضعیت (Status Page) کلودفلیر نیز از کار افتاد. اگرچه این صفحه کاملاً خارج از زیرساخت کلودفلیر میزبانی می‌شود و وابستگی به آن ندارد، اما این همزمانی باعث شد تیم عیب‌یابی در ابتدا تصور کند یک مهاجم به‌طور همزمان هر دو سیستم را هدف قرار داده است.

۸. رفع مشکل و گام‌های بعدی

از ساعت ۱۱:۲۸ (UTC) که خطاها مشاهده شدند، تیم کلودفلیر به‌سرعت وارد عمل شد.

1. بررسی و انحراف اولیه: در ابتدا، گمان می‌رفت مشکل ناشی از افزایش سطح ترافیک به سرویس Workers KV باشد. تلاش‌هایی برای مدیریت ترافیک و محدود کردن حساب‌ها صورت گرفت.
2. پیاده‌سازی دور زدن (Bypass): در ساعت ۱۳:۰۵، دور زدن سرویس‌های Workers KV و Cloudflare Access پیاده‌سازی شد. این امر باعث شد نرخ خطای سیستم‌های پایین‌دستی که به Workers KV وابسته بودند (مانند Access)، کاهش یابد.
3. شناسایی عامل اصلی: در ساعت ۱۳:۳۷، تیم اطمینان پیدا کرد که فایل پیکربندی مدیریت ربات عامل محرک است.
4. توقف انتشار و بازیابی: در ساعت ۱۴:۲۴، تولید و انتشار فایل‌های پیکربندی جدید مدیریت ربات متوقف شد. با قرار دادن دستی یک فایل خوب شناخته‌شده قبلی در صف توزیع و اجبار به راه‌اندازی مجدد پروکسی اصلی، مشکل حل شد.
5. پایان اختلال اصلی: تا ساعت ۱۴:۳۰ (UTC)، اختلال اصلی برطرف شد.

در نهایت، تا ساعت ۱۷:۰۶ (UTC)، تمام سیستم‌ها به حالت عادی برگشتند.

اقدامات اصلاحی و جلوگیری از تکرار

این بدترین قطعی کلودفلیر از سال ۲۰۱۹ بود. کلودفلیر متعهد شد تا در آینده، سیستم‌های خود را در برابر شکست‌هایی مانند این مقاوم‌تر سازد. برنامه‌های آن‌ها شامل موارد زیر است:

• سخت‌سازی دریافت فایل‌های پیکربندی تولیدشده توسط خود کلودفلیر، درست مانند ورودی‌های تولیدشده توسط کاربر.
• فعال‌سازی سوئیچ‌های کشتار جهانی (Global Kill Switches) بیشتر برای ویژگی‌ها.
• حذف قابلیتی که گزارش‌های خطا یا کور دامپ‌ها (Core Dumps) منابع سیستم را اشغال کنند.
• بازبینی حالت‌های شکست برای شرایط خطا در تمام ماژول‌های پروکسی اصلی.

نتیجه‌گیری تحلیلی: این واقعه نشان داد که حتی قوی‌ترین شبکه‌های جهان نیز در برابر یک خطای ساده در مدیریت مجوزهای پایگاه داده، که منجر به تجاوز از محدودیت‌های پیش‌تخصیص حافظه (Memory Preallocation) می‌شود، آسیب‌پذیرند. درس بزرگ اینجاست که در معماری سیستم‌های توزیع‌شده، کوچکترین تغییر در یک بخش می‌تواند اثرات فاجعه‌باری در بخش‌های کاملاً مستقل دیگر ایجاد کند. می‌توان گفت، شکست کلودفلیر مانند این بود که یک کارمند بانک در حال به‌روزرسانی سیستم‌های امنیتی، ناخواسته دستور دهد که تمام صندوق‌های امانات (Features) در پایگاه داده کپی شوند؛ حجم ناگهانی این اطلاعات کپی شده، سیستم اصلی را که برای نگهداری تعداد محدودی از صندوق‌ها طراحی شده بود، دچار اضافه بار کرده و آن را فلج کرد.