خلاصه‌ای از قطعی بزرگ ۱۸ نوامبر کلودفلر

در ۱۸ نوامبر ۲۰۲۵، بخش بزرگی از اینترنت از کار افتاد.

اگر ChatGPT، X (توییتر)، League of Legends، Shopify، Coinbase یا سایت‌های کوچک بی‌شماری را باز می‌کردید، با یک صفحه خطای ۵xx با برند Cloudflare مواجه می‌شدید - یا اصلاً سایت‌ها بارگذاری نمی‌شد. چیزی که در ابتدا مانند یک لحظه بزرگ دیگر "اینترنت خراب است" به نظر می‌رسید، در واقع چیزی ظریف‌تر و از برخی جهات نگران‌کننده‌تر بود: یک اشکال خودساخته در اعماق زیرساخت خود Cloudflare.

در زیر، شرح مفصلی از آنچه در قطعی دیروز Cloudflare (۱۸ نوامبر ۲۰۲۵) اتفاق افتاد، دلیل آن، افرادی که تحت تأثیر قرار گرفتند و درس‌هایی که تیم‌های زیرساخت باید از آن بگیرند، آورده شده است.

دیروز واقعاً چه اتفاقی افتاد؟

روز سه‌شنبه، ۱۸ نوامبر ۲۰۲۵، حوالی اواخر صبح UTC، Cloudflare شروع به ارسال حجم زیادی از خطاهای سرور HTTP 5xx برای ترافیکی که از شبکه‌اش عبور می‌کرد، کرد. برای کاربران نهایی، این به معنای صفحات «خطای داخلی سرور» یا «خطای دروازه» هنگام تلاش برای دسترسی به بسیاری از وب‌سایت‌ها و برنامه‌های محبوب بود.

طبق وبلاگ پس از حادثه خود Cloudflare، قطعی:

تاثیرگذاری بر ترافیک HTTP مشتری از ساعت ۱۱:۲۸ UTC آغاز شد

خطاهای گسترده ۵xx در CDN اصلی و سرویس‌های امنیتی مشاهده شد

حدود ساعت ۱۳:۰۵ تا ۱۴:۳۰ UTC اقدامات اساسی برای کاهش خطا انجام شد

حجم خطای ۵xx تا ساعت ۱۷:۰۶ UTC به حالت اولیه بازگشت. وبلاگ Cloudflare

خود Cloudflare این را بدترین قطعی خود از سال ۲۰۱۹ توصیف کرد، زیرا فقط بر یک ویژگی یا داشبورد تأثیر نگذاشت - لایه پروکسی اصلی را که اکثر ترافیک مشتری را از طریق شبکه خود هدایت می‌کند، مختل کرد. وبلاگ Cloudflare

نظارت شخص ثالث این موضوع را تأیید کرد. شرکت Cisco ThousandEyes شاهد قطعی سراسری بود که Cloudflare را تحت تأثیر قرار داد و با وقفه‌ها و خطاهای 5xx در سرویس‌هایی مانند X، OpenAI (ChatGPT) و Anthropic همراه بود، در حالی که خود مسیرهای شبکه سالم به نظر می‌رسیدند. این موضوع به شدت به یک نقص سرویس backend اشاره داشت، نه یک مشکل در سطح ISP یا مسیریابی. ThousandEyes

چه کسی تحت تأثیر قرار گرفت؟
از آنجا که Cloudflare در مقابل بخش عظیمی از اینترنت قرار دارد (حدود 20٪ از سایت‌های وب برای عملکرد و امنیت به Cloudflare متکی هستند)، شعاع انفجار بسیار زیاد بود. AP News+1

از جمله سرویس‌هایی که تحت تأثیر قرار گرفته‌اند:

ChatGPT / OpenAI

X (قبلاً توییتر)

Canva، Shopify، Dropbox، Coinbase

League of Legends و سایر پلتفرم‌های بازی

سایت‌های مختلف حمل و نقل عمومی و دولتی، از جمله سیستم حمل و نقل نیوجرسی و سیستم‌های دیجیتال راه‌آهن SNCF فرانسه

AP News+1

