Cloudflare در 13 جولای 2026 لایه تشخیص ربات جدیدی به نام Precursor را معرفی کرد. رویکرد Precursor با کنترلهای آشنای قبلی فرق دارد: بهجای آزمایش یکباره بازدیدکننده در دروازه ورود، رفتار او را در طول گشتوگذار در سایت پیوسته ارزیابی میکند. در این نوشته میبینید Precursor چه کاری انجام میدهد، از محافظتهای پیشین کجا جدا میشود، صاحبان سایت چگونه آن را فعال میکنند و برای تیمهایی که از اتوماسیون مرورگر استفاده میکنند چه معنایی دارد.
Cloudflare چرا به لایه جدیدی نیاز داشت؟
محافظتهای کلاسیک ربات روی لحظههای خاصی تمرکز دارند: صفحه ورود، فرم ثبتنام، مرحله پرداخت. بازدیدکننده در همین نقطه یک CAPTCHA را رد میکند یا از یک بررسی JavaScript تأیید میگیرد و راهش را ادامه میدهد.
طبق مشاهده متن اعلان Cloudflare، اتوماسیون امروزی توانسته از پس این آزمونهای کوتاه بربیاید: رباتها JavaScript اجرا میکنند، محیط مرورگر واقعی به کار میبرند و میتوانند تکتک CAPTCHAها را بدون برانگیختن شک رد کنند. نتیجهگیری Cloudflare این است: انساننما بودن در لحظههای کوتاه آسان شده، اما نشان دادن رفتار انسانی پایدار در طول زمان هنوز دشوار است.
این تغییر، جهت کلی تشخیص ربات را هم نشان میدهد. ابتدا به اعتبار IP نگاه میشد؛ پروکسیها از آن عبور کردند. سپس به محیط مرورگر نگاه شد؛ مرورگرهای واقعی و ابزارهای ضدشناسایی از آن هم عبور کردند. حالا نوبت به ثبات رفتار در طول زمان رسیده است.
لایههای محافظتی فعلی Cloudflare
برای جای درست دادن به Precursor، باید لایههایی را که Cloudflare هنگام محافظت از یک سایت به کار میبرد به یاد آورد:
| لایه | چه میکند؟ | چه زمانی فعال میشود؟ |
|---|---|---|
| اعتبار IP و قواعد WAF | آدرسهای شناختهشده مخرب و الگوهای درخواست را مسدود میکند | در هر درخواست، سمت سرور |
| امتیاز ربات | با هدرهای درخواست، اثر انگشت TLS و یادگیری ماشین امتیازی بین 1 تا 99 تولید میکند | در هر درخواست |
| JavaScript Detections | واقعی بودن مرورگر را سمت کلاینت میسنجد | هنگام بارگذاری صفحه، یکباره |
| Turnstile / Managed Challenge | به بازدیدکننده یک تأیید نمایان یا نامرئی ارائه میدهد | وقتی آستانه شک رد شود |
| Precursor | رفتار تعامل را در طول نشست ارزیابی میکند | پس از بارگذاری صفحه، پیوسته |
همانطور که در جدول دیده میشود، کنترلهای سمت کلاینت پیش از Precursor یکباره بودند. Precursor این خلأ را پر میکند.
Precursor چگونه کار میکند؟
طبق مستندات توسعهدهنده Cloudflare، Precursor سامانهای است که سمت کلاینت اجرا میشود و در طول نشست اعتبارسنجی انجام میدهد. در اعلان سه بخش توصیف شده است:
- لایه جمعآوری. Cloudflare یک اسکریپت کوچک به پاسخ HTML سایت اضافه میکند. صاحب سایت نیازی به تغییر کد ندارد. این اسکریپت سیگنالهای تعاملی مانند حرکت اشارهگر، فعالیت صفحهکلید، تغییر فوکوس و نمایان بودن یا نبودن صفحه را گوش میدهد. طبق اعلان، محتوای تایپشده روی صفحهکلید نه، بلکه زمانبندی تایپ ارزیابی میشود.
- لایه ارزیابی. سیگنالها در سرورهای لبه Cloudflare از چند ارزیاب میگذرند و بهصورت متقاطع بررسی میشوند. برای نمونه، اگر وقتی صفحه در پسزمینه است حرکت اشارهگر بیاید، این یک ناسازگاری است.
- یکپارچگی نشست. نتایج در طول نشست انباشته میشوند. نکتهای که اعلان بر آن تأکید میکند این است: یک ربات نمیتواند با تازهسازی صفحه یا شروع یک تأیید جدید، تاریخچه رفتاری خود را بازنشانی کند.
نتایج ارزیابی در کوکی cf_clearance بازدیدکننده منعکس میشود. طبق مستندات، اگر رفتار در طول نشست مشکوک شود، اثر مجوز دسترسی قبلاً صادرشده ممکن است کاهش یابد یا باطل شود.
چه سیگنالهایی ارزیابی میشوند؟
اعلان و مستندات سیگنالها را تکتک فهرست نمیکنند، اما دستهبندیهای توصیفشده از این قرارند:
- حرکت اشارهگر: اینکه سرعت، شتاب و تغییرات جهت شبیه حرکت انسان است یا نه. اشارهگر انسان در خط راست و با سرعت ثابت حرکت نمیکند.
- زمانبندی صفحهکلید: توزیع فاصلههای زمانی بین کلیدها. محتوا نه، بلکه ریتم ارزیابی میشود.
- فوکوس و نمایان بودن: اینکه صفحه در تب فعال است یا نه، پنجره فوکوس دارد یا نه. اگر در تبی که در پسزمینه است تعامل بیاید، تناقض وجود دارد.
- رابطه تعامل با درخواستهای شبکه: اینکه آیا پس از یک کلیک، درخواست موردانتظار میآید یا نه، و آیا درخواستها بدون کلیک تولید میشوند یا نه.
- پایداری در طول زمان: اینکه آیا سیگنالهای بالا در طول نشست همان «شخصیت» را حفظ میکنند یا نه.
این فهرست توضیح میدهد چرا Precursor را نمیتوان با یک کنترل تنها رد کرد: تولید یک حرکت لحظهای شبیه انسان آسان است؛ تولید رفتاری پایدار در طول دقایق آسان نیست.
آیا جای CAPTCHA و Turnstile را میگیرد؟
خیر. Cloudflare جایگاه Precursor را مکمل تأییدهای موجود تعریف میکند. طبق مستندات، Precursor کمک میکند تصمیم بگیرد چه زمانی به تأیید اضافی نیاز است و بازدیدکنندهای را که یک تأیید را رد کرده، پس از آن هم دوباره ارزیابی میکند. با فعال شدن Precursor، ویژگی قدیمی JavaScript Detections بهطور خودکار غیرفعال میشود.
| تأیید کلاسیک | Precursor | |
|---|---|---|
| چه زمانی بررسی میکند؟ | در لحظههای خاص | در طول نشست |
| به چه چیزی نگاه میکند؟ | محیط مرورگر، آزمون یکباره | پایداری رفتار تعامل در طول زمان |
| قابل بازنشانی است؟ | با تلاش جدید | در محدوده نشست انباشته میشود |
| کاربر میبیند؟ | اگر CAPTCHA ظاهر شود | بسته به حالت انتخابی، در بیشتر موارد خیر |
| نیاز به تغییر کد صاحب سایت | برای Turnstile بله | خیر، اسکریپت خودکار اضافه میشود |
صاحبان سایت چگونه Precursor را فعال میکنند؟
Precursor بهطور پیشفرض فعال نیست؛ صاحب سایت باید آن را روشن کند. طبق مستندات، این تنظیم در پنل Cloudflare زیر Security > Settings انجام میشود و دو حالت ارائه میدهد:
- Minimize Friction: تأیید در پسزمینه اجرا میشود و تجربه کاربر تا حد امکان بدون وقفه نگه داشته میشود.
- Maximize Security: برای تأیید سختگیرانهتر میتوان از یک صفحه میانی سبک استفاده کرد.
نتایج در تحلیل ربات و تطبیقهای قواعد WAF در بخش Security > Analytics منعکس میشود. چون اینکه در کدام پلنها و با چه شرایطی ارائه میشود ممکن است در طول زمان تغییر کند، باید اطلاعات بهروز را از مستندات Cloudflare دنبال کرد.
اگر سایت خودتان را با Cloudflare محافظت میکنید، پیش از فعال کردن Precursor بهتر است دو چیز را بررسی کنید: اتوماسیون مشروع سایتتان (ابزارهای پایش، اسکریپتهای تست خودتان، یکپارچهسازیهای شرکای شما) و اینکه آیا این ترافیک را با قواعد WAF معاف کردهاید یا نه. در غیر این صورت ابزارهای خودتان هم «غیرانسانی» ارزیابی میشوند.
برای اتوماسیون مرورگر چه چیزی تغییر میکند؟
در سایتی که Precursor روی آن فعال است، اتوماسیون انجامشده با مرورگر بدون رابط گرافیکی دیگر فقط در نقطه ورود نه، بلکه در کل نشست ارزیابی میشود. این چند پیامد عملی دارد:
- رویکرد «عبور» یکباره کارساز نیست. نشستی که تأیید را در اولین صفحه رد کرده، اگر در صفحات بعدی الگویی غیرانسانی نشان دهد ممکن است دسترسیاش را از دست بدهد.
- تازهسازی صفحه، صفحهای پاک باز نمیکند. تاریخچه رفتار در محدوده نشست انباشته میشود.
- IP بهتنهایی تعیینکننده نیست. یک آدرس IP با اعتبار خوب، اگر سیگنالهای رفتاری ناسازگار باشد، نشست را نجات نمیدهد. نقش اثر انگشت مرورگر را در اثر انگشت مرورگر چیست؟ توضیح دادیم.
- گشتوگذار بدون تعامل مشکوک است. نشستی که بدون هیچ حرکت اشارهگری از صفحهای به صفحه دیگر میرود و هیچوقت اسکرول نمیکند، شبیه یک بازدیدکننده معمولی نیست.
لازم است روی یک نکته تأکید شود: توسعه ابزارهایی که رفتار انسانی را تقلید میکنند تا Precursor دور زده شود، یعنی هدف قرار دادن محافظتی که صاحب سایت آگاهانه فعال کرده است. این هم میتواند با شرایط استفاده سایت و هم با قوانین بسیاری از کشورها در تضاد باشد.
راه درست برای اتوماسیون مشروع
پیام Precursor برای تیمهایی که با هدف جمعآوری داده، تست یا پایش کار میکنند روشن است: بهجای رقابت با لایههای محافظتی، گرفتن رضایت سایت پایدارتر است.
- APIهای رسمی را ترجیح دهید. بسیاری از پلتفرمها داده موردنیاز را از راه API ارائه میدهند. API هم سریعتر است و هم اصلاً وارد ارزیابی رفتاری نمیشود.
- با صاحب سایت هماهنگ شوید. اگر سایت خودتان یا سایت مشتریتان را تست میکنید، صاحب سایت میتواند ترافیک تست را از قواعد WAF معاف کند. این تمیزترین راه برای کار بیدردسر اتوماسیون حتی با فعال بودن Precursor است.
- برنامههای ربات تأییدشده را بررسی کنید. رباتهای شناختهشدهای مانند خزندههای موتور جستجو با مکانیزم ربات تأییدشده Cloudflare شناسایی میشوند. اگر خزندهای در خدمت عموم اداره میکنید، درخواست عضویت در این برنامه ممکن است.
- سرعت معقول و هویت شفاف. هنگام جمعآوری داده عمومی، سرعت درخواست را پایین نگه دارید، از قواعد
robots.txtپیروی کنید و ازUser-Agentای استفاده کنید که خودتان را معرفی کند. - راههایی را بجویید که به مرورگر نیاز ندارند. اگر داده صفحه از یک نقطه پایانی JSON میآید، ارسال مستقیم درخواست به آن نقطه پایانی هم از اتوماسیون مرورگر ارزانتر است و هم مستقل از لایه رفتاری.
زیرساخت پروکسی در این چارچوب هم اهمیت خودش را حفظ میکند: برای دیدن محتوایی که بر اساس موقعیت تغییر میکند از منطقه درست، برای اینکه ترافیک را روی یک آدرس تنها انباشته نکنید و برای پخش متعادل بار خزنده وب لازم است. در هدفهای محافظتشده، پروکسی مسکونی با آدرسهای کاربر واقعی و پروکسی با نشست ثابت که همان آدرس را در طول نشست حفظ میکند، بخشی از این نظم هستند. اما پروکسی ابزاری نیست که محافظت رفتاریای را که یک سایت آشکارا برپا کرده مشروع کند. اینکه چه دادهای تحت چه شرایطی قابل جمعآوری است را در آیا اسکرپینگ وب قانونی است؟ بررسی کردیم.
روند کلیای که Precursor نشان میدهد
Precursor فراتر از یک محصول تنها، جهتی را نشان میدهد که تشخیص ربات به سمت آن میرود. سه نتیجهگیری میتوان کرد:
- سیگنالهای ثابت ارزش خود را از دست میدهند. سیگنالهای خواندهشده در یک لحظه مانند نوع IP،
User-Agentو محیط مرورگر هنوز استفاده میشوند، اما بهتنهایی تصمیمساز نیستند. - نشست به واحد اندازهگیری تبدیل میشود. ارزیابی بهازای هر درخواست نه، بلکه بهازای هر نشست انجام میشود. این یعنی راهبرد «IP متفاوت در هر درخواست» ممکن است در برخی هدفها نتیجه معکوس بدهد؛ تغییر IP در میانه یک نشست میتواند ناسازگاری شمرده شود.
- شفاف بودن هویت اتوماسیون مشروع اهمیت بیشتری پیدا میکند. برنامههای ربات تأییدشده و هماهنگی با صاحب سایت، در مقایسه با اتوماسیون پنهان، به راهی قابلاعتمادتر تبدیل میشوند.
این روند مخصوص Cloudflare نیست؛ رویکردهای رفتاری مشابه در دیگر ارائهدهندگان محافظت هم دیده میشود. هنگام برنامهریزی زیرساخت اتوماسیون، پرسیدن «محافظت به کدام سمت میرود» بهجای «امروز چه کنترلی وجود دارد» تصمیمهایی بادوامتر میدهد.
سؤالات متداول
آیا Precursor روی همه سایتهای Cloudflare کار میکند؟
خیر. ویژگیای اختیاری است که صاحب سایت باید از پنل فعالش کند.
آیا Precursor داده شخصی جمعآوری میکند؟
طبق اعلان Cloudflare، اسکریپت سیگنالهای تعاملی را جمع میکند؛ در سمت صفحهکلید محتوای فشردهشده نه، بلکه زمانبندی را ارزیابی میکند. توضیح این پردازش به بازدیدکنندگان سایت در سیاست حریم خصوصی، مسئولیت صاحب سایت است.
آیا ابزارهایی مانند Undetected ChromeDriver در برابر Precursor کارساز است؟
اینگونه ابزارها روی کاهش ردهای شناختهشده اتوماسیون در محیط مرورگر تمرکز دارند. اما Precursor چون به پایداری رفتار در طول نشست نگاه میکند، در لایهای متفاوت کار میکند. محدودیتهای کلی این ابزارها را در Undetected ChromeDriver توضیح دادیم.
چگونه بفهمم سایتی از Precursor استفاده میکند؟
از بیرون روش قطعیای وجود ندارد. در سایتی که پشت Cloudflare است، تنگ شدن دسترسی یا درخواست تأیید اضافی در صفحات بعدی، پس از عبور از نقطه ورود، میتواند نشانه باشد. اگر صاحب سایت هستید، از پنل میتوانید ببینید.
آیا Precursor کاربران واقعی را بهاشتباه مسدود میکند؟
Cloudflare میگوید حالت Minimize Friction برای پایین نگهداشتن این ریسک طراحی شده است. با این حال برای ابزارهای دسترسپذیری، کاربران وابسته به صفحهکلید و دستگاههای غیرمعمول، صاحب سایت باید موارد مثبت کاذب را از صفحه تحلیل خود پایش کند.
هنگام کار با Puppeteer در سایت دارای Precursor چه کنم؟
اول ببینید سایت API ارائه میدهد یا نه؛ سپس با صاحب سایت تماس بگیرید. اگر اتوماسیون الزامی است، سرعت را پایین بیاورید، نشست را حفظ کنید و روی یک IP بمانید؛ این مراحل را در Puppeteer و CAPTCHA توضیح دادیم. روی آوردن به ابزارهایی که رفتار را تقلید میکنند هم شکننده است و هم پرریسک.
خلاصه
Cloudflare Precursor تشخیص ربات را از آزمونهای یکباره به ارزیابیای که در طول نشست ادامه دارد منتقل میکند. بسته به انتخاب صاحب سایت فعال میشود، مکمل تأییدهای موجود است و با تازهسازی صفحه بازنشانی نمیشود. مطمئنترین راهبرد برای تیمهایی که با اتوماسیون کار میکنند، تلاش برای دور زدن محافظت نیست؛ ساختن نظمی برای جمعآوری داده مبتنی بر API، اجازه و ترافیک معقول است. در این نظم، پروکسی ابزار دور زدن محافظت نیست، بلکه ابزار مدیریت ترافیک از منطقه درست و بهشکلی متعادل است.
