توسعه‌دهندگانی که از Playwright برای وب‌اسکرپینگ (web-scraping) استفاده می‌کنند، با رد شدن اولین درخواست خود مواجه می‌شوند، حتی اگر اسکریپت یک نمونه کامل از Chromium را اجرا کند، یک User-Agent واقعی تنظیم نماید و تأخیرهای مشابه انسان را اعمال کند. سرور درخواست را در مرحله TLS handshake مسدود می‌کند؛ تکنیکی که اثرانگشت TLS (TLS fingerprinting) نامیده می‌شود.

توضیح اثرانگشت TLS (TLS fingerprinting)

وقتی یک مرورگر یک اتصال HTTPS باز می‌کند، پیام ClientHello را ارسال می‌کند. این بسته شامل نسخه TLS، مجموعه‌ رمزهای پشتیبانی‌شده (cipher suites)، مجموعه‌ای از افزونه‌ها (منحنی‌های بیضوی، الگوریتم‌های امضا) و چند فیلد دیگر است. ترکیب دقیق این موارد، پشته شبکه (networking stack) را به‌طور منحصربه‌فرد شناسایی می‌کند.

محققان آن فیلدهای خام را به یک شناسه فشرده به نام JA3 (یا نسخه جدیدتر آن JA4) هش (hash) می‌کنند. یک مرورگر واقعی Chrome یک هش تولید می‌کند، در حالی که یک کتابخانه HTTP پایتون هشی متفاوت تولید می‌کند. اگر هش سمت سرور با User-Agent ادعا شده مطابقت نداشته باشد، درخواست را به عنوان یک اسکریپت علامت‌گذاری می‌کند.

چرا یک مرورگر Playwright خام (vanilla) همچنان می‌تواند شناسایی شود

نسخه پیش‌فرض Chromium در Playwright معمولاً اثرانگشت صحیح Chrome را ارسال می‌کند، اما بسیاری از اسکرپرها مراحلی را اضافه می‌کنند که این ثبات را از بین می‌برد:

  1. استراتژی‌های درخواست ترکیبی – توسعه‌دهندگان اغلب اجازه می‌دهند Playwright صفحات سنگین را رندر کند، در حالی که یک کلاینت HTTP سبک، منابع کمکی (مانند JSON، تصاویر و غیره) را واکشی می‌کند. این فراخوانی‌های سریع، اثرانگشت کتابخانه را حمل می‌کنند، نه Chrome را، و سرور بلافاصله متوجه عدم تطابق می‌شود.
  2. پروکسی‌های پایان‌دهنده TLS (TLS-terminating proxies) – برخی از سرویس‌های پروکسی، جریان TLS را رمزگشایی کرده، ترافیک را بازرسی یا اصلاح می‌کنند و سپس دوباره آن را رمزگذاری می‌کنند. در نهایت، سرور اثرانگشت پروکسی را می‌بیند و ممکن است آن را به عنوان یک کلاینت غیرمرورگر مسدود کند.
  3. سایر لایه‌های پروتکل – سیستم‌های ضد اسکرپینگ همچنین تنظیمات HTTP/2، ترتیب هدرها و اعتبار IP را مقایسه می‌کنند. هرگونه اختلاف در هر لایه می‌تواند باعث مسدود شدن شود.

از JA3 تا JA4: مسابقه تسلیحاتی

JA3 اولین اثرانگشت TLS بود که به‌طور گسترده مورد استفاده قرار گرفت. اکنون Chrome ترتیب افزونه‌های خود را در هر بار اجرا به‌صورت تصادفی تغییر می‌دهد که باعث می‌شود هش JA3 برای یک مرورگر واقعی ناپایدار باشد. JA4 این مشکل را با مرتب‌سازی لیست افزونه‌ها قبل از هش کردن حل می‌کند و حتی زمانی که Chrome ترتیب را جابه‌جا می‌کند، یک شناسه پایدار ارائه می‌دهد. ابزارهای شناسایی که از JA4 استفاده می‌کنند، می‌توانند به‌طور قابل‌اعتمادی نمونه‌های واقعی Chrome را از کلاینت‌های اسکریپتی که صرفاً یک هش JA3 ایستا را کپی می‌کنند، متمایز کنند.

