تشخیص بات چگونه کار می‌کند؟ منطق سامانه‌های ضدبات

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

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

تشخیص بات چیست؟#

تشخیص بات کار جداکردن این است که درخواست رسیده به یک سایت از مرورگری که انسان به کار می‌برد آمده یا از یک برنامه خودکار. نرم‌افزاری که این کار را انجام می‌دهد سامانه ضدبات، حفاظت در برابر بات یا مدیریت بات نامیده می‌شود؛ بیشتر آن نه در کد خود سایت، بلکه در CDN یا دیوار آتش برنامه وب (WAF) جلوی آن اجرا می‌شود. Cloudflare، Akamai و DataDome نام‌هایی هستند که در این حوزه پرتکرارند. سامانه دنبال پاسخ دو پرسش است: آیا درخواست خودکار است و اگر هست، از نوع خواسته‌شده است؟

ترافیک بات چیست: بات خوب از بات بد چگونه جدا می‌شود؟#

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

• بات‌هایی که سایت می‌خواهد. خزنده‌های موتور جست‌وجو، سرویس‌هایی که در دسترس بودن سایت را پایش می‌کنند، پیام‌رسان‌هایی که پیش‌نمایش پیوند می‌سازند و خودکارسازی آزمون خود سایت.
• بات‌هایی که سایت می‌سنجد. سرویس‌های مقایسه قیمت، ابزارهای بایگانی، خزنده‌های هوش مصنوعی و اسکریپت‌های پژوهشی. برخی سایت‌ها در را باز می‌کنند و برخی با محدودیت سرعت می‌پذیرند.
• خودکارسازی‌ای که سایت نمی‌خواهد. پروژه تهدیدهای خودکار OWASP این گروه را با نام‌گذاری فهرست می‌کند: آزمودن انبوه رمزهای دزدیده‌شده (credential stuffing)، وارسی شماره کارت‌های دزدیده‌شده (carding)، جمع‌کردن خودکار موجودی محدود (scalping) و کپی انبوه محتوا (scraping) در این فهرست‌اند.

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

یک درخواست به چه ترتیبی ارزیابی می‌شود؟#

1. اتصال می‌رسد. پیش از خوانده‌شدن هر محتوایی، IP مبدأ مشخص است؛ اعتبار، کشور و شبکه آن پرس‌وجو می‌شود.
2. دست‌دادن TLS انجام می‌شود. نخستین پیام (ClientHello) سرنخی درباره اینکه چه نرم‌افزاری سخن می‌گوید با خود دارد.
3. اتصال HTTP برقرار می‌شود. در HTTP/2 سرویس‌گیرنده تنظیمات اتصال خود را اعلام می‌کند؛ سپس روش، نشانی و هدرها می‌آیند.
4. امتیاز سمت سرور محاسبه می‌شود. سیگنال‌های سه گام نخست با تاریخچه نزدیک آن نشانی ترکیب می‌شود؛ درخواست همین‌جا هم می‌تواند رد شود.
5. صفحه به مرورگر می‌رسد. اسکریپت کوچکی در صفحه محیط مرورگر را می‌آزماید و نتیجه را بازمی‌گرداند.
6. نشست زیر نظر می‌ماند. بسامد درخواست، ترتیب گشت‌وگذار و تعامل، امتیاز را در طول نشست به‌روز می‌کند.
7. اگر از آستانه بگذرد، اقدام می‌آید. محدودیت سرعت، صفحه آزمون یا مسدودسازی.

چهار گام نخست بدون آنکه بازدیدکننده چیزی بفهمد سمت سرور می‌گذرد؛ گام پنجم و ششم تنها در سرویس‌گیرنده‌هایی که JavaScript اجرا می‌کنند داده می‌سازند.

لایه‌ها در یک جدول: هر لایه چه چیزی را می‌سنجد؟#

ستون آخر ایده اصلی نوشته را با خود دارد: هر لایه گروهی از آدم‌ها را اشتباه می‌سنجد و آستانه‌ها با آگاهی از این هزینه تنظیم می‌شوند.

لایه شبکه: اعتبار IP و ASN چه می‌گویند؟#