ردیاب‌های قطعی مانند Downdetector هزاران گزارش مشکل همزمان را در اوج مصرف ثبت کردند. رویترز گزارش داد که در یک مقطع، تنها برای X حدود ۵۰۰۰ کاربر تحت تأثیر قرار گرفته‌اند، قبل از اینکه با ارائه اصلاحات، تعداد آنها کاهش یابد. رویترز

از دیدگاه یک کاربر، این مشکل به صورت‌های زیر خود را نشان می‌دهد:

سایت‌ها اصلاً بارگیری نمی‌شوند

جریان‌های ورود به سیستم قطع یا از کار می‌افتند (به‌خصوص در مواردی که Cloudflare Access یا Turnstile درگیر بودند)

APIها به‌طور متناوب یا با خطاهای ۵xx پاسخ می‌دهند

داشبوردها و پنل‌های مدیریتی با زمان‌بندی از کار می‌افتند

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

نحوه عملکرد معمول Cloudflare (به زبان ساده)

برای درک اینکه چرا این قطعی اینقدر شدید بود، دانستن مسیر تقریبی یک درخواست از طریق شبکه Cloudflare مفید است.

Cloudflare به عنوان یک CDN پروکسی معکوس و لایه امنیتی عمل می‌کند:

مرورگر یا برنامه شما به جای اتصال مستقیم به سایت اصلی، به Cloudflare متصل می‌شود.

Cloudflare TLS و HTTP را در لبه خود خاتمه می‌دهد.

درخواست‌ها به سیستم پروکسی اصلی Cloudflare به نام FL ("Frontline") و نسل جدیدتر آن FL2 جریان می‌یابند.

آن پروکسی اصلی:

قوانین WAF (فایروال برنامه وب) را اعمال می‌کند

مدل‌های مدیریت ربات را اجرا می‌کند

محافظت در برابر DDoS، ذخیره‌سازی و خروج به مبدا را مدیریت می‌کند

ترافیک را به سایر محصولات داخلی مانند Workers، R2، Access و غیره هدایت می‌کند. وبلاگ Cloudflare

در حالت عادی، این معماری بسیار مقاوم است: اگر یک مرکز داده مشکلی داشته باشد، ترافیک از طریق سایر مراکز داده هدایت می‌شود؛ تغییرات پیکربندی با دقت اعمال می‌شوند؛ ویژگی‌های منحصر به فرد باید به روش‌های کنترل‌شده‌ای از کار بیفتند.

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

علت اصلی: یک فایل ویژگی مدیریت ربات از کار افتاده است
توضیح رسمی Cloudflare به یک مقصر اصلی اشاره دارد:
یک فایل پیکربندی ویژگی که توسط سیستم مدیریت ربات آنها استفاده می‌شود. وبلاگ Cloudflare

در اینجا زنجیره رویدادها به زبان ساده آمده است:

مدیریت ربات از یک "فایل ویژگی" استفاده می‌کند

مدل تشخیص ربات Cloudflare به مجموعه‌ای از "ویژگی‌ها" متکی است - سیگنال‌هایی در مورد هر درخواست که برای تصمیم‌گیری در مورد انسان یا ربات بودن آن استفاده می‌شود.

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

تغییر در رفتار پرس‌وجوی ClickHouse

فایل ویژگی توسط پرس‌وجوها در برابر یک پایگاه داده ClickHouse تولید می‌شود.

Cloudflare حدود ساعت 11:05 UTC تغییری ایجاد کرد تا امنیت و مجوزهای پرس‌وجوهای توزیع‌شده را بهبود بخشد - allo

کاربران بال می‌توانند فراداده‌ها را نه تنها از یک طرح پیش‌فرض، بلکه از جداول r0 زیرین نیز ببینند. وبلاگ Cloudflare

پرس و جویی که لیست ویژگی‌ها را ایجاد می‌کند، بر اساس نام پایگاه داده فیلتر نشده بود؛ ناگهان شروع به دریافت ستون‌های تکراری از هر دو حالت پیش‌فرض و r0 کرد و عملاً تعداد ردیف‌های ویژگی را دو برابر کرد.

فایل ویژگی از نظر اندازه به شدت افزایش یافت

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

