Developers using Playwright for web-scraping are seeing their first request rejected even though the script launches a full Chromium instance, sets a genuine User-Agent and inserts human-like delays. The server blocks the request during the TLS handshake, a technique called TLS fingerprinting.

TLS fingerprinting-এর ব্যাখ্যা

যখন একটি ব্রাউজার একটি HTTPS কানেকশন খোলে, তখন এটি একটি ClientHello মেসেজ পাঠায়। এই প্যাকেটে TLS ভার্সন, সমর্থিত cipher suites, কতগুলো এক্সটেনশন (elliptic curves, signature algorithms) এবং আরও কিছু ফিল্ডের তালিকা থাকে। এই সুনির্দিষ্ট কম্বিনেশনটি নেটওয়ার্কিং স্ট্যাককে অনন্যভাবে শনাক্ত করে।

গবেষকরা সেই র (raw) ফিল্ডগুলোকে হ্যাশ করে একটি সংক্ষিপ্ত আইডেন্টিফায়ার তৈরি করেন যাকে JA3 (অথবা এর নতুন সংস্করণ JA4) বলা হয়। একটি আসল Chrome ব্রাউজার একটি হ্যাশ তৈরি করে; অন্যদিকে একটি Python HTTP লাইব্রেরি অন্য একটি হ্যাশ তৈরি করে। যদি সার্ভারের হ্যাশটি দাবি করা User-Agent-এর সাথে না মেলে, তবে এটি রিকোয়েস্টটিকে স্ক্রিপ্টেড হিসেবে চিহ্নিত করে।

কেন একটি সাধারণ Playwright ব্রাউজারও ফ্ল্যাগড হতে পারে

Playwright-এর ডিফল্ট Chromium বিল্ড সাধারণত সঠিক Chrome fingerprint প্রদান করে, কিন্তু অনেক স্ক্র্যাপার এমন কিছু পদক্ষেপ নেয় যা এই সামঞ্জস্য নষ্ট করে দেয়:

  1. Mixed request strategies – ডেভেলপাররা প্রায়ই Playwright-কে ভারী পেজ রেন্ডার করতে দেয়, আর একই সাথে একটি হালকা ওজনের HTTP ক্লায়েন্ট ব্যবহার করে অতিরিক্ত রিসোর্স (JSON, ছবি ইত্যাদি) সংগ্রহ করে। এই দ্রুত কলগুলোতে লাইব্রেরির fingerprint থাকে, Chrome-এর নয়, আর সার্ভার তাৎক্ষণিকভাবে এই অমিলটি ধরে ফেলে।
  2. TLS-terminating প্রক্সি – কিছু প্রক্সি সার্ভিস TLS স্ট্রিম ডিক্রিপ্ট করে, ট্রাফিক পরিদর্শন বা পরিবর্তন করে এবং তারপর পুনরায় এনক্রিপ্ট করে। সার্ভার শেষ পর্যন্ত প্রক্সির fingerprint দেখতে পায় এবং এটিকে একটি নন-ব্রাউজার ক্লায়েন্ট হিসেবে ব্লক করে দিতে পারে।
  3. অন্যান্য প্রোটোকল লেয়ার – অ্যান্টি-স্ক্র্যাপিং সিস্টেমগুলো HTTP/2 সেটিংস, হেডার অর্ডার এবং IP রেপুটেশনও তুলনা করে। যেকোনো লেয়ারে অমিল থাকলে তা ব্লকের কারণ হতে পারে।

JA3 থেকে JA4: একটি অস্ত্র প্রতিযোগিতা (the arms race)

JA3 ছিল প্রথম ব্যাপকভাবে গৃহীত TLS fingerprint। Chrome এখন প্রতিটি লঞ্চের সময় তার এক্সটেনশনগুলোর অর্ডার র‍্যান্ডমাইজ করে দেয়, যার ফলে একটি আসল ব্রাউজারের জন্য JA3 হ্যাশটি অস্থির (unstable) হয়ে পড়ে। JA4 এই সমস্যার সমাধান করে হ্যাশ করার আগে এক্সটেনশন লিস্টটিকে সর্ট (sort) করার মাধ্যমে, ফলে Chrome অর্ডার পরিবর্তন করলেও একটি স্থিতিশীল আইডেন্টিফায়ার পাওয়া যায়। যেসব ডিটেকশন টুল JA4 গ্রহণ করেছে, তারা সহজেই আসল Chrome ইনস্ট্যান্স এবং শুধুমাত্র একটি স্ট্যাটিক JA3 হ্যাশ কপি করা স্ক্রিপ্টেড ক্লায়েন্টগুলোর মধ্যে পার্থক্য করতে পারে।

ডেভেলপাররা আজ যা করতে পারেন

