بازگشت به وبلاگ

۸۹.۶٪ سایت‌های اروپایی با CDN — به خاطر Cloudflare: چه خطراتی در فرهنگ تک‌محصولی وجود دارد؟

7 سپتامبر 2026، CipherCue تعداد 44,143 شرکت اروپایی را با CDN شناسایی شده اندازه‌گیری کرد: 89.6% از آن‌ها متعلق به Cloudflare هستند، در هلند — 95.6%. ما اعداد و روش‌ها را بررسی می‌کنیم، با داده‌های W3Techs مقایسه می‌کنیم، توضیح می‌دهیم که چرا امتیاز bot واحد بر روی 46 میلیون درخواست در ثانیه قوانین کار با استخرهای آدرس را تغییر می‌دهد، و چه کار باید کرد زمانی که یک ارائه‌دهنده — نقطه شکست مشترک برای مسدودسازی‌ها و حوادث است.

📅۱۸ شهریور ۱۴۰۵
۸۹.۶٪ سایت‌های اروپایی با CDN — به خاطر Cloudflare: چه خطراتی در فرهنگ تک‌محصولی وجود دارد؟

۷ سپتامبر ۲۰۲۶ سال، محققان CipherCue گزارشی منتشر کردند که برای همه کسانی که به صورت خودکار به وب اروپایی مراجعه می‌کنند، خواندن آن ضروری است: از ۴۴,۱۴۳ شرکت اروپایی که توانستند CDN را شناسایی کنند، ۸۹.۶٪ در پشت Cloudflare نشسته‌اند. نه «رهبر بازار با فاصله زیاد» — بلکه تقریباً کل بازار. برای اسکرپینگ، چند حساب کاربری و هر نوع اتوماسیون، این به معنای یک چیز ساده است: دسترسی به نه سایت از ده در اتحادیه اروپا توسط یک الگوریتم مشابه، با همان نشانه‌ها، در یک ثانیه مشابه انجام می‌شود.

چه چیزی دقیقاً محاسبه شده است

نمونه‌برداری — شرکت‌هایی از آلمان، بریتانیا، هلند، لهستان، فرانسه، ایتالیا، اسپانیا و ایرلند که در وب‌سایتشان حداقل یک مؤلفه CDN شناسایی شده است. شناسایی از طریق پاسخ‌های HTTP و اثر انگشت سرور انجام شد: هدر cf-ray و server: cloudflare برای Cloudflare، x-served-by با نشانگر کش برای Fastly، x-amz-cf-id برای CloudFront. تاریخ مشاهدات — ۷ سپتامبر ۲۰۲۶.

تقسیم‌بندی بر اساس ارائه‌دهندگان:

  • Cloudflare — ۳۹,۵۴۷ شرکت (۸۹.۶٪)
  • Amazon CloudFront — ۳,۱۱۲
  • Fastly — ۱,۲۹۹
  • Akamai — ۳۹۶

بر اساس کشورها، پراکندگی قابل توجهی وجود دارد، اما سقف در همه جا بالا است:

  • هلند — ۹۵.۶٪ (۷,۵۸۷ از ۷,۹۳۹)
  • بریتانیا — ۹۳.۲٪ (۱۵,۸۴۶ از ۱۷,۰۰۷)
  • لهستان — ۹۲.۶٪ (۲,۶۸۲ از ۲,۸۹۶)
  • فرانسه — ۸۶.۲٪ (۳,۴۵۶ از ۴,۰۰۸)
  • ایتالیا — ۸۵.۴٪ (۳,۱۲۶ از ۳,۶۶۱)
  • آلمان — ۸۱.۴٪ (۴,۶۵۰ از ۵,۷۱۵)
  • اسپانیا و ایرلند — هر کدام ۷۸.۸٪