هنگامی که فایل تازه تولید شده از آن محدودیت فراتر رفت، ماژول به دلیل خطای مدیریت نشده در کد Rust که از Result::unwrap() روی یک مقدار خطا استفاده می‌کرد، به محدودیت رسید و دچار وحشت شد. وبلاگ Cloudflare

سرویس‌های پروکسی اصلی شروع به بازگرداندن خطاهای ۵xx کردند

از آنجا که مدیریت ربات در مسیر پروکسی اصلی ادغام شده است، وحشت به عنوان پاسخ‌های HTTP 5xx برای هر ترافیکی که به آن ماژول وابسته بود، ظاهر شد.

در موتور جدید FL2، مشتریان خطاهای صریح ۵xx را مشاهده کردند.

در موتور قدیمی‌تر FL، امتیاز ربات‌ها بی‌سروصدا به صفر می‌رسید که می‌توانست باعث ایجاد مثبت کاذب در قوانین مسدود کردن ربات‌ها شود. وبلاگ Cloudflare

بخش واقعاً ناخوشایند: فایل مدام بین «خوب» و «بد» در نوسان بود.

خوشه ClickHouse به تدریج به‌روزرسانی می‌شد و فایل ویژگی هر پنج دقیقه بازسازی می‌شد.

گاهی اوقات پرس‌وجو روی گره‌های به‌روزرسانی‌شده اجرا می‌شد (یک فایل بد تولید می‌کرد)، گاهی اوقات روی گره‌های به‌روزرسانی‌نشده (یک فایل خوب تولید می‌کرد).

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

این نوسان، وضعیت را از نظر داخلی بسیار گیج‌کننده کرد. در ابتدا، تیم‌های Cloudflare به یک حمله DDoS گسترده مشکوک شدند زیرا الگوی خطا شبیه یک خرابی نرم‌افزاری ساده نبود. حتی صفحه وضعیت Cloudflare که خارج از زیرساخت خودشان میزبانی می‌شود، به طور خلاصه خطاهایی را نشان داد - تصادفی که بیشتر به سوءظن حمله خارجی دامن زد. وبلاگ Cloudflare+1

تنها زمانی که متوجه شدند عامل مشترک، فایل ویژگی ربات است، تصویر واضح شد.

جدول زمانی حادثه
بر اساس گزارش‌های پس از وقوع Cloudflare و گزارش‌های شخص ثالث، می‌توانیم یک جدول زمانی تقریبی برای 18 نوامبر 2025 کنار هم قرار دهیم: وبلاگ Cloudflare+2ThousandEyes+2

11:05 UTC - یک تغییر کنترل دسترسی به پایگاه داده در ClickHouse اعمال می‌شود.

11:20-11:30 UTC - نسخه‌های بد فایل ویژگی مدیریت ربات شروع به تولید و انتشار می‌کنند.

11:28 UTC - اولین تأثیر بر مشتری: خطاهای HTTP 5xx بالا در ترافیک مشتری مشاهده می‌شود.

11:30-11:32 UTC - ابزارهای نظارت خارجی و آزمایش‌های خودکار شروع به شناسایی خرابی‌های متناوب می‌کنند.

11:35 UTC - Cloudflare یک فراخوان حادثه داخلی را آغاز می‌کند؛ تحقیقات آغاز می‌شود.

~11:48 UTC – Cloudflare یک به‌روزرسانی وضعیت منتشر می‌کند که یک حادثه را تأیید می‌کند. ارسال مجدد

11:30–13:05 UTC – تیم‌ها بر روی آنچه که به نظر می‌رسد رفتار Worker KV تخریب شده است تمرکز می‌کنند و چندین علت احتمالی (از جمله سناریوهای حمله) را بررسی می‌کنند.

13:05 UTC – کاهش کلیدی: Worker KV و Cloudflare Access برای دور زدن پروکسی اصلی تغییر داده می‌شوند؛ تأثیر کاهش می‌یابد. وبلاگ Cloudflare