نشانی IP نخستین اطلاعات درباره یک درخواست است. سامانه به تاریخچه سوءاستفاده از آن نشانی، به کشور آن و از راه ASN (شماره سیستم خودمختار) به اینکه در کدام شبکه ثبت شده نگاه می‌کند. درخواستی که از شبکه یک شرکت میزبانی می‌آید با درخواستی که از بلوکی می‌آید که یک اپراتور برای مشترکان خانگی کنار گذاشته، یکسان دیده نمی‌شود: کاربران خانگی از مرکز داده به اینترنت نمی‌روند. اینکه سایت‌ها یک نشانی را چگونه «اپراتور» یا «میزبانی» دسته‌بندی می‌کنند در تفاوت پروکسی ISP و پروکسی خانگی آمده است.

اعتبار از دو منبع می‌آید: فهرست‌های سیاه که ثبت می‌کنند آیا آن نشانی پیش‌تر به‌عنوان منبع هرزنامه یا حمله گزارش شده است (فهرست سیاه IP) و سرویس‌های امتیاز خطر که نوع نشانی و پروکسی یا VPN بودن خروجی آن را به یک عدد فرو می‌کاهند (IP Fraud Score). ضعف این لایه آن است که نه شخص، بلکه نشانی را می‌سنجد. اپراتورهای همراه و بسیاری از ارائه‌دهندگان، شمار زیادی مشترک را پشت یک نشانی می‌گذارند (CGNAT)؛ اسکریپتی که از آنجا کار کند اعتبار همه کسانی را که آن نشانی را به اشتراک گذاشته‌اند پایین می‌آورد.

لایه پروتکل: اثر انگشت TLS و تنظیمات ⁦HTTP/2⁩#

در نخستین پیام یک اتصال HTTPS، سرویس‌گیرنده مجموعه‌های رمزنگاری پشتیبانی‌شده، افزونه‌ها و ترتیب آن‌ها را آشکارا می‌فرستد. این فهرست از مرورگری به مرورگر دیگر و از کتابخانه‌ای به کتابخانه دیگر فرق می‌کند؛ وقتی سرور آن را به خلاصه‌ای کوتاه تبدیل کند (⁦JA3⁩ و ⁦JA4⁩ قالب‌های رایج‌اند)، نشانه‌ای مستقل از هدرها در دست دارد. درخواستی که در هدر User-Agent آن Chrome نوشته شده اما دست‌دادنش شبیه یک کتابخانه Python است، با همین ناهماهنگی جلب توجه می‌کند. جزئیات این محاسبه و مرزهای آن در اثر انگشت TLS و ⁦JA3⁩ آمده است.

⁦RFC 9113⁩ لازم می‌داند که هر دو طرف در آغاز اتصال HTTP/2 یک فریم SETTINGS بفرستند. مقدارهای این فریم و ترتیب فرستادن شبه‌هدرها (:method، :authority، :scheme، :path) در هر پشته HTTP فرق می‌کند. ارزش این لایه در مستقل بودنش از اظهار است؛ خطرش آن است که کارکنان پشت تجهیزات امنیتی سازمانی، که ترافیک TLS را باز و دوباره برقرار می‌کنند، با دست‌دادنی می‌آیند که با مرورگرشان جور درنمی‌آید.

لایه هدر: User-Agent و هماهنگی#

هدرها اظهار سرویس‌گیرنده درباره خودش است: User-Agent مرورگر و سیستم‌عامل را می‌گوید، هدرهای Client Hints (خانواده Sec-CH-UA) همان اطلاعات را ساختارمند تکرار می‌کنند و Accept-Language ترجیح زبانی را اعلام می‌کند. این اظهار را کسی وارسی نمی‌کند؛ هر برنامه‌ای می‌تواند هر مقداری بنویسد. اینکه این رشته چگونه خوانده می‌شود در User-Agent چیست؟ آمده است.

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

لایه مرورگر: سیگنال‌های JavaScript#

وقتی صفحه باز می‌شود، سازوکار حفاظتی به جایی دسترسی پیدا می‌کند که سمت سرور نمی‌دید: خود مرورگر. اسکریپتی که به صفحه افزوده شده اندازه‌های نمایشگر، فونت‌های نصب‌شده، خروجی ترسیم سخت‌افزار گرافیکی، منطقه زمانی و APIهای پشتیبانی‌شده را می‌خواند؛ ترکیب این مقدارها اثر انگشت مرورگر است. این اثر انگشت دو کار می‌کند: شناختن همان سرویس‌گیرنده حتی وقتی IP عوض شود و آزمودن اینکه محیط اعلام‌شده واقعی است یا نه. محیطی که می‌گوید Chrome روی Windows است اما درایور گرافیکی‌ای را گزارش می‌کند که تنها روی سرورهای Linux پیدا می‌شود، در همین آزمون گیر می‌کند. فهرست کامل سیگنال‌ها در اثر انگشت مرورگر آمده است.