آنچه توسعه‌دهندگان امروز می‌توانند انجام دهند

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

  • User-Agent، TLS handshake، تنظیمات HTTP/2 و ترتیب هدرها را با همان نسخه مرورگر و سیستم‌عامل همسو کنید.
  • از ترکیب یک ابزار اتوماسیون مرورگر کامل با یک کلاینت HTTP مجزا خودداری کنید. اگر سرعت مهم است، اجازه دهید Playwright تمام فراخوانی‌های شبکه را انجام دهد، حتی موارد ساده را.
  • پروکسی‌هایی را انتخاب کنید که TLS را بدون قطع کردن اتصال (pass TLS through) عبور می‌دهند، یا آن‌ها را طوری پیکربندی کنید که TLS handshake اصلی را بدون تغییر ارسال کنند.
  • سرویس‌های اعتبار IP (IP-reputation) را نظارت کنید؛ استفاده از یک مجموعه IP تمیز، احتمال مسدود شدن بر اساس سوءاستفاده‌های گذشته را کاهش می‌دهد.

هزینه نادیده گرفتن ثبات اثرانگشت

وقتی یک اسکرپر در مرحله handshake مسدود می‌شود، هرگز به منطق صفحه نمی‌رسد، بنابراین هیچ داده‌ای استخراج نمی‌شود و زمانی برای اجرای JavaScript صرف نمی‌شود. شرکت‌هایی که بر جمع‌آوری داده در مقیاس بزرگ تکیه دارند، با فعال شدن حلقه‌های تلاش مجدد (retry loops)، شاهد افزایش هزینه‌های محاسبات ابری هستند. مسدود شدن‌های مکرر همچنین می‌تواند منجر به بن شدن IP شود که بر سایر ترافیک‌های مشروع از همان شبکه تأثیر می‌گذارد.

دیدگاه مقابل: چرا سایت‌ها از اثرانگشت TLS استفاده می‌کنند

صاحبان سایت‌ها اثرانگشت TLS را یک دفاع مشروع می‌دانند. اسکرپینگ خودکار می‌تواند سرورها را تحت فشار قرار دهد، دیوارهای پرداخت (paywalls) را دور بزند یا داده‌های شخصی را در مقیاس بزرگ جمع‌آوری کند. با بررسی اینکه آیا اثرانگشت TLS با مرورگر ادعا شده مطابقت دارد یا خیر، یک سایت دسته بزرگی از بات‌های کم‌هزینه را بدون آسیب رساندن به کاربران واقعی فیلتر می‌کند. این تکنیک نسبت به CAPTCHAها کمتر مزاحم است و تجربه کاربری را حفظ می‌کند.

آنچه باید در آینده زیر نظر داشت

  • پذیرش JA4 – انتظار می‌رود در ماه‌های آینده، فروشندگان امنیتی و ارائه‌دهندگان CDN بیشتر، شناسایی مبتنی بر JA4 را عرضه کنند.
  • تصادفی‌سازی در سطح مرورگر – Chrome و سایر مرورگرها ممکن است به تغییر پارامترهای TLS ادامه دهند و ابزارهای اثرانگشت‌گذاری را به سمت سیگنال‌های پیچیده‌تر مانند زمان‌بندی ترافیک یا الگوهای اجرای JavaScript سوق دهند.
  • واکنش بازار پروکسی – احتمال ظهور سرویس‌هایی که مسیریابی «شفاف برای TLS» (TLS-transparent) را وعده می‌دهند، وجود دارد تا نیاز جامعه اسکرپینگ به دست‌دادن‌های (handshakes) بدون تغییر را برآورده کنند.

نکته کلیدی (Takeaway)

اگر اسکرپر Playwright شما پیش از بارگذاری هر صفحه‌ای رد می‌شود، علت اصلی تقریباً به طور قطع عدم تطابق در TLS fingerprint است. رفع این مشکل با یک وصله سریع امکان‌پذیر نیست؛ بلکه مستلزم هم‌راستاسازی دقیق تمام لایه‌های پروتکل با پروفایل مرورگرِ تعریف‌شده است. حفظ یکپارچگی در User-Agent، TLS handshake، تنظیمات HTTP/2، ترتیب هدرها و رفتار پروکسی، تنها راه مطمئن برای زیر رادار ماندن از سیستم‌های دفاعی مدرن ضد اسکرپینگ است.