ماجرای بزرگ‌ترین قطعی Cloudflare در ۱۸ نوامبر ۲۰۲۵؛ وقتی یک فایل کوچک، اینترنت را زمین زد

صبح ۱۸ نوامبر ۲۰۲۵، خیلی‌ها مثل همیشه پشت لپ‌تاپ‌شان نشستند تا کار روزانه را شروع کنند؛ اما اینترنت یک «نه» بزرگ در صورت‌شان کوبید. سایت‌ها بالا نمی‌آمدند، APIها timeout می‌شدند و داشبوردها قفل کرده بودند. اگر آن روز سردرگم شده بودید که «باز چی شد؟»، پاسخ کوتاه این است: Cloudflare زمین خورد.

Cloudflare یکی از ستون‌های اصلی اینترنت است؛ از DNS و CDN گرفته تا WAF و Bot Management. به‌همین‌خاطر، وقتی در این ستون ترک می‌افتد، موجش تقریباً همه‌جا دیده می‌شود. در این پست، به زبان ساده و در عین حال کاملاً فنی، داستان این قطعی را مرور می‌کنیم: چه شد، چرا شد و اگر شما مسئول زیرساخت هستید، چطور باید از تکرار چنین سناریویی در سیستم خودتان جلوگیری کنید.

۱. از نگاه کاربر چه اتفاقی افتاد؟

قطعی از حدود ساعت ۱۱:۲۰ UTC شروع شد. کاربران سعی می‌کردند سایت‌ها را باز کنند و با خطاهای سری ۵۰۰ مواجه می‌شدند. بعضی‌ها فکر کردند سرور خودشان خوابیده، بعضی‌ها گمان حمله DDoS بردند، و عده‌ای هم طبق معمول، اینترنت را مقصر دانستند!

• سایت‌ها خطای 5xx می‌دادند.
• ورود به داشبوردها و پنل‌ها سخت یا غیرممکن شده بود.
• سرویس‌های لاگین و احراز هویت گیر می‌کردند.
• بعضی سرویس‌ها به‌طور کامل unavailable بودند، بعضی دیگر کند شده بودند.

تصویر بزرگ‌تر: Cloudflare لزوماً «همه اینترنت» نیست، اما آن‌قدر بخش بزرگی از ترافیک را عبور می‌دهد که وقتی مشکلی برایش پیش بیاید، به‌نظر می‌رسد کل اینترنت خراب شده است.

۲. زیر کاپوت چه شد؟ ریشه ماجرا در Bot Management

برخلاف حدس اولیه خیلی‌ها، این ماجرا حمله سایبری نبود. داستان از یک تغییر ظاهراً ساده در سطح دسترسی (permissions) یک دیتابیس شروع شد که روی سیستم Bot Management اثر گذاشت. این سیستم برای تشخیص ربات‌ها از کاربران واقعی، از یک فایل پیکربندی به‌نام feature file استفاده می‌کند.

۲.۱ قدم اول: کوئری دیتابیس «بیش از حد مهربان» شد

Cloudflare برای ذخیره و تحلیل داده‌ها از ClickHouse استفاده می‌کند. در بخشی از بهبود مدیریت دسترسی، تغییراتی روی نحوهٔ دیدن متادیتا جدول‌ها اعمال شد. نتیجه ناخواسته این بود که یک کوئری که برای ساخت لیست featureها استفاده می‌شد، به‌جای یک‌بار، اطلاعات را تقریباً دو بار (با اسامی تکراری از شِماهای مختلف) برمی‌گرداند.

در عمل یعنی:

SELECT name, type FROM system.columns WHERE table = 'http_requests_features' ORDER BY name;

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

۲.۲ قدم دوم: feature file چاق شد

خروجی این کوئری هر چند دقیقه یک‌بار به یک فایل پیکربندی تبدیل می‌شد که باید به کل شبکه Cloudflare منتقل شود. به‌دلیل تکرار داده، این فایل:

• از حد معمول بزرگ‌تر شد،
• تعداد featureها از حدی که سیستم برای آن طراحی شده بود فراتر رفت،
• و در نهایت ماژول Bot Management را از مدار خارج کرد.

۲.۳ قدم سوم: ماژول Bot Management «وحشت» کرد