سرویس‌گیرنده‌هایی که اسکریپت را اصلاً اجرا نمی‌کنند (کتابخانه‌های HTTP مانند cURL یا Python Requests) در این لایه داده‌ای نمی‌سازند. در یک نقطه پایانی API این همان حالت مورد انتظار است؛ در یک صفحه HTML، نرسیدن هیچ نتیجه‌ای از اسکریپت کافی است تا سرویس‌گیرنده مرورگر به شمار نیاید.

مرورگر headless چیست و سایت‌ها آن را چگونه می‌شناسند؟#

مرورگر headless یک مرورگر واقعی است که بدون گشودن پنجره روی صفحه کار می‌کند: صفحه را بار می‌کند، JavaScript را اجرا می‌کند و نتیجه را به کد تحویل می‌دهد. در آزمون سرتاسری، تولید PDF، پایش سایت و گردآوری داده با اجازه به کار می‌رود؛ ابزارهای رایج Playwright، Puppeteer و Selenium هستند. اینکه چه زمانی لازم می‌شود در صفحه‌های ایستا و پویا و تفاوت دو ابزار در Playwright و Selenium آمده است.

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

پرچم سطر نخست ترفند تشخیص نیست، بخشی از استاندارد است: متن W3C آن را راه استاندارد اعلام مرورگر به سند تعریف می‌کند که توسط WebDriver هدایت می‌شود.

وزن سطر دوم به‌مرور کم شده است. بنا بر سند headless مربوط به Chrome، حالت headless قدیمی برنامه‌ای جدا بود که کد مرورگر را به اشتراک نمی‌گذاشت؛ از ⁦Chrome 132⁩ به بعد تنها به شکل فایلی جداگانه با نام chrome-headless-shell عرضه می‌شود و --headless کد واقعی Chrome را اجرا می‌کند. هرچه تفاوت‌های محیطی کوچک‌تر شد، وزن به سمت رفتار رفت.

درس این ماجرا برای صاحب سایت چنین است: تشخیص مرورگر headless با تشخیص نیت بد یکی نیست. تیم QA و سرویس پایش شما هم همین نشانه‌ها را دارند؛ جداکردن این ترافیک با IP شناخته‌شده یا قاعده درخواست امضاشده زیان کمتری دارد تا نگاه‌کردن به پرچم و مسدودکردن یکجا.

لایه رفتار: سرعت و الگوی گشت‌وگذار#

لایه‌های پیشین به این نگاه می‌کنند که درخواست از چه کسی آمده، لایه رفتار به اینکه چه می‌کند. ساده‌ترین سنجه سرعت است: شمار درخواست‌هایی که در بازه‌ای معین از یک نشانی، نشست یا حساب می‌آید. وقتی از مرز بگذرد، سرور 429 Too Many Requests برمی‌گرداند. اینکه شمارنده‌ها بر چه پایه‌ای نگه داشته می‌شوند و الگوریتم‌های پنجره ثابت، پنجره لغزان و token bucket چگونه کار می‌کنند در ⁦429 Too Many Requests⁩ آمده است.

فراتر از سرعت، الگوی گشت‌وگذار هست. انسان از صفحه نخست به دسته و از آنجا به محصول می‌رود و مرورگرش تصویرها و فایل‌های سبک را هم می‌گیرد؛ نشستی که تنها نشانی محصول‌ها را با فاصله‌های ثابت می‌پیماید و هیچ فایل جانبی نمی‌خواهد، جور دیگری دیده می‌شود. درخواست‌هایی که به پیوندهای پنهانِ نادیدنی برای بازدیدکننده می‌روند نیز سیگنال همین لایه‌اند (تله‌های honeypot). سامانه‌های تازه‌تر تعامل درون صفحه (حرکت نشانگر، دیده‌شدن یا نشدن زبانه) را در طول نشست دنبال می‌کنند؛ نمونه‌ای امروزی را در Cloudflare Precursor بررسی کرده‌ایم.