14:30 UTC – علت اصلی شناسایی می‌شود؛ تولید و انتشار فایل‌های ویژگی بد متوقف می‌شود. یک فایل پیکربندی شناخته شده به خوبی به صورت دستی وارد می‌شود و پروکسی اصلی مجدداً راه‌اندازی می‌شود. بیشتر ترافیک اصلی به حالت عادی باز می‌گردد. وبلاگ Cloudflare

14:40–15:30 UTC – مشکلات داشبورد و ورود به سیستم همچنان ادامه دارد زیرا Turnstile و انباشت تلاش‌های احراز هویت باعث ایجاد افزایش بار ثانویه می‌شوند. وبلاگ Cloudflare

17:06 UTC – نرخ خطا به حالت اولیه بازمی‌گردد؛ Cloudflare سیستم‌ها را کاملاً عادی اعلام می‌کند. وبلاگ کلودفلر

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

چرا این قطعی برق بسیار مهم است

ریسک تمرکز
کلودفلر بخشی از یک مجموعه کوچک از ارائه دهندگان زیرساخت اینترنت مرکزی است، در کنار پلتفرم‌های اصلی ابری (AWS، Azure، GCP) و سایر CDN های بزرگ. وقتی یکی از این بازیگران از کار می‌افتد، تأثیر آن گسترده و اغلب غیر آشکار است.

این قطعی برق:

از یک حادثه مسیریابی BGP یا قطع کابل ISP ناشی نشد.

از یک حمله مخرب ناشی نشد (علیرغم سوءظن‌های اولیه).

از یک پیکربندی واحد ناشی شد و اشکال را در یک جزء داخلی محدود می‌کند.

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

وابستگی‌های «نرم» نیز آسیب‌زا بودند

برخی از سرویس‌های آسیب‌دیده فقط از Cloudflare به عنوان یک CDN بی‌معنی استفاده نمی‌کردند. آن‌ها عبارت بودند از:

استفاده از Cloudflare Access برای احراز هویت و دسترسی بدون اعتماد.

استفاده از Workers KV به عنوان بخشی از صفحات کنترل داخلی.

تکیه بر Turnstile برای ورود به سیستم مقاوم در برابر ربات. وبلاگ Cloudflare+1

وقتی این محصولات از کار می‌افتادند، فقط محتوای وب‌سایت نبود که از کار می‌افتاد - ورود به سیستم‌ها، توابع مدیریتی و APIهای داخلی نیز از کار می‌افتادند. این امر بازیابی را پیچیده‌تر می‌کند: صفحه وضعیت شما،

ابزارهای رخداد یا رابط کاربری ادمین نیز ممکن است به همان ارائه‌دهنده‌ای که تازه از کار افتاده است، متکی باشند.

آنچه کلودفلر می‌گوید تغییر خواهد کرد
وبلاگ کلودفلر چندین گام اصلاحی را که شرکت در حال حاضر برای کاهش خطر تکرار هر اتفاق مشابهی انجام می‌دهد، تشریح می‌کند: وبلاگ کلودفلر

مهار کردن فایل‌های پیکربندی تولید شده خودکار

با پیکربندی‌های تولید شده داخلی با همان شک و تردید و اعتبارسنجی مانند ورودی‌های ارائه شده توسط کاربر رفتار کنید، از جمله بررسی دقیق طرحواره و اندازه قبل از راه‌اندازی.

کلیدهای kill سراسری بیشتر

غیرفعال کردن سریع ماژول‌های داخلی مشکل‌ساز (مانند مدیریت ربات) در سراسر شبکه را آسان‌تر کنید، به طوری که آنها به جای ایجاد وحشت در کل مسیر پروکسی، در حالت باز از کار بیفتند.

از منابع سیستم در برابر طوفان‌های خطا محافظت کنید

اطمینان حاصل کنید که داده‌های اصلی، ابرداده‌های اشکال‌زدایی و ابزارهای مشاهده‌پذیری نمی‌توانند هنگام شروع به افزایش خطاها، CPU و حافظه را تحت فشار قرار دهند.

حالت‌های خرابی را در ماژول‌های پروکسی اصلی بررسی کنید

به طور سیستماتیک نحوه رفتار هر ماژول داخلی را تحت ورودی یا پیکربندی غیرمنتظره بررسی کنید و به جای خرابی سراسری، از تخریب مناسب اطمینان حاصل کنید.

