TLS ফিঙ্গারপ্রিন্টিং এবং JA3: এটি স্ক্র্যাপিংকে কীভাবে প্রভাবিত করে
TLS ফিঙ্গারপ্রিন্টিং একটি HTTP ক্লায়েন্টকে তার TLS হ্যান্ডশেকের গঠন থেকে শনাক্ত করে, যেকোনো অ্যাপ্লিকেশন ডেটা চলাচলের আগেই। JA3 এবং JA4 ClientHello বার্তার ফিল্ডগুলোকে একটি ছোট হ্যাশে রূপান্তর করে, এবং অ্যান্টি-বট সিস্টেমগুলো সেই হ্যাশকে পরিচিত ব্রাউজার ও বট সিগনেচারের সাথে তুলনা করে। দাবি করা ব্রাউজার এবং হ্যাশের মধ্যে অমিল থাকলে হেডার পড়ার আগেই একটি রিকোয়েস্ট প্রত্যাখ্যান করা হতে পারে।
নিচের প্রতিটি টেবিলে ব্যবহৃত লেজেন্ড: ✅ ভেন্ডর দ্বারা ডকুমেন্টেড · ❌ অফার করা হয় না বা ডকুমেন্টেড নয় · ⚠️ সীমাবদ্ধতার সাথে ডকুমেন্টেড · 💡 ব্যবহারিক টিপ। এই পৃষ্ঠায় অন্য কোনো চিহ্ন ব্যবহার করা হয়নি।
TLS ফিঙ্গারপ্রিন্ট কী
TLS ফিঙ্গারপ্রিন্ট হলো একটি ছোট সিগনেচার, যা কোনো HTTP ক্লায়েন্ট tls হ্যান্ডশেকের সময় তার client hello বার্তায় পাঠানো ফিল্ডগুলো থেকে তৈরি হয়, এমনকি এনক্রিপশন শুরু হওয়ার আগেই। JA3 কী তা বোঝা এখান থেকেই শুরু হয়: JA3 ঐ ফিল্ডগুলোর মধ্যে পাঁচটি পড়ে সেগুলোকে একটি একক হ্যাশে রূপান্তর করে। প্রতিটি ক্লায়েন্ট, সেটা Chrome, curl বা একটি Python স্ক্রিপ্ট হোক, নিজস্ব নির্দিষ্ট ক্রমে cipher suite, extension এবং elliptic curve-এর তালিকা পাঠায়। সার্ভারগুলো এই ডেটা প্লেইনটেক্সটে পড়ে, কারণ তখনও কোনো পক্ষ এনক্রিপশন কী নিয়ে একমত হয়নি।
Client hello-তে একটি alpn extension-ও থাকে, যা সার্ভারকে জানায় সংযোগটি HTTP/1.1 পছন্দ করে নাকি HTTP/2। ভিন্ন ভিন্ন লাইব্রেরি অন্তর্নিহিত TLS স্ট্যাকের ওপর নির্ভর করে এই ফিল্ডগুলো ভিন্নভাবে সাজায়, যেমন OpenSSL বনাম BoringSSL বনাম NSS। এটিই সেই কাঁচামাল যা থেকে JA3 এবং JA4 উভয়ই কাজ করে।
💡 টিপ: যদি দুটি রিকোয়েস্ট একই ফিঙ্গারপ্রিন্ট বহন করে কিন্তু ভিন্ন ঘোষিত ব্রাউজার দাবি করে, তবে শুধু এই অসামঞ্জস্যের কারণেই, কোনো হেডার কৌশল ছাড়াই, সন্দেহের জন্ম নিতে পারে।
JA3 এবং JA4 কীভাবে গণনা করা হয়
একটি JA3 ফিঙ্গারপ্রিন্ট গণনা করা হয় ClientHello-র পাঁচটি ফিল্ডকে একটি স্ট্রিং-এ যুক্ত করে MD5 দিয়ে হ্যাশ করার মাধ্যমে, যা একটি ৩২-অক্ষরের সিগনেচার তৈরি করে (Scrapfly, JA3/JA4 TLS Fingerprinting Guide, 2026)। John Althouse, Jeff Atkinson এবং Josh Atkins ২০১৭ সালে Salesforce-এ মূল পদ্ধতিটি প্রকাশ করেন, এবং এটি আজও অধিকাংশ TLS-ভিত্তিক বট যাচাইয়ের মেরুদণ্ড গঠন করে। ঐ হ্যাশে যাওয়া পাঁচটি ফিল্ড হলো TLS সংস্করণ, cipher suite, extension, elliptic curve এবং point format, একটি নির্দিষ্ট ক্রমে যুক্ত।
- TLS সংস্করণ বের করুন, দশমিক সংখ্যা হিসেবে প্রকাশ করে, যেমন TLS 1.2-এর জন্য 771।
- Cipher suite-গুলো ঠিক সেই ক্রমে তালিকাভুক্ত করুন যেভাবে ক্লায়েন্ট পাঠিয়েছে, হাইফেন দিয়ে আলাদা করে।
- TLS extension-গুলো পাঠানোর ক্রমে তালিকাভুক্ত করুন, হাইফেন দিয়ে আলাদা করে, GREASE মানগুলো বাদ দিয়ে।
- সমর্থিত elliptic curve এবং point format যুক্ত করুন।
- পাঁচটি ফিল্ডই কমা দিয়ে যুক্ত করুন এবং ফলস্বরূপ স্ট্রিংটি MD5 দিয়ে হ্যাশ করে ja3 হ্যাশ পান।
ClientHello থেকে JA3 হ্যাশ কীভাবে তৈরি হয়
নতুন পদ্ধতিটি ধাপ ৩-এর ক্রম সমস্যাটি এড়িয়ে যায়। পাঠানো অবস্থায় extension রেকর্ড করার বদলে এটি সেগুলোকে হেক্সাডেসিমাল মান অনুযায়ী সাজায়, যা ২০২৩ সালে ব্রাউজারগুলো extension-এর ক্রম র্যান্ডমাইজ করা শুরু করার পরও JA4 ফিঙ্গারপ্রিন্টকে স্থিতিশীল রাখে (Scrapfly, 2026)। এই উত্তরসূরি হ্যাশটি MD5 বাদ দিয়ে একটি ট্রাঙ্কেটেড SHA-256 ব্যবহার করে এবং ALPN ও QUIC সমর্থন যোগ করে, যেসব বিবরণ JA3 কখনোই ধরতে পারেনি।
| মানদণ্ড | JA3 | উত্তরসূরি পদ্ধতি |
|---|---|---|
| হ্যাশ অ্যালগরিদম | MD5 | ট্রাঙ্কেটেড SHA-256 |
| Extension-এর ক্রম | যেমন পাঠানো হয়েছে | হেক্স মান অনুযায়ী সাজানো |
| QUIC/HTTP3 সমর্থন | ❌ অফার করা হয় না | ✅ ডকুমেন্টেড |
| ALPN অন্তর্ভুক্ত | ❌ অফার করা হয় না | ✅ ডকুমেন্টেড |
| তৈরি হয়েছে | ২০১৭, Salesforce | ২০২৩, FoxIO |
নিজের ক্লায়েন্ট পরীক্ষা করার ক্ষেত্রে এই কাঠামোগত পার্থক্যগুলো গুরুত্বপূর্ণ। একভাবে গণনা করা একটি ফিঙ্গারপ্রিন্ট অন্য পদ্ধতির জন্য তৈরি ডেটাবেসের সাথে মিলবে না।
শুধু প্রক্সি দিয়ে ফিঙ্গারপ্রিন্টিং সমাধান হয় না কেন
প্রক্সি একটি রিকোয়েস্টের উৎস IP ঠিকানা পরিবর্তন করে; এটি tls হ্যান্ডশেককে একেবারেই স্পর্শ করে না, তাই TLS ফিঙ্গারপ্রিন্টিং এখনো দেখে কোন লাইব্রেরি সংযোগটি শুরু করেছে। হ্যান্ডশেকটি সরাসরি ক্লায়েন্ট ও গন্তব্য সার্ভারের মধ্যে ঘটে, এবং CONNECT পদ্ধতি ব্যবহারকারী একটি স্ট্যান্ডার্ড HTTPS প্রক্সি শুধু এনক্রিপ্টেড বাইটগুলো স্পর্শ না করে টানেল করে (Shifter, TLS fingerprint glossary, 2026)। অর্থাৎ, একটি পরিচ্ছন্ন রেসিডেনশিয়াল IP-এর সাথে ডিফল্ট Python ক্লায়েন্ট ব্যবহার করলে এমন একটি ফিঙ্গারপ্রিন্ট পাঠানো হয় যা ব্রাউজার নয়, স্ক্রিপ্ট হিসেবে পড়া যায়।
>আমাদের পরীক্ষায়, আগস্ট ২০২৬, একটি ডিফল্ট requests সেশন তিন ধরনের ভিন্ন প্রক্সির মাধ্যমে রুট করা হয়েছিল এবং প্রতিবার একই হ্যাশ ফেরত এসেছে, IP রেপুটেশন বা ভৌগোলিক অবস্থান নির্বিশেষে। শুধুমাত্র অন্তর্নিহিত TLS লাইব্রেরি পরিবর্তন করলেই ফলাফল বদলায়। কথোপকথনের এটিই সৎ অংশ: IP-এর গুণমান এবং ফিঙ্গারপ্রিন্ট মিল দুটি আলাদা সমস্যার সমাধান করে, এবং একটিকে অন্যটির সমাধান হিসেবে ভাবলে তাড়াতাড়ি হতাশা আসে।"TLS ফিঙ্গারপ্রিন্টিং ঘটে প্রথম HTTP বাইট পৌঁছানোর আগেই। IP ঠিকানা বদলালে এর নিচের হ্যান্ডশেকে কিছুই হয় না।" - Insocks ইঞ্জিনিয়ারিং নোট, আগস্ট ২০২৬
- ❌ একটি রেসিডেনশিয়াল IP cipher suite-এর ক্রম পুনর্লিখন করে না।
- ❌ প্রক্সি রোটেশন TLS হ্যান্ডশেকের ফিল্ডগুলো স্পর্শ করে না।
একটি প্রক্সি কী পরিবর্তন করে আর কী অপরিবর্তিত রাখে
- ✅ একটি আসল ব্রাউজারের TLS স্ট্যাকের সাথে মিলিয়ে নেওয়াই আসলে ফিঙ্গারপ্রিন্ট পরিবর্তন করে।
অ্যান্টি-বট সিস্টেম কীভাবে TLS ফিঙ্গারপ্রিন্ট ব্যবহার করে
অ্যান্টি-বট সিস্টেমগুলো প্রতিটি আগত ClientHello থেকে একটি হ্যাশ গণনা করে এবং পরিচিত ব্রাউজার ও বট ফিঙ্গারপ্রিন্টের ডেটাবেসের সাথে মিলিয়ে দেখে, তারপর ব্লক, চ্যালেঞ্জ বা পাস নির্ধারণের আগে সেই সংকেতকে অন্যান্য স্তরের সাথে একত্রিত করে। TLS ফিঙ্গারপ্রিন্টিং HTTP হেডারের সম্পূর্ণ নিচের স্তরে থাকে, এজন্যই নিখুঁত হেডারের পাশাপাশি একটি স্ক্রিপ্টেড TLS স্ট্যাক থাকলেও ফ্ল্যাগ হয়ে যায়। Cloudflare তার bot management পণ্যের ভেতরে JA3 এবং JA4 ফিল্ড ডকুমেন্ট করে, এবং অন্যান্য ভেন্ডরও অনুরূপ যাচাই চালায় (Scrapfly, 2026)। স্কোরিংটি একক ফিল্ডের ওপর নির্ভর না করে TLS সংকেতকে রিকোয়েস্টের টাইমিং, IP রেপুটেশন এবং আচরণগত ডেটার সাথে মিশিয়ে দেয়।
কিছু ভেন্ডর হ্যান্ডশেক যাচাইয়ের ওপরে http2 ফিঙ্গারপ্রিন্টিং যোগ করে, যেখানে TLS স্তর শেষ হওয়ার পর কোনো ক্লায়েন্ট কীভাবে stream priority এবং window size নিয়ে আলোচনা করে তা পড়া হয়। এই দ্বিতীয় স্তর JA3 এবং JA4 হ্যাশের পাশাপাশি বৃহত্তর anti bot ডিটেকশন স্কোরিং-এ অন্তর্ভুক্ত হয়। ভেন্ডরগুলো ব্রাউজার সংস্করণ প্রকাশের সাথে সাথে এই ডেটাবেসগুলো আপডেট রাখে, এবং গত কোয়ার্টারে পাস করা একটি ফিঙ্গারপ্রিন্ট ব্রাউজার আপডেটে তার ডিফল্ট বদলানোর পর ফেল করা শুরু করতে পারে।
| সংকেত | এটি যা প্রকাশ করে | সাধারণ পদক্ষেপ |
|---|---|---|
| JA3 হ্যাশ বনাম User-Agent-এ অমিল | দাবি করা ব্রাউজার TLS স্ট্যাকের সাথে মেলে না | ⚠️ সীমাবদ্ধতার সাথে ডকুমেন্টেড, প্রায়ই একটি চ্যালেঞ্জ |
| সেশন জুড়ে স্থির হ্যাশ | একই স্ক্রিপ্ট বারবার পুনর্ব্যবহৃত | ⚠️ সীমাবদ্ধতার সাথে ডকুমেন্টেড, রেট লিমিটিং |
| পরিচিত বট ডেটাবেসে মিল | ফিঙ্গারপ্রিন্ট কোনো সাধারণ লাইব্রেরি ডিফল্টের সাথে সংযুক্ত | ❌ অফার করা হয় না, প্রায়ই সরাসরি ব্লক করা হয় |
| সামঞ্জস্যপূর্ণ ব্রাউজার-সদৃশ প্রোফাইল | প্রত্যাশিত ব্রাউজার আচরণের সাথে মেলে | ✅ ডকুমেন্টেড, সাধারণত পাস করে |
স্তর জুড়ে সামঞ্জস্য: TLS, HTTP/2, হেডার এবং IP
স্তর জুড়ে সামঞ্জস্য মানে হলো tls হ্যান্ডশেক, http2 settings frame, ঘোষিত User-Agent এবং IP-এর নেটওয়ার্ক ধরন — সবকিছুকে একই গল্পের দিকে ইঙ্গিত করতে হবে, একটি আসল ব্রাউজার বা একটি আসল ক্লায়েন্ট, অমিলযুক্ত সংকেতের একটি জাফরি নয়। Http2 ফিঙ্গারপ্রিন্টিং দেখে হ্যান্ডশেক সম্পন্ন হওয়ার পর একটি ক্লায়েন্ট কীভাবে stream priority এবং window size নিয়ে আলোচনা করে, এবং এটি দ্বিতীয় স্তর যা কিছু অ্যান্টি-বট ভেন্ডর JA3 এবং JA4 ডেটার পাশাপাশি যাচাই করে (Scrapfly, 2026)। একটি স্ক্র্যাপার যা তার TLS স্ট্যাক ঠিক করে কিন্তু HTTP/2 সেটিংস উপেক্ষা করে, সে একটি স্পষ্ট ফাঁক রেখে দেয়।
একটি রিকোয়েস্ট যে চারটি স্তর উন্মুক্ত করে, এবং প্রতিটি কী প্রকাশ করে
User agent সামঞ্জস্যও গুরুত্বপূর্ণ, কারণ Chrome 124 দাবি করা একটি User-Agent স্ট্রিং একটি পুরোনো JA4 ফিঙ্গারপ্রিন্ট প্রোফাইলের সাথে জুড়লে সেটি নিজেই একটি স্ববিরোধ হিসেবে পড়া যায়। প্রতিটি স্বতন্ত্র হেডার সঠিক দেখালেও অ্যান্টি-বট ভেন্ডরগুলো ঠিক এই ধরনের অমিলই ফ্ল্যাগ করে। এই যাচাইগুলোর কোনোটির জন্যই টার্গেট সাইটে কিছু বাইপাস করার প্রয়োজন নেই; এগুলো শুধু নিশ্চিত করে যে রিকোয়েস্ট বের হওয়ার আগে ক্লায়েন্টের নিজস্ব সংকেতগুলো পরস্পরের সাথে একমত।
| স্তর | কী মিলতে হবে | কীভাবে যাচাই করবেন |
|---|---|---|
| TLS হ্যান্ডশেক | দাবি করা ব্রাউজারের জন্য cipher suite এবং extension-এর ক্রম | JA3/JA4 হ্যাশকে একটি পরিচিত ব্রাউজার নমুনার সাথে তুলনা করুন |
| HTTP/2 settings frame | Window size, header table size, stream priority | ফ্রেমের মানগুলো ব্রাউজার ডিফল্টের সাথে পরীক্ষা করুন |
| হেডার | User-Agent, Accept-Language, Sec-CH-UA যদি থাকে | ম্যানুয়াল পর্যালোচনা বা একটি হেডার পরিদর্শন টুল |
| IP/নেটওয়ার্ক | ASN ধরন দাবি করা ক্লায়েন্টের সাথে মেলে, রেসিডেনশিয়াল বনাম ডেটাসেন্টার | IP রেপুটেশন এবং ASN লুকআপ যাচাই করুন |
নিজের TLS ফিঙ্গারপ্রিন্ট কীভাবে পরীক্ষা করবেন
একটি ফিঙ্গারপ্রিন্ট পরীক্ষা শুরু হয় একটি যাচাই এন্ডপয়েন্টে একটি পরিচ্ছন্ন রিকোয়েস্ট পাঠিয়ে, তারপর একই এন্ডপয়েন্টে একটি আসল ব্রাউজারের ফলাফলের সাথে পাশাপাশি তুলনা করে। একটি JA4 ফিঙ্গারপ্রিন্ট TLS সংস্করণ, cipher-এর সংখ্যা, extension-এর সংখ্যা এবং প্রথম ALPN মানকে একটি পাঠযোগ্য স্ট্রিং-এ গুচ্ছবদ্ধ করে, যা কাঁচা হ্যাশ পড়ার তুলনায় দৃশ্যমান তুলনা সহজ করে (Scrapfly, JA3/JA4 fingerprint tool, 2026)। ভিন্ন দুই দিনে একই পরীক্ষা দুবার চালানো ফলাফলটি লাইব্রেরি আপডেট জুড়ে স্থিতিশীল থাকে কিনা তা নিশ্চিত করতে সাহায্য করে।
এর জন্য তৈরি টুলগুলো, যার মধ্যে Scrapfly-এর নিজস্ব চেকার এবং curl impersonate-এর মতো থার্ড পার্টি লাইব্রেরি — একটি টুলের নাম যা এখানে শুধুমাত্র শনাক্তকরণের উদ্দেশ্যে ব্যবহৃত — ঠিক এই তুলনাটি অনুমান ছাড়াই সম্ভব করার জন্যই তৈরি। Playwright বা Puppeteer চালানো একটি হেডলেস ব্রাউজারও তুলনার জন্য একটি সত্যিকারের হ্যান্ডশেক দেয়, কারণ এটি একটি স্ক্রিপ্টেড TLS স্ট্যাকের বদলে একটি আসল ব্রাউজার ইঞ্জিন চালু করে।
- ধাপ ১। পর্যালোচনাধীন ক্লায়েন্ট থেকে একটি ফিঙ্গারপ্রিন্ট টেস্টিং এন্ডপয়েন্টে একটি রিকোয়েস্ট পাঠান এবং এটি যে হ্যাশ ফেরত দেয় তা রেকর্ড করুন।
- ধাপ ২। একই এন্ডপয়েন্ট একটি আসল, হালনাগাদ ব্রাউজারে খুলুন এবং তুলনার জন্য সেটির নিজস্ব হ্যাশ নোট করুন।
- ধাপ ৩। শুধু হ্যাশ মিলের ওপর বিচার না করে cipher suite, extension-এর সংখ্যা এবং ALPN মান পাশাপাশি তুলনা করুন।
- ধাপ ৪। ঘোষিত User-Agent হেডারটি আসলে পর্যবেক্ষিত TLS প্রোফাইলের সাথে মেলে কিনা যাচাই করুন।
- ধাপ ৫। তারিখসহ ফলাফল লগ করুন, কারণ একটি লাইব্রেরি বা ব্রাউজার আপডেটের পর হ্যাশটি বদলে যেতে পারে।
👉 সঠিকভাবে কনফিগার করা একটি ক্লায়েন্ট শুরু থেকে শেষ কীভাবে আচরণ করে তা দেখতে চান? একটি ডেমো চেষ্টা করুন Insocks-এর সাথে, সম্পূর্ণ টেস্ট ব্যাচ চালানোর আগে।
স্থিতিশীল ডেটা সংগ্রহের জন্য হোয়াইট-হ্যাট অনুশীলন
হোয়াইট-হ্যাট ডেটা সংগ্রহ শুরু হয় টার্গেট সাইটের নিজস্ব নিয়ম মেনে: প্রথমে অফিসিয়াল API, robots.txt সম্মান করা, এবং রিকোয়েস্টের হার সার্ভারে চাপ সৃষ্টি করতে পারে এমন যেকোনো সীমার অনেক নিচে রাখা। JA3 কী তা আবার দেখা ব্যাখ্যা করে কেন হেডার কৌশল নয়, বরং পূর্ণ ব্রাউজার ইঞ্জিনই সবচেয়ে স্থিতিশীল ফলাফল দিতে প্রবণ, কারণ একটি আসল ব্রাউজারের TLS স্ট্যাক ডিফল্টভাবেই তার নিজস্ব ঘোষিত পরিচয়ের সাথে মিলে যায়। Playwright, Puppeteer এবং Selenium সবগুলোই সত্যিকারের ব্রাউজার ইঞ্জিন চালু করে, তাই কোনো অতিরিক্ত কনফিগারেশন ছাড়াই তাদের হ্যান্ডশেক Chrome বা Firefox-এর মতো দেখায় (Scrapfly, 2026)।
কিছু টিম কাজের জন্য পূর্ণ ব্রাউজার অতিরিক্ত ভারী হলে curl impersonate বা অনুরূপ লাইব্রেরির দিকে হাত বাড়ায়, এবং এটি একটি যৌক্তিক আপস যতক্ষণ ফলস্বরূপ ফিঙ্গারপ্রিন্টটি আগে একটি আসল ব্রাউজারের সাথে পরীক্ষা করা হয়। হয় পদ্ধতির সাথে বিবেচনাপূর্ণ টাইমিং এবং একটি স্পষ্ট User-Agent জুড়লে সংগ্রহ প্রক্রিয়াটি পূর্বানুমেয় ও পরে নিরীক্ষা করা সহজ থাকে।
- ✅ যেখানে অফিসিয়াল API এবং ডকুমেন্টেড এন্ডপয়েন্ট আছে সেখানে সেগুলো ব্যবহার করুন।
- ✅ robots.txt এবং টার্গেট সাইটের প্রকাশিত শর্তাবলী সম্মান করুন।
- ✅ একটি এন্ডপয়েন্টে বার্স্ট ছোড়ার বদলে রিকোয়েস্টের মধ্যে বিরতি রাখুন।
- ✅ টুকরো টুকরো হেডার বা TLS স্পুফিংয়ের বদলে পূর্ণ ব্রাউজার অটোমেশনকে অগ্রাধিকার দিন।
- 💡 একটি ধীরে, স্থির সংগ্রহ সময়সূচি সাধারণত একটি দ্রুতগতির, বার্স্টি সময়সূচির তুলনায় কম সাপোর্ট টিকিটের কারণ হয়।
মার্কিন যুক্তরাষ্ট্র থেকে এই পদ্ধতি ব্যবহার করে, একটি টিম নিশ্চিত করে যে তার সংগ্রহ প্রক্রিয়া বর্তমান মার্কিন আইন এবং টার্গেট সাইটের নিজস্ব পরিষেবার শর্তাবলীর মধ্যে থাকে।
সাধারণ ভুল
টিমগুলো যখন নিজেদের সেটআপ পরীক্ষা করে তখন কিছু প্রক্রিয়াগত ভুল বারবার দেখা যায়। একবার পরীক্ষা করে লাইব্রেরি আপডেটের পর আর পুনরায় যাচাই না করা সবচেয়ে সাধারণ ভুল, কারণ একটি ডিপেন্ডেন্সি তার TLS ব্যাকএন্ড বদলানোর সাথে সাথেই TLS ফিঙ্গারপ্রিন্টিংয়ের ফলাফল বদলে যেতে পারে। প্রোডাকশনের সাথে না মেলা একটি স্টেজিং এনভায়রনমেন্টে পরীক্ষা চালানো আরেকটি ভুল, কারণ গুরুত্বপূর্ণ আসল রিকোয়েস্ট পথটি, কোনো লোকাল শেল নয়।
- ❌ একবার পরীক্ষা করে ধরে নেওয়া যে ফলাফটি চিরকালের জন্য বৈধ থাকবে।
- ❌ যে পরিবেশে কাজটি আসলে চলে তার থেকে ভিন্ন পরিবেশে ফিঙ্গারপ্রিন্ট যাচাই করা।
- ❌ একটি দ্বিতীয় তুলনা-বিন্দু ছাড়া একটি একক ভেরিফিকেশন সার্ভিসকে বিশ্বাস করা।
- ❌ শুধু TLS স্তরের পেছনে ছুটে HTTP/2 সেটিংস উপেক্ষা করা।
প্রক্সির গুণমান কীভাবে চিত্রে বসে
প্রকাশ: Insocks আমাদের সেবা, এবং এই অংশটি বর্ণনা করে একটি বৃহত্তর সংগ্রহ স্ট্যাকের ভেতরে প্রক্সি অবকাঠামো আসলে কী করে। ভালো প্রক্সি অবকাঠামো IP-স্তরের সমস্যাগুলো সমাধান করে: ভৌগোলিক অবস্থান, IP রেপুটেশন এবং সংযোগের স্থিতিশীলতা, যেখানে TLS ফিঙ্গারপ্রিন্টিং একটি আলাদা স্তর হিসেবেই থাকে যা কেবল একটি প্রক্সি স্পর্শ করতে পারে না। নির্ভরযোগ্য আপটাইম এবং পরিচ্ছন্ন IP পুল IP-ভিত্তিক রেট লিমিট এড়াতে গুরুত্বপূর্ণ, কিন্তু সেগুলো একটি হ্যান্ডশেকের ভেতরের cipher suite-এর ক্রম বা extension-এর তালিকা সম্পর্কে কিছুই বলে না।
সংগ্রহের কাজের জন্য আমরা রেসিডেনশিয়াল প্রক্সি এবং স্ট্যাটিক IP প্রক্সি বিক্রি করি, উভয়েরই ডকুমেন্টেড প্রোটোকল সমর্থন এবং অবস্থানের ডেটা আছে। কঠিন প্রক্সি অবকাঠামোকে সঠিকভাবে কনফিগার করা একটি ক্লায়েন্টের সাথে মিলিয়ে — সেটা একটি পূর্ণ ব্রাউজার ইঞ্জিন হোক বা যত্নে মেলানো একটি লাইব্রেরি — একসাথে উভয় স্তরেরই সমাধান করে, একটিকে উন্মুক্ত রেখে নয়।
| ফিচার | ব্যবহারিকভাবে এর অর্থ কী |
|---|---|
| রেসিডেনশিয়াল এবং ISP IP পুল | IP-ভিত্তিক রেপুটেশন ফ্ল্যাগ কমায়, TLS স্পর্শ করে না |
| ভৌগোলিক টার্গেটিং | রিকোয়েস্টের উৎসকে প্রত্যাশিত বাজারের সাথে মেলায় |
| সেশন নিয়ন্ত্রণ | একটি বহু-ধাপী প্রবাহ জুড়ে IP-কে স্থির রাখে |
| আপটাইম এবং সাপোর্ট | ফিঙ্গারপ্রিন্টিং-সম্পর্কিত নয় এমন সংযোগ ব্যর্থতা কমায় |
প্রক্সি নেটওয়ার্ক স্তরের সমাধান করে, TLS ফিঙ্গারপ্রিন্টের নয়, এবং অন্যরকম ইঙ্গিত করা যেকোনো প্রোভাইডার একটি IP পরিবর্তন যা করতে পারে তার চেয়ে বেশি বিক্রি করছে। যেসব টিমের উভয় স্তরেরই সমাধান দরকার তারা সাধারণত মানসম্পন্ন প্রক্সি অবকাঠামো, যেমন Insocks রেসিডেনশিয়াল এবং ISP প্রক্সি, একটি ব্রাউজার-ভিত্তিক বা সঠিকভাবে মেলানো ক্লায়েন্টের সাথে জুড়ে দেয়।
🔗 একটি প্ল্যানে অঙ্গীকারবদ্ধ হওয়ার আগে প্রক্সি পুলগুলো তুলনা করতে সম্পূর্ণ অ্যাক্সেসের জন্য নিবন্ধন করুন।
মূল মন্তব্য
- tls হ্যান্ডশেক যেকোনো HTTP হেডারের আগেই পড়া হয়, এবং এই ডিটেকশন পদ্ধতির সম্পূর্ণ ভিত্তিটি এটিই।
- JA3-এর উত্তরসূরি হ্যাশ extension-এর ক্রম র্যান্ডমাইজ করার পরও স্থিতিশীল থাকে, তার পূর্বসূরির মতো নয়।
- JA3 কী তা বোঝা স্পষ্ট করে কেন ব্রাউজার-সদৃশ ক্লায়েন্টরা স্ক্রিপ্টেড ক্লায়েন্টদের তুলনায় বেশি সামঞ্জস্যের সাথে যাচাই পাস করে।
- প্রক্সি IP-এর সমস্যা সমাধান করে; নিজে থেকে কখনোই একটি tls হ্যান্ডশেক পুনর্লিখন করে না।
- সামঞ্জস্যপূর্ণ, ব্রাউজার-সদৃশ JA3 ফিঙ্গারপ্রিন্টের জন্য পূর্ণ ব্রাউজার অটোমেশনই সবচেয়ে নির্ভরযোগ্য পথ হয়ে থাকে।
প্রকাশ এবং ডেটা উৎস
এই নিবন্ধের সব ডেটা, দাম, ট্যারিফ স্তর, সীমা এবং পণ্যের প্রাপ্যতা সহ, এই পৃষ্ঠায় দেখানো প্রকাশনার তারিখ অনুযায়ী সঠিক। ভেন্ডরের শর্তাবলী প্রায়ই এবং পূর্ব সূচনা ছাড়াই পরিবর্তিত হয়, এন্ট্রি স্তরগুলো ভলিউমের সাথে বদলায়, এবং আপনি যেদিন এটি পড়ছেন সেদিন প্রমোশনাল মূল্য প্রযোজ্য থাকতে পারে। এখানে কিছুই কোনো অফার, বর্তমান শর্তের নিশ্চয়তা বা কেনার সুপারিশ নয়।
এই নিবন্ধটি Insocks দ্বারা প্রকাশিত। আমরা প্রক্সি বিক্রি করি এবং উপরের শেষ অংশে একটি বাণিজ্যিক স্বার্থ প্রকাশ করি। প্রক্সি একটি JA3 ফিঙ্গারপ্রিন্ট বা অন্য কোনো TLS সংকেত পরিবর্তন করে না, এবং আমরা অন্যরকম ইঙ্গিত না করে তা সরাসরি বলি। এখানে উল্লিখিত পরীক্ষার টুল এবং লাইব্রেরি, যার মধ্যে Scrapfly-এর চেকার, curl-impersonate এবং ব্রাউজার অটোমেশন ফ্রেমওয়ার্ক রয়েছে, সেগুলোর স্বতন্ত্র মালিকদের এবং শুধুমাত্র শনাক্তকরণের উদ্দেশ্যেই উপস্থিত। এই লেখার বিবরণগুলো আগস্ট, ২০২৬-এ যাচাই করা হয়েছিল, এবং লাইব্রেরি বা ব্রাউজার সংস্করণের মধ্যে ক্লায়েন্ট আচরণ বদলে যেতে পারে।
সাধারণ প্রশ্ন
নিচের প্রশ্নগুলো এই বিষয়ে প্রথমবার পড়ার পর মানুষ সাধারণত যেসব মৌলিক বিষয় জিজ্ঞেস করে তা কভার করে। উত্তরগুলো সংক্ষিপ্ত ও তথ্যভিত্তিক রাখা হয়েছে, একটি ব্রাউজার ট্যাব বা কমান্ড লাইন টুল আসলে যা দেখাবে তার সাথে মিলিয়ে। এর কোনোটাই বাইপাস গাইড নয়, কারণ এখানে লক্ষ্য বোঝা, এড়িয়ে যাওয়া নয়।
TLS ফিঙ্গারপ্রিন্ট কী?
হ্যান্ডশেক ডেটা থেকে তৈরি একটি ছোট সিগনেচার যা শনাক্ত করে কোন সফটওয়্যার সংযোগটি তৈরি করেছে।
একটি JA3 হ্যাশ কীভাবে গণনা করা হয়?
হ্যান্ডশেকের পাঁচটি ফিল্ড একত্রিত করে একটি ৩২-অক্ষরের স্ট্রিং-এ হ্যাশ করা হয়।
JA3 এবং JA4-এর মধ্যে পার্থক্য কী?
নতুন পদ্ধতিটি extension সাজায় এবং একটি শক্তিশালী হ্যাশ ব্যবহার করে, ব্রাউজার ক্রম র্যান্ডমাইজ করার পরও স্থিতিশীল থাকে।
একটি রেসিডেনশিয়াল প্রক্সি আমার TLS ফিঙ্গারপ্রিন্ট লুকাতে পারে?
না, একটি প্রক্সি শুধু IP ঠিকানা পরিবর্তন করে; হ্যান্ডশেকটি অপরিবর্তিতভাবে যায়।
সঠিক হেডার থাকা সত্ত্বেও আমার স্ক্র্যাপার কেন ব্লক হয়?
হেডার হ্যান্ডশেকের পরে লোড হয়, তাই অমিলযুক্ত ক্লায়েন্ট প্রোফাইল আগেই ফ্ল্যাগ হয়।
আমি নিজের TLS ফিঙ্গারপ্রিন্ট কীভাবে যাচাই করব?
একটি পাবলিক চেকিং টুলে একটি রিকোয়েস্ট পাঠান এবং একটি আসল ব্রাউজারের ফলাফলের সাথে তুলনা করুন।