نویسندگان خودشان محدودیت‌ها را ذکر می‌کنند و این صادقانه است: یک شرکت ممکن است تحت چندین ارائه‌دهنده قرار گیرد (حساب‌داری دوگانه)، و نمونه‌برداری به سمت کسب‌وکارهای کوچک و متوسط متمایل است — بخشی که در آن تعرفه رایگان Cloudflare بیشترین تأثیر را دارد. به عبارت دیگر، ۸۹.۶٪ — این سهم در میان شرکت‌هایی با CDN شناسایی شده است، نه در میان تمام اشخاص حقوقی اروپایی.

یک بررسی مستقل از مقیاس‌ها وجود دارد: بر اساس داده‌های W3Techs در سپتامبر ۲۰۲۶، Cloudflare ۸۴.۷٪ وب‌سایت‌ها را که به طور کلی معکوس پروکسی شناخته شده‌اند، استفاده می‌کند — که این معادل ۲۵.۲٪ از تمام وب‌سایت‌ها در فهرست آن‌ها است. روش‌های مختلف، نمونه‌برداری‌های مختلف، اما نتیجه یکی است: در برابر یک چهارم وب و در برابر اکثریت قریب به اتفاق نصب‌های CDN شناسایی شده، یک واسطه وجود دارد.

چرا برای اتوماسیون این فقط «سهم بازار» نیست

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

Cloudflare به درخواست امتیاز ربات از ۱ تا ۹۹ می‌دهد: هرچه پایین‌تر، اطمینان بیشتری وجود دارد که در مقابل وب‌سایت اتوماسیون قرار دارد. مدلی که این امتیاز را محاسبه می‌کند، بر اساس توصیف خود شرکت، بیش از ۴۶ میلیون درخواست HTTP در ثانیه را پردازش می‌کند و نه تنها درخواست خاص شما، بلکه آمار جهانی در کل شبکه را نیز در نظر می‌گیرد: شهرت IP، ASN و نوع آدرس (مرکز داده / مسکونی / موبایل)، سازگاری هدرها، اثر انگشت TLS، نشانه‌های رفتاری. شناسایی لایه‌ای است — هوریستیک به علاوه ML، و بخش عمده‌ای از تصمیمات به یادگیری ماشین مربوط می‌شود.

نتیجه عملی: استخر شما و اثر انگشت شما توسط شبکه ارزیابی می‌شود، نه وب‌سایت. اگر در یک منبع شناسایی شده‌اید — سیگنال شهرت در درخواست بعدی به منبع دیگر در نظر گرفته شده است. در دنیایی که در این شبکه نه از ده وب‌سایت اروپایی نشسته‌اند، «تغییر به هدف دیگر و صبر کردن» دیگر یک استراتژی نیست.

IP مسکونی دیگر مجوزی نیست

منطق قدیمی «آدرس مسکونی را گرفتی — مثل یک انسان عبور کردی» به این واقعیت برخورد می‌کند که ارائه‌دهنده فیلتر مدت‌هاست که این روش را شناسایی کرده است. Cloudflare به طور عمومی مدلی جداگانه برای ربات‌هایی که از طریق پروکسی‌های مسکونی می‌آیند، توصیف کرده است: ابتدا نشانه‌های شبکه (پرش‌های اضافی، تأخیر) را امتحان کردند، اما به دلیل اشتباهات کاذب در اینترنت ماهواره‌ای از آن صرف‌نظر کردند و به تجزیه و تحلیل رفتاری — نوسانات فعالیت در آدرس‌های IP — روی آوردند. در انتشار خودشان مقیاس پدیده‌ای که می‌بینند را ذکر کرده‌اند: حدود ۱۷ میلیون IP منحصر به فرد در ساعت که در حملات از طریق پروکسی‌های مسکونی استفاده می‌شوند، ۴۵ هزار ASN و ۲۳۷ کشور و منطقه (این اعداد مربوط به مارس ۲۰۲۴ است و شرکت عدد جدیدتری ارائه نکرده است). دقت اعلام شده برای طبقه‌بندی حمله توزیع شده به یکی از مشتریان — ۹۵٪، افزایش شناسایی ربات‌ها از شبکه‌های ابری — ۲۰٪.