اصلاح روندها و ایزوله‌سازی
اگرچه جزئیات زیادی در این مورد ذکر نشده است، اما این حادثه نشان می‌دهد که Cloudflare احتمالاً نحوه انتشار پیکربندی‌های جدید و رفتارهای پایگاه داده را بیشتر بخش‌بندی خواهد کرد تا احتمال تأثیر یک تغییر بد بر کل ناوگان را کاهش دهد.

آنها همچنین این حادثه را به عنوان یک شکست مطلق در انتظارات تاب‌آوری خود مطرح کردند و آن را "غیرقابل قبول" خواندند و صریحاً به دردی که هم برای مشتریان و هم برای کاربران عادی اینترنت ایجاد کرده است، اذعان کردند. وبلاگ Cloudflare

درس‌هایی برای تیم‌های زیرساخت و SRE

حتی اگر چیزی به بزرگی Cloudflare را اجرا نمی‌کنید، درس‌های طراحی و عملیاتی بسیار کاربردی در این قطعی وجود دارد:

با پیکربندی داخلی مانند ورودی‌های غیرقابل اعتماد رفتار کنید

به راحتی می‌توان فرض کرد که پیکربندی تولید شده "خودمان" همیشه درست است. دیروز نشان می‌دهد که چرا این خطرناک است:

همیشه اندازه، شکل و محدودیت‌های فایل‌های پیکربندی را قبل از اعمال آنها اعتبارسنجی کنید.

ابتدا اعمال پیکربندی به صورت قناری را برای زیرمجموعه کوچکی از ترافیک یا گره‌ها در نظر بگیرید و در صورت بروز ناهنجاری‌ها، به طور خودکار آنها را برگردانید.

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

طراحی برای خرابی جزئی مناسب
یک اشکال در ماژول مدیریت ربات نباید بتواند کل مسیر پروکسی را دچار اختلال کند:

در برخی از لایه‌های امنیتی، وقتی گزینه جایگزین، قطعی کامل است، پیش‌فرض به حالت باز-باز در مقابل بسته-بسته است.

برای ویژگی‌های غیر اصلی، سوئیچ‌های kill واضح و آزمایش‌شده بسازید.

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

سیگنال‌های صحیح را مشاهده کنید
نوسان بین "پیکربندی خوب" و "پیکربندی بد" هر پنج دقیقه باعث می‌شد سیگنال مانند ترافیک حمله یا رفتار خارجی پر سر و صدا به نظر برسد:

مطمئن شوید که همبستگی هر نسخه یا هر پیکربندی را در خط لوله مشاهده‌پذیری خود دارید.

داشبوردهایی بسازید که تغییرات پیکربندی را از نظر بصری در بالای نمودارهای خطا آشکار می‌کنند.

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

تمام تخم‌مرغ‌هایتان را در یک سبد مادون قرمز قرار ندهید

برای سازمان‌هایی که از Cloudflare استفاده می‌کنند:

برای ویژگی‌های واقعاً حیاتی، تنظیمات چند CDN را در نظر بگیرید.

از وابسته کردن کامل صفحه وضعیت خود به همان ارائه‌دهنده پشته اصلی خود خودداری کنید (Cloudflare این کار را انجام می‌دهد، اما دیروز مشکلی تصادفی با میزبان صفحه وضعیت آنها وجود داشت که اوضاع را پیچیده‌تر کرد). وبلاگ Cloudflare+1

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

تصویر بزرگتر
تنها در چند ماه گذشته، شاهد قطعی‌های عمده در Microsoft Azure، Amazon Web Services و اکنون Cloudflare بوده‌ایم که همگی به طور موقت بخش‌های بزرگی از خدمات مصرفی و سازمانی را آفلاین کرده‌اند. AP News+2 واشنگتن پست+2

الگو واضح است:

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

قطعی‌ها اغلب خودخواسته هستند و از تغییرات پیچیده داخلی ناشی می‌شوند تا حملات خارجی.

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

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

برای کاربران، این حادثه بیشتر به عنوان «آن روز صبح که X و ChatGPT بارگذاری نشدند» به یاد خواهد ماند.

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