این لایه درباره یک درخواست کم می‌گوید و درباره صد درخواست بسیار. بهایش تأخیر است: برای تصمیم باید داده انباشته شود.

سیگنال‌ها چگونه به تصمیم بدل می‌شوند: امتیازدهی و آزمون#

هیچ لایه‌ای به‌تنهایی نمی‌گوید «این یک بات است». خروجی‌ها در یک امتیاز جمع می‌شوند. سند امتیاز بات Cloudflare نمونه‌ای روشن از این رویکرد است: به هر درخواست عددی میان 1 تا 99 داده می‌شود؛ 1 یعنی اطمینان بالا از خودکار بودن درخواست و 99 یعنی اطمینان بالا از انسانی بودن آن؛ زیر 30 «احتمالاً خودکار» شمرده می‌شود. بنا بر همین سند، قاعده‌های اکتشافی، یادگیری ماشین، تشخیص ناهنجاری و بررسی‌های JavaScript این امتیاز را می‌سازند.

امتیاز اقدام نیست. اقدام را قاعده‌ای تعیین می‌کند که صاحب سایت نوشته است و گزینه‌ها نردبانی می‌سازند:

1. اجازه بده. امتیاز بالاست یا درخواست از باتی تأییدشده می‌آید.
2. سرعتش را محدود کن. درخواست پذیرفته می‌شود و بسامدش کوتاه می‌آید.
3. آزمون نشان بده. به مرورگر آزمایشی نادیدنی یا به بازدیدکننده کادر تأیید داده می‌شود؛ معنای این صفحه در سمت بازدیدکننده در Cloudflare «Verify You Are Human» آمده است.
4. مسدود کن. درخواست با 403 یا صفحه مسدودسازی رد می‌شود.

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

هزینه مثبت کاذب: اگر بازدیدکننده واقعی بات شمرده شود چه می‌شود؟#

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

منبع‌های اصلی‌اش این‌هاست:

• نشانی‌های IP مشترک. مشترکان اپراتورهای همراه و کاربران خوابگاه، کافه و شبکه سازمانی بهای رفتار دیگران را می‌پردازند.
• VPN و ابزارهای حریم خصوصی. چون نشانی متعلق به مرکز داده به نظر می‌رسد، لایه شبکه امتیاز را پایین می‌آورد (VPN یا پروکسی شناسایی شد).
• مسدودکننده‌های اسکریپت، ابزارهای دسترس‌پذیری و گشت‌وگذار با صفحه‌کلید. لایه مرورگر داده‌ای نمی‌گیرد و لایه رفتار الگویی را که انتظار دارد نمی‌یابد.

در سمت بازدیدکننده، برابر این وضعیت پیام‌هایی مانند «به‌عنوان بات شناسایی شدید» یا «ترافیک غیرعادی شناسایی شد» است: دو نمونه‌اش را در خطای «ترافیک غیرعادی» Google و «Sorry, You Have Been Blocked» بررسی کرده‌ایم.

نتیجه عملی: پیش از مسدودکردن آزمون نشان بدهید و نسبت کسانی را که از آن می‌گذرند زیر نظر بگیرید. هر درخواستی که می‌گذرد سندی است بر اینکه قاعده شما فرد نادرستی را متوقف کرده است.

بات‌های تأییدشده: سایت بات خوب را چگونه می‌شناسد؟#

نوشتن «Googlebot» در هدر User-Agent کار یک سطر است؛ به همین دلیل بات خوب نه با اظهارش، بلکه با مدرکش شناخته می‌شود. امروز سه روش به کار می‌رود.

وارسی DNS معکوس. سند Google درباره وارسی Googlebot روش را می‌دهد: برای IP موجود در لاگ پرس‌وجوی DNS معکوس انجام می‌شود، بررسی می‌شود که نام بازگشته زیر googlebot.com، google.com یا googleusercontent.com باشد و سپس همان نام دوباره به IP تبدیل و با نشانی نخست سنجیده می‌شود.