برای جلوگیری از مصرف بی‌نهایت حافظه، ماژول Bot Management سقفی برای تعداد featureهایی که می‌تواند در حافظه نگه دارد تعیین کرده بود (مثلاً ۲۰۰ مورد، در حالی که استفاده واقعی حدود ۶۰ بود). وقتی فایل جدید با تعداد featureهای بیشتر از این سقف رسید، کد چیزی شبیه به این رفتار کرد:

// شبه‌کد تقریبی برای نشان دادن منطق if (features.len() > MAX_FEATURES) {    panic!("too many features in config"); }

به‌جای اینکه gracefully fail کند و لاگ هشدار بدهد، عملاً panic کرد و ماژول کل پروکسی را کشید پایین. نتیجه؟ موج عظیمی از خطاهای سری ۵۰۰ برای ترافیکی که به Bot Management وابسته بود.

نکته مهم طراحی: هر جا در کدِ سرویس حیاتی با panic، assert یا معادل‌شان سر و کار دارید، یعنی جایی هست که یک ورودی غیرمنتظره می‌تواند کل سیستم را نابود کند. این‌جا دقیقاً همین اتفاق افتاد.

۳. Cloudflare چطور درخواست‌ها را پردازش می‌کند و این وسط چه خراب شد؟

هر درخواست HTTP که به Cloudflare می‌رسد، مسیر مشخصی را طی می‌کند:

1. پایان TLS/HTTP در لایه لبه (Edge).
2. ورود به پروکسی اصلی (هسته‌ای) که Cloudflare آن را Frontline یا FL/FL2 می‌نامد.
3. عبور از ماژول‌های مختلف: WAF، DDoS، Bot Management، قوانین سفارشی مشتری و ...
4. در صورت نیاز، ارسال درخواست به origin یا پاسخ از cache (از طریق Pingora و سایر اجزا).

ماژول Bot Management یکی از این ایستگاه‌هاست. وقتی این ایستگاه به‌خاطر فایل خراب از کار افتاد، پروکسی برای تعداد زیادی از درخواست‌ها دیگر نتوانست مسیر را کامل کند و به جای پاسخ عادی، 5xx برگرداند.

۴. چه سرویس‌هایی دقیقاً ضربه خوردند؟

طبق گزارش Cloudflare، این دسته از سرویس‌ها تحت تأثیر قرار گرفتند:

• Core CDN و سرویس‌های امنیتی: بازگشت خطاهای 5xx برای بخش قابل توجهی از ترافیک.
• Workers KV: سطح بالایی از خطا هنگام دسترسی به gateway به‌خاطر وابستگی به core proxy.
• Cloudflare Access: تلاش‌های جدید برای احراز هویت معمولاً با خطا مواجه می‌شد.
• Turnstile: سرویس کپچا-محور Cloudflare در دوره‌هایی از دسترس خارج شد؛ ورود به داشبورد سخت شد.
• Dashboard: بعضی کاربران نمی‌توانستند وارد شوند یا تنظیمات جدید اعمال کنند.

علاوه بر این، هنگام تلاش برای دیباگ، حجم بالای لاگ و گزارش خطا خودش فشار بیشتری روی منابع گذاشت و latency را بالا برد؛ یعنی حین حل مشکل، خود ابزار حل مشکل هم به بخشی از مشکل تبدیل شد.

۵. خط زمانی (Timeline) اتفاقات

۶. Cloudflare بعد از ماجرا چه کارهایی انجام می‌دهد؟

خلاصه اقداماتی که Cloudflare قول داده روی آن‌ها کار کند:

• سخت‌گیری روی ingest شدن فایل‌های پیکربندی تولیدشده توسط خود سیستم، همان‌قدر که روی ورودی کاربر حساس است.
• تعریف kill switchهای سراسری بیشتر برای ماژول‌ها تا در صورت بروز مشکل، بتوان یک قابلیت را سریعاً از مدار خارج کرد.
• جلوگیری از اینکه core dumpها و گزارش خطا خودشان منابع سیستم را نبلعند.
• بازنگری failure mode تمام ماژول‌های پروکسی برای جلوگیری از panicهای مشابه.