সার্ভারকে চিরতরে বোকা বানানোর মতো কোনো "ম্যাজিক স্ট্রিং" নেই। নির্ভরযোগ্য পদ্ধতি হলো রিকোয়েস্টের প্রতিটি লেয়ারকে একই তথ্য প্রদান করা:

  • User-Agent, TLS handshake, HTTP/2 settings, এবং header order-কে একই ব্রাউজার ভার্সন এবং OS-এর সাথে সামঞ্জস্যপূর্ণ করুন।
  • একটি পূর্ণাঙ্গ ব্রাউজার অটোমেশন টুলের সাথে আলাদা HTTP ক্লায়েন্ট ব্যবহার করা বন্ধ করুন। যদি গতি গুরুত্বপূর্ণ হয়, তবে Playwright-কেই সমস্ত নেটওয়ার্ক কল হ্যান্ডেল করতে দিন, এমনকি ছোটখাটো কলগুলোও।
  • এমন প্রক্সি বেছে নিন যা কানেকশন টার্মিনেট না করে TLS পাস-থ্রু (pass TLS through) করে, অথবা সেগুলোকে এমনভাবে কনফিগার করুন যাতে তারা মূল TLS হ্যান্ডশেকটি অপরিবর্তিত অবস্থায় ফরওয়ার্ড করে।
  • IP-reputation সার্ভিসগুলো মনিটর করুন; একটি ক্লিন IP পুল ঐতিহাসিক অপব্যবহারের ভিত্তিতে ব্লক হওয়ার সম্ভাবনা কমিয়ে দেয়।

Fingerprint সামঞ্জস্য উপেক্ষা করার মূল্য

যখন একটি স্ক্র্যাপার হ্যান্ডশেক পর্যায়ে ব্লক হয়ে যায়, তখন এটি কখনোই পেজ লজিক পর্যন্ত পৌঁছাতে পারে না, ফলে কোনো ডেটা সংগ্রহ করা সম্ভব হয় না এবং জাভাস্ক্রিপ্ট এক্সিকিউট করতে কোনো সময় ব্যয় হয় না। যেসব এন্টারপ্রাইজ বড় পরিসরে ডেটা সংগ্রহের ওপর নির্ভর করে, তাদের ক্লাউড-কম্পিউট খরচ বেড়ে যায় কারণ রিট্রাই লুপ (retry loops) চলতে থাকে। বারবার ব্লক হওয়ার ফলে IP ব্যানও হতে পারে, যা একই নেটওয়ার্ক থেকে আসা অন্যান্য বৈধ ট্রাফিককেও প্রভাবিত করতে পারে।

পাল্টা যুক্তি: কেন সাইটগুলো TLS fingerprinting ব্যবহার করে

সাইট মালিকরা TLS fingerprinting-কে একটি বৈধ প্রতিরক্ষা হিসেবে দেখেন। অটোমেটেড স্ক্র্যাপিং সার্ভারকে ওভারলোড করতে পারে, পে-ওয়াল বাইপাস করতে পারে বা বড় পরিসরে ব্যক্তিগত ডেটা সংগ্রহ করতে পারে। TLS fingerprint দাবি করা ব্রাউজারের সাথে মিলছে কি না তা পরীক্ষা করার মাধ্যমে, একটি সাইট আসল ব্যবহারকারীদের কোনো ক্ষতি না করেই বিপুল সংখ্যক নিম্নমানের বটকে ফিল্টার করে ফেলে। এই কৌশলটি CAPTCHA-এর চেয়ে কম বিরক্তিকর এবং ব্যবহারকারীর অভিজ্ঞতা বজায় রাখে।

পরবর্তী বিষয় যা খেয়াল রাখতে হবে

  • JA4-এর ব্যবহার – আগামী মাসগুলোতে আরও বেশি সিকিউরিটি ভেন্ডর এবং CDN প্রোভাইডাররা JA4-ভিত্তিক ডিটেকশন চালু করবে বলে আশা করা যায়।
  • ব্রাউজার-লেভেল র‍্যান্ডমাইজেশন – Chrome এবং অন্যান্য ব্রাউজারগুলো TLS প্যারামিটারগুলো পরিবর্তন করতে থাকতে পারে, যা fingerprinting টুলগুলোকে ট্রাফিক টাইমিং বা জাভাস্ক্রিপ্ট এক্সিকিউশন প্যাটার্নের মতো আরও জটিল সিগন্যালের দিকে ঠেলে দেবে।
  • প্রক্সি মার্কেটের প্রতিক্রিয়া – "TLS-transparent" রাউটিংয়ের প্রতিশ্রুতি দেয় এমন সার্ভিসগুলো বাজারে আসার সম্ভাবনা রয়েছে, যা স্ক্র্যাপিং কমিউনিটির অপরিবর্তিত হ্যান্ডশেক সংক্রান্ত প্রয়োজন মেটাবে।

সারসংক্ষেপ

যদি আপনার Playwright scraper কোনো পেজ লোড হওয়ার আগেই রিজেক্ট হয়ে যায়, তবে এর মূল কারণ সম্ভবত TLS fingerprint-এর অমিল। এর সমাধান কোনো সাময়িক প্যাচ নয়; বরং প্রতিটি প্রোটোকল লেয়ারকে ঘোষিত ব্রাউজার প্রোফাইলের সাথে সুশৃঙ্খলভাবে সামঞ্জস্যপূর্ণ করা প্রয়োজন। User-Agent, TLS handshake, HTTP/2 settings, header order এবং proxy behavior-এর মধ্যে ধারাবাহিকতা বজায় রাখাই হলো আধুনিক anti-scraping defenses-এর নজর এড়ানোর একমাত্র নির্ভরযোগ্য উপায়।