فهرست‌های بات تأییدشده. سرویس‌های مدیریت بات این بررسی را به‌جای صاحب سایت انجام می‌دهند؛ سند بات‌های تأییدشده Cloudflare دو شرط می‌شمارد: بات خود را صادقانه معرفی کند (با امضای رمزنگاری، فهرست IP منتشرشده یا DNS معکوس) و از این اعتماد سوءاستفاده نکند، یعنی به robots.txt پایبند بماند و سرعت درخواست معقولی نگه دارد. پایبند نبودن به دستور crawl-delay یا ساختن ترافیکی که با هدف اعلام‌شده نمی‌خواند، دلیل حذف از فهرست است.

درخواست‌های امضاشده (Web Bot Auth). در رویکرد تازه‌تر، بات هر درخواست را با کلید خصوصی خود امضا می‌کند، کلید عمومی‌اش را روی دامنه خودش منتشر می‌کند و سایت امضا را وارسی می‌کند. استاندارد پایه ⁦RFC 9421⁩ HTTP Message Signatures است و برای سازگارکردن آن با بات‌ها در IETF یک کارگروه Web Bot Auth تشکیل شده است. این کارگروه راهکارهای امروزی مانند فهرست IP، رشته User-Agent و کلید API مشترک را ناکافی می‌داند؛ هویت عاملی که به نمایندگی از کاربر درخواست می‌فرستد در دامنه کار است و هویت کاربر نهاییِ پشت آن عامل بیرون از دامنه کار. هدرهای این امضا را در چرا عامل‌های خرید هوش مصنوعی در سایت‌ها مسدود می‌شوند؟ شرح داده‌ایم.

در هر سه روش، هویت نه با اظهار سرویس‌گیرنده، بلکه با مدرکی (رکورد DNS، مالکیت IP، کلید خصوصی) ساخته می‌شود.

اگر خودکارسازی اجرا می‌کنید، راه مشروع چیست؟#

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

• اگر API رسمی هست، از آن استفاده کنید. دسترسی بر پایه توافق است و تشخیص بات اصلاً وارد ماجرا نمی‌شود.
• به robots.txt پایبند باشید. قالب آن و روش بررسی‌اش در Python در فایل robots.txt چیست؟ آمده است.
• سرعت را به تفکیک سایت محدود کنید. به پاسخ‌های 429 و Retry-After پایبند بمانید.
• به بات خود نام بدهید. نام بات و نشانی تماس در User-Agent به مدیر سایت این امکان را می‌دهد که به‌جای مسدودکردن برایتان بنویسد.
• برای دسترسی پرحجم اجازه بگیرید. اگر خزنده‌ای در خدمت عموم اجرا می‌کنید، برای برنامه‌های بات تأییدشده درخواست بدهید.
• وقتی صفحه آزمون دیدید، بایستید. این صفحه ترجیح آشکار سایت است؛ سرویس‌های حل کپچا را پیشنهاد نمی‌کنیم.

اجرای این گام‌ها (همزمانی، درخواست‌های شرطی، تفاوت چرخش با نشست ثابت) با کد آزموده در گردآوری داده بدون مسدود شدن آمده است.

کاربردها: این نقشه را چه کسی و برای چه باید بداند؟#

• تیم بازاریابی و تحلیل: برای جداکردن منبع جهش‌های ترافیک و محافظت از بودجه تبلیغات در برابر کلیک جعلی. سمت تبلیغات در کلاهبرداری کلیکی Google Ads و در صفحه راهکار وارسی تبلیغات ما آمده است.
• تیم داده: برای فهمیدن اینکه هنگام گردآوری داده از صفحه‌های عمومی، چه رفتاری چرا مشکوک به نظر می‌رسد؛ طرح کلی در صفحه راهکار استخراج داده ما آمده و برای محتوایی که بر پایه موقعیت تغییر می‌کند پروکسی مسکونی به کار می‌رود.
• تیم‌های QA و آزمون: حفاظت بات سایت خودتان می‌تواند خودکارسازی آزمون خودتان را متوقف کند. ترافیک آزمون را از یک نشانی ثابت بیرون ببرید و برای آن نشانی قاعده اجازه بنویسید؛ برای این کار پروکسی ISP یا IP ثابت خودتان به کار می‌رود (راهکار آزمون اپلیکیشن).
• تیم‌های حفاظت از برند: پویش فروشگاه‌های جعلی و آگهی‌های تقلبی هم خودکارسازی است و از همین لایه‌ها می‌گذرد؛ دامنه کار در صفحه راهکار حفاظت از برند ما آمده است.