جزئیات مهم از همان جا: مدل به عمد بر اساس مسدود کردن IP ساخته نمی‌شود — تا کاربران واقعی را از همان شبکه‌ها حذف نکند. این خبر خوبی برای ترافیک واقعی از آدرس‌های مسکونی است و خبر بدی برای کسانی است که امیدوارند «خانه» به تنهایی چراغ سبز بدهد. آنچه کار می‌کند نوع آدرس نیست، بلکه ترکیب «نوع آدرس + رفتار + اثر انگشت» است. تجزیه و تحلیل دقیق تفاوت‌ها بین دیوارها را در مقایسه سیستم‌های ضد ربات Cloudflare، DataDome، Akamai و Kasada انجام دادیم — اکنون باید به آن با توجه به اینکه وزن‌ها در خط اول در اروپا به طرز نامتناسبی زیاد شده است، بازگردیم.

طرف دیگر: وقتی یکی سقوط می‌کند — همه سقوط می‌کنند

برای تک‌کشت‌ها یک جنبه دیگر وجود دارد، نه در مورد مسدود کردن، بلکه در مورد در دسترس بودن. یک سال و نیم گذشته سه مورد نمایشی ارائه داده است:

  1. ۱۸ نوامبر ۲۰۲۵ — اختلال جهانی که به تخمین‌ها تقریباً هر پنجم وب‌سایت و یک سوم از ۱۰,۰۰۰ وب‌سایت و سرویس محبوب را تحت تأثیر قرار داد. دلیل به گفته خود شرکت: تغییر حقوق در خوشه ClickHouse منجر به تکرار سطرها در فایل نشانه‌ها شد که توسط مدل ML برای امتیازدهی ربات‌ها استفاده می‌شود. این یک پارادوکس است: مکانیزمی که تصمیم می‌گیرد شما انسان هستید یا نه، بخش قابل توجهی از اینترنت را از کار انداخت.
  2. ۵ دسامبر ۲۰۲۵ — اختلال از ساعت ۸:۴۷ UTC به مدت تقریباً ۲۵ دقیقه که بخشی از مشتریان را تحت تأثیر قرار داد که حدود ۲۸٪ از کل ترافیک HTTP که از طریق شبکه عبور می‌کرد، مربوط به آن‌ها بود.
  3. ۲۰ فوریه ۲۰۲۶ — در ساعت ۱۷:۴۸ UTC، برای بخشی از مشتریان که از BYOIP (محدوده‌های IP خود) استفاده می‌کنند، مسیرها به دلیل تغییر در فرآیند ورود آدرس‌ها از BGP لغو شدند.

بیان نویسندگان تحقیق در اینجا دقیق است: وقتی یک ارائه‌دهنده در برابر بخش عمده‌ای از بازار قرار دارد، اشتباهات او دیگر مشکل او نیست و به مشکل همه به طور همزمان تبدیل می‌شود. برای خط لوله جمع‌آوری داده‌ها، این به این معنی است که «وب‌سایت هدف سقوط کرده» و «کل منطقه سقوط کرده» اکنون به سختی قابل تفکیک است — و هشدارهایی که برای دامنه خاص تنظیم شده‌اند، دروغ می‌گویند.

چه کار باید کرد به طور عملی