پیام ضمنی برای بقیه دنیا: اگر Cloudflare با این سطح تجربه و تیم فنی، هنوز می‌تواند با یک باگ در config این‌طور ضربه بخورد، بقیه‌ی ما حتماً باید چند برابر محتاط‌تر باشیم.

۷. این اتفاق برای ما چه درسی دارد؟ (چک‌لیست عملی برای تیم‌های زیرساخت)

۷.۱ به یک ارائه‌دهنده قانع نشوید؛ Multi-CDN و Multi-DNS

• برای سرویس‌های حیاتی، حداقل دو ارائه‌دهنده CDN/DNS در نظر بگیرید.
• سناریوهای failover را از قبل پیاده کنید؛ نه وسط بحران.

۷.۲ با configها مثل کد رفتار کنید

• version control، code review، و حتی تست واحد برای ruleها و configها.
• محدودیت سختگیرانه روی اندازه، تعداد rule و سطح پیچیدگی.
• سیستمی برای rollback سریع به آخرین نسخهٔ سالم.

۷.۳ هیچ‌وقت روی ورودی «مطمئن» حساب نکنید

در این حادثه، ورودی خراب از سمت کاربر نیامد؛ بلکه خود سیستم داخلی آن را تولید کرد. پس هرجا پای فایل، message یا config وسط است، فرض کنید «ممکن است روزی خراب تولید شود».

۷.۴ panic و crash را به خطاهای کنترل‌شده تبدیل کنید

• به‌جای توقف کامل ماژول، مسیر degrade شده ولی قابل‌استفاده تعریف کنید (مثلاً غیرفعال کردن Bot Management به‌طور موقت).
• panic فقط در لایه‌هایی که کاملاً ایزوله هستند قابل توجیه است، نه در core proxy.

۷.۵ Chaos Engineering را جدی بگیرید

سناریوهایی مثل «فایل پیکربندی خراب است»، «یک ماژول اصلی خطا می‌دهد»، «latency دیسک بالا رفته» و ... را عمداً در محیط staging یا حتی production با کنترل دقیق شبیه‌سازی کنید. ببینید واقعاً چه اتفاقی می‌افتد، نه آنچه فکر می‌کنید اتفاق می‌افتد.

۸. سوالات متداول کوتاه (FAQ)

آیا این قطعی به‌خاطر حمله سایبری بود؟

خیر. طبق گزارش رسمی Cloudflare، هیچ نشانه‌ای از حمله وجود نداشت و ریشهٔ مشکل یک تغییر داخلی در دیتابیس بود.

آیا دادهٔ کاربران به خطر افتاد؟

این حادثه در لایهٔ مسیر‌یابی و پردازش درخواست رخ داد، نه در لایهٔ ذخیره‌سازی داده. تمرکز مشکل روی در دسترس‌بودن بود، نه محرمانگی.

چرا سایت من هم قطع شد؟

اگر از Cloudflare به‌عنوان CDN، DNS یا WAF استفاده می‌کردید، احتمالاً بخشی از ترافیک شما در همین بازه از شبکه‌ای عبور می‌کرد که feature file خراب روی آن لود شده بود.

الان چه کار می‌توانم بکنم؟

• ریسک وابستگی ۱۰۰٪ به یک ارائه‌دهنده را بسنجید.
• برای سرویس‌های حیاتی، مسیر جایگزین (backup path) طراحی کنید.
• برای config و ruleها pipeline تست و rollback بسازید.

جمع‌بندی: یک فایل کوچک، یک درس بزرگ

قطعی ۱۸ نوامبر ۲۰۲۵ Cloudflare فقط یک «حادثه فنی» نبود؛ یک یادآوری محکم بود که در عصر وابستگی شدید به چند ارائه‌دهندهٔ زیرساختی، کوچک‌ترین خطا در لایهٔ پیکربندی می‌تواند اثر جهانی داشته باشد.

اگر شما مالک یک محصول آنلاین، مهندس DevOps، SRE یا مسئول زیرساخت هستید، این حادثه یک دعوت جدی است به اینکه امروز — نه فردا — نگاهی دوباره به معماری‌تان، نقاط شکست، و برنامه‌های بازیابی بیندازید. اینترنت همیشه آنلاین به‌صورت پیش‌فرض به دست نمی‌آید؛ باید آن را طراحی و هر روز مراقبت کرد.