خطاهای پرتکرار#

• مسدودکردن بر پایه یک سیگنال. قاعده‌ای که تنها به ASN مرکز داده یا به پرچم navigator.webdriver نگاه کند، سرویس‌های پایش و آزمون‌های خودتان را هم متوقف می‌کند.
• اعتماد به هدر User-Agent و بازکردن در به روی «Googlebot». اظهار مدرک نیست؛ از DNS معکوس یا فهرست بات تأییدشده استفاده کنید.
• گذاشتن یک آستانه برای همه نقطه‌های پایانی. صفحه ورود و یک نوشته بلاگ خطر یکسانی ندارند.
• نسنجیدن مثبت کاذب. اگر نسبت درخواست‌هایی که از آزمون می‌گذرند دنبال نشود، معلوم نمی‌شود قاعده چه کسی را متوقف می‌کند.
• در سمت خودکارسازی: دیدن مسدودسازی همچون معمایی فنی. صفحه آزمون خطا نیست، پاسخ صاحب سایت است؛ سرعت، دامنه و وضعیت اجازه خود را بازبینی کنید.

راهنمای انتخاب#

پرسش‌های متداول#

ضدبات چیست و به چه کار می‌آید؟#

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

«به‌عنوان بات شناسایی شدید» یعنی چه؟#

یعنی لایه حفاظتی سایت به درخواست شما امتیاز پایینی داده است؛ این به معنای استفاده شما از یک برنامه نیست. پرتکرارترین دلیل‌ها VPN یا نشانی IP مشترک، افزونه‌هایی که اسکریپت را مسدود می‌کنند و بازکردن صفحه‌های بسیار در زمان کوتاه است. نخستین گام خاموش‌کردن VPN و افزونه‌ها و بازکردن دوباره صفحه است.

چرا Selenium و Playwright در تشخیص بات گیر می‌کنند؟#

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

آیا تشخیص بات تنها به نشانی IP نگاه می‌کند؟#

نه. IP نخستین سیگنال است، نه تنها سیگنال: دست‌دادن TLS، هماهنگی هدرها، محیط مرورگر و رفتار در طول نشست جداگانه ارزیابی می‌شوند. به همین دلیل تنها عوض‌کردن IP روی لایه‌های دیگر اثری ندارد.

ترافیک بات را در Google Analytics چگونه تشخیص بدهم؟#

جهش ناگهانی از یک شهر یا یک شبکه، مدت تعامل نزدیک به صفر و نشست‌هایی که با تبدیل نسبتی ندارند نشانه‌های معمول‌اند. برای جداسازی قطعی ابزار تحلیل بس نیست؛ همان بازه زمانی را در لاگ‌های سرور یا CDN به تفکیک IP، ASN و User-Agent بررسی کنید.

برای حفاظت یک سایت کوچک در برابر بات از کجا شروع کنیم؟#

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

خلاصه#

تشخیص بات دیوار نیست، اندازه‌گیری‌هایی پشت سر هم است: لایه شبکه اعتبار و ASN نشانی را می‌خواند، لایه پروتکل رد TLS و HTTP/2 را، لایه هدر هماهنگی اظهار را، لایه مرورگر واقعی بودن محیط را و لایه رفتار الگوی گشت‌وگذار را. همه در یک امتیاز جمع می‌شوند و صاحب سایت بر پایه خطر نقطه پایانی اجازه، محدودیت سرعت، آزمون یا مسدودسازی را برمی‌گزیند. چون هر لایه کاربران واقعی‌ای دارد که درباره‌شان اشتباه می‌کند، سامانه خوب‌ساخته نخست آزمون می‌گیرد و سپس مسدود می‌کند. بات‌های خوب هویتشان را با DNS معکوس، فهرست‌های بات تأییدشده و امضاهای مبتنی بر ⁦RFC 9421⁩ اثبات می‌کنند؛ برای کسی که خودکارسازی اجرا می‌کند نیز راه ماندگار API رسمی، robots.txt، سرعت اندازه‌دار و هویت آشکار است. برای کارهای گردآوری داده مطابق قاعده، انواع پروکسی را در سرویس‌های پروکسی ما می‌یابید.