در زیر — آنچه واقعاً در فرآیند کاری تغییر می‌کند، اگر تک‌کشت فیلتر را به عنوان یک واقعیت بپذیرید.

  1. ترکیب را در یک وب‌سایت تست نکنید. اگر اثر انگشت شما در سه منبع عبور می‌کند — احتمالاً شما یک فیلتر مشابه را سه بار بررسی کرده‌اید. یک منبع از CloudFront، یک منبع از Fastly، یک منبع از Akamai و بدون CDN را در مجموعه تست خود بگنجانید، در غیر این صورت نمونه‌برداری چیزی را اثبات نمی‌کند.
  2. استخرها را بر اساس پروژه‌ها تقسیم کنید، نه بر اساس وب‌سایت‌ها. از آنجا که شهرت توسط شبکه ارزیابی می‌شود، «استخر جداگانه برای هر دامنه» هیچ چیز را ایزوله نمی‌کند. ایزوله‌سازی در سطح پروژه و پروفایل معنا دارد: یک پروژه — استخر آدرس‌های خود، مجموعه اثر انگشت‌های خود، ریتم خود.
  3. به نوع و منبع آدرس توجه کنید. ASN و دسته آدرس — ورودی مستقیم به امتیازدهی هستند. برای اهداف حساس، پروکسی‌های مسکونی و آدرس‌های موبایل معقول هستند؛ وظایف فنی انبوه (بررسی در دسترس بودن، API‌های خود، کار با پلتفرم‌ها بدون ضد ربات سخت) ارزان‌تر و عادلانه‌تر است که با پروکسی‌های مرکز داده بسته شوند، بدون اینکه ترافیک گران‌قیمت را بیهوده هدر دهید.
  4. زیرشبکه را نسوزانید. مدل‌های رفتاری نوسانات فعالیت در آدرس را شناسایی می‌کنند. ریتم یکنواخت در یک استخر وسیع بهتر از یک شلیک کوتاه و تهاجمی از یک استخر باریک امتیاز می‌گیرد.
  5. اثر انگشت را به طور کامل مرتب کنید. اثر انگشت TLS، ترتیب و ترکیب هدرها، نسخه HTTP، رفتار JS — به طور مشترک ارزیابی می‌شوند. IP مسکونی با اثر انگشت یک کلاینت HTTP عاری از جزئیات نتیجه بدتری نسبت به یک آدرس مرکز داده مرتب با استک مرورگر معتبر می‌دهد.
  6. «ما مسدود شدیم» و «آن‌ها دچار مشکل شدند» را جدا کنید. قانون ساده: در صورت افزایش خطاهای انبوه، ابتدا بررسی کنید که آیا همه چیز به طور همزمان در چندین هدف غیر مرتبط سقوط کرده است و وضعیت صفحه ارائه‌دهنده چه چیزی را نشان می‌دهد. تلاش مجدد در زمان اختلال جهانی — راهی برای سوزاندن استخر در یک مکان است.
  7. یک برنامه B داشته باشید برای روزی که فیلتر سقوط کند. صف وظایفی که می‌تواند منتظر بماند و نقص‌های از دست رفته را جبران کند، در توسعه گران‌تر است، اما ۲۵ دقیقه عدم دسترسی را بدون از دست دادن داده‌ها تحمل می‌کند.

نتیجه‌گیری

عدد ۸۹.۶٪ — نه درباره این است که Cloudflare بد است، و نه درباره این است که وب اروپایی بسته شده است. این درباره این است که تنوع اهداف دیگر به معنای تنوع موانع نیست. یک امتیازدهی، یک مدل، یک پایگاه داده شهرت — و در نتیجه، یک حالت مشترک از شکست: هم زمانی که شما به عنوان ربات شناسایی می‌شوید و هم زمانی که خود ارائه‌دهنده مسیرها را سقوط می‌دهد.

نتیجه برای عمل خسته‌کننده است، اما کارآمد: بهینه‌سازی دور زدن «برای وب‌سایت» را متوقف کنید و شروع به بهینه‌سازی رفتار کنید — کیفیت آدرس‌ها، ریتم یکنواخت، اثر انگشت سازگار، تشخیص دقیق خطاها. این تنها چیزی است که به طور یکسان در هر دو طرف ۸۹.۶٪ خوب کار می‌کند.