TLS-फिंगरप्रिंट पार्सर: कैसे जांचें और पकड़े न जाएं

आपने एक महंगा रेजिडेंशियल IP लिया, रोटेशन सेट किया, एक यथार्थवादी User-Agent डाला — लेकिन परसिंग फिर भी कैप्चा में चला जाता है या खाली उत्तर प्राप्त करता है। समस्या लगभग हमेशा IP में नहीं होती, बल्कि TLS-फ़िंगरप्रिंट में होती है: जिस पुस्तकालय का आप HTTPS अनुरोध भेज रहे हैं, वह असली ब्राउज़र की तरह "सुनाई" नहीं देता। एंटी-बॉट सिस्टम Wildberries, Ozon, Cloudflare और Akamai इसे आपके IP पते की जांच करने से पहले देख लेते हैं।

TLS-फ़िंगरप्रिंट क्या है और यह IP से क्यों अधिक महत्वपूर्ण है

जब ग्राहक HTTPS कनेक्शन स्थापित करता है, तो वह सर्वर को ClientHello पैकेट भेजता है — TLS हैंडशेक का एक हिस्सा। इसमें TLS के समर्थित संस्करणों की सूची, एन्क्रिप्शन सेट (cipher suites), एक्सटेंशन का क्रम (extensions), अंडर-ऑलिप्टिक कर्व्स और संकुचन एल्गोरिदम एन्क्रिप्टेड होते हैं। यह सेटिंग्स "पुस्तकालय + ऑपरेटिंग सिस्टम + TLS स्टैक संस्करण" के लिए अद्वितीय होती हैं।

Chrome, Firefox और Safari अपने तरीके से ClientHello बनाते हैं, और यह सेटिंग्स अनुरोध से अनुरोध में लगभग नहीं बदलती हैं — IP या User-Agent के विपरीत, जिन्हें टेक्स्ट द्वारा आसानी से फर्जी बनाया जा सकता है। लेकिन मानक HTTP पुस्तकालय — requests, urllib3, Java में मानक HttpClient, Node.js में अंतर्निहित TLS स्टैक — एक बिल्कुल अलग ClientHello बनाते हैं, क्योंकि वे OpenSSL या अन्य पुस्तकालय का उपयोग करते हैं, जो ब्राउज़र से अलग है।

यही कारण है कि आप एक बिल्कुल "साफ़" रेजिडेंशियल IP कनेक्ट कर सकते हैं, असली Chrome का ताज़ा User-Agent डाल सकते हैं — और फिर भी ब्लॉक प्राप्त कर सकते हैं। सर्वर उपयोगकर्ता के रेजिडेंशियल IP को देखता है, "Chrome 124" हेडर देखता है, लेकिन TLS हैंडशेक कहता है: "यह एक Python स्क्रिप्ट है"। असमानता — एंटी-बॉट के लिए सीधा संकेत है।

एंटी-बॉट सिस्टम कैसे JA3/JA4 द्वारा परसिंग को पहचानते हैं

ClientHello के पैरामीटर्स को संक्षिप्त पहचानकर्ता में बदलने के लिए JA3 (और इसके नए संस्करण JA4) एल्गोरिदम का उपयोग किया जाता है। यह TLS संस्करण, एन्क्रिप्शन की सूची, एक्सटेंशन और कर्व्स को लेता है, उन्हें एक स्ट्रिंग में जोड़ता है और MD5 के माध्यम से हैश करता है। परिणामस्वरूप एक छोटा हैश प्राप्त होता है जैसे 769,47-53-5-10...,0-23-65281...,29-23-24,0, जो ग्राहक के "फ़िंगरप्रिंट" की स्पष्ट पहचान करता है।

एंटी-बॉट प्रदाता (Cloudflare, Akamai, PerimeterX, DataDome — और उनके समकक्ष, जो Wildberries और Ozon का उपयोग करते हैं) लोकप्रिय HTTP पुस्तकालयों के ज्ञात JA3/JA4 हैश का डेटाबेस रखते हैं: requests, aiohttp, Scrapy, Node fetch, Java HttpClient, Go net/http। यदि हैश ज्ञात "स्क्रिप्ट" सिग्नेचर के साथ मेल खाता है, न कि Chrome/Firefox/Safari के सिग्नेचर के साथ — अनुरोध को व्यवहार के विश्लेषण से पहले ही संदिग्ध के रूप में चिह्नित किया जाता है।

फिर सिस्टम TLS फ़िंगरप्रिंट और घोषित User-Agent के बीच मेल को देखता है। यदि हेडर में "Windows पर Chrome 124" लिखा है, और TLS फ़िंगरप्रिंट Python की मानक पुस्तकालय से OpenSSL 1.1.1 के साथ मेल खाता है — इसे TLS/HTTP mismatch कहा जाता है, जो स्वचालन के डिटेक्ट का सबसे विश्वसनीय संकेतों में से एक है। इसी तरह परसिंग को पहचानते हैं, भले ही रेजिडेंशियल IP और सही हेडर हों।

अपने TLS-फ़िंगरप्रिंट की जांच कैसे करें: उपकरण

समस्या को ठीक करने से पहले, आपको यह देखना होगा कि सर्वर क्या देखता है। कुछ सार्वजनिक सेवाएँ हैं जो आपके JA3/JA4 हैश और ClientHello के पूर्ण सेट को दिखाती हैं:

tls.peet.ws — JA3, JA4, एन्क्रिप्शन और एक्सटेंशन की सूची JSON प्रारूप में दिखाता है, जो स्वचालित रूप से स्क्रिप्ट द्वारा जांचने के लिए सुविधाजनक है।
ja3er.com — विशिष्ट पुस्तकालयों और ब्राउज़रों के साथ जुड़ी ज्ञात JA3 हैश का डेटाबेस।
browserleaks.com/tls — आपके फ़िंगरप्रिंट की सामान्य ब्राउज़रों के साथ दृश्य तुलना।
Wireshark स्थानीय रूप से — यदि आप अपने स्क्रिप्ट से अनुरोध भेजने पर ClientHello का कच्चा पैकेट देखना चाहते हैं।

व्यावहारिक परीक्षण सरल है: सामान्य Chrome में tls.peet.ws खोलें और JA4 हैश запис करें। फिर अपने परसिंग से उसी पते पर GET अनुरोध भेजें (requests, curl_cffi या किसी अन्य पुस्तकालय के माध्यम से) उसी प्रॉक्सी के माध्यम से और हैश की तुलना करें। यदि वे भिन्न हैं — सर्वर हर अनुरोध पर "ब्राउज़र" और "स्क्रिप्ट" के बीच अंतर देखता है, चाहे IP कितना भी साफ़ हो।

Python पर जांच: requests, httpx, curl_cffi

हम व्यावहारिक रूप से समझते हैं कि क्यों मानक Python पुस्तकालय परसिंग को पहचानते हैं। requests के माध्यम से सामान्य अनुरोध:

import requests

resp = requests.get("https://tls.peet.ws/api/all", proxies={
    "https": "http://user:pass@proxy_host:port"
})
print(resp.json()["tls"]["ja4"])
# परिणाम वास्तविक Chrome के JA4 से भिन्न होगा,
# क्योंकि requests Python के मानक ssl-मॉड्यूल का उपयोग करता है

समस्या यह है कि requests और httpx सिस्टम के OpenSSL का उपयोग करते हैं ssl मॉड्यूल के माध्यम से, और TLS के एक्सटेंशन का क्रम और सेटिंग्स कठोर रूप से निर्धारित हैं और Chrome/Firefox के साथ मेल नहीं खाते। समाधान है curl_cffi पुस्तकालय, जो वास्तविक ब्राउज़रों के साथ सही TLS प्रोफाइल का उपयोग करने के लिए पैच किया गया curl का उपयोग करता है:

from curl_cffi import requests as cffi_requests

resp = cffi_requests.get(
    "https://tls.peet.ws/api/all",
    impersonate="chrome124",
    proxies={"https": "http://user:pass@proxy_host:port"}
)
print(resp.json()["tls"]["ja4"])
# हैश वास्तविक Chrome 124 पर डेस्कटॉप पर समान होगा

impersonate पैरामीटर curl_cffi को केवल ClientHello को पुन: उत्पन्न करने के लिए नहीं बल्कि HTTP/2 हेडर के क्रम (frame order) को भी पुन: उत्पन्न करने के लिए मजबूर करता है, जो भी फ़िंगरप्रिंट में शामिल होता है। इसी तरह का दृष्टिकोण tls-client पुस्तकालयों के लिए Go और undetected-chromedriver के लिए उपयोग किया जाता है, जो वास्तविक ब्राउज़र के माध्यम से परसिंग करते हैं, न कि HTTP क्लाइंट के माध्यम से।

यदि परसिंग headless ब्राउज़र (Playwright, Puppeteer, Selenium) के माध्यम से की जाती है, तो TLS-फ़िंगरप्रिंट Chromium/Firefox इंजन द्वारा उत्पन्न होता है और डिफ़ॉल्ट रूप से वास्तविक ब्राउज़र के साथ मेल खाता है। लेकिन यहाँ एक और समस्या आती है — JS स्तर पर स्वचालन के सिग्नेचर (webdriver-फ्लैग, canvas fingerprint), इसलिए headless परिदृश्यों के लिए अतिरिक्त पैच जैसे playwright-stealth की आवश्यकता होती है।

TLS + HTTP/2 + हेडर: क्यों संयोजन महत्वपूर्ण है

TLS-फ़िंगरप्रिंट केवल डिटेक्ट का एक स्तर है। एंटी-बॉट सिस्टम एक साथ कई स्तरों की तुलना करते हैं:

TLS ClientHello (JA3/JA4) — एन्क्रिप्शन और एक्सटेंशन का सेट।
HTTP/2 फ़िंगरप्रिंट — पseudo-headers (:method, :path, :authority) का क्रम, SETTINGS-फ्रेम सेटिंग्स, विंडो का आकार।
HTTP हेडर — सामान्य हेडर का क्रम और सेट (Accept-Language, Sec-Ch-Ua, Sec-Fetch-*).
User-Agent — TLS प्रोफाइल के संस्करण के साथ मेल खाना चाहिए: यदि UA कहता है "Chrome 124", और TLS Chrome 110 के साथ मेल खाता है, तो यह भी संदिग्ध है।

एक सामान्य गलती — User-Agent को Chrome के नवीनतम संस्करण में अपडेट करना, जबकि curl_cffi या अन्य पुस्तकालय में TLS प्रोफाइल को अपडेट करना भूल जाना। संस्करणों का यह अंतर एंटी-बॉट को उतनी स्पष्टता से दिखाई देता है जितनी कि पूरी तरह से छिपाने की अनुपस्थिति। सुनिश्चित करें कि impersonate का संस्करण और User-Agent में संस्करण मेल खाते हैं, और नए ब्राउज़र संस्करणों के जारी होने पर दोनों पैरामीटर को समन्वयित रूप से अपडेट करें।

एक और बिंदु — हेडर का क्रम। ब्राउज़र हेडर को एक निश्चित क्रम में भेजता है, जबकि कई HTTP पुस्तकालय उन्हें वर्णानुक्रम में या कोड में जोड़ने के क्रम में क्रमबद्ध करते हैं। भले ही हेडर का सेट ब्राउज़र के साथ समान हो, गलत क्रम — DataDome जैसी उन्नत एंटी-बॉट सिस्टम के लिए एक अतिरिक्त संकेत है।

प्रॉक्सी की भूमिका: क्यों साफ़ IP मदद नहीं करता

रेजिडेंशियल IP एक विशिष्ट कार्य को हल करता है — भूगोल, ASN और पते की प्रतिष्ठा के आधार पर संदेह को कम करता है। डेटा सेंटर IP अक्सर काले सूचियों में होते हैं, क्योंकि उनसे स्वचालित ट्रैफ़िक बड़े पैमाने पर आता है, जबकि रेजिडेंशियल असली प्रदाताओं और सामान्य उपयोगकर्ताओं के होते हैं। Wildberries, Ozon या Avito पर परसिंग के लिए यह महत्वपूर्ण है: बिना साफ़ IP के, अनुरोध को केवल इसी संकेत पर ब्लॉक किया जाता है, बिना TLS की जांच किए।

लेकिन IP और TLS-फ़िंगरप्रिंट — ये दो स्वतंत्र सुरक्षा स्तर हैं, और ये विभिन्न समस्याओं को हल करते हैं। IP सर्वर को बताता है "कहाँ" अनुरोध आया, TLS-फ़िंगरप्रिंट बताता है "किससे" इसे भेजा गया। इसलिए एक साफ़ IP और सही TLS प्रोफाइल का संयोजन — स्थिर परसिंग के लिए न्यूनतम सेट है। उच्च अनुरोध आवृत्ति और आक्रामक एंटी-बॉट के मामलों के लिए, रेजिडेंशियल प्रॉक्सी का उपयोग करना बेहतर है, वे IP प्रतिष्ठा के आधार पर कम बैन प्रतिशत देते हैं, लेकिन उन्हें उस पुस्तकालय के साथ संयोजित करना आवश्यक है जो वास्तविक ब्राउज़र के TLS प्रोफाइल को सही ढंग से पुन: उत्पन्न करता है।

मार्केटप्लेस पर कीमतों की निगरानी के लिए, जहां गति और अनुरोधों की मात्रा महत्वपूर्ण है, अक्सर डेटा सेंटर प्रॉक्सी का उपयोग TLS मास्किंग के साथ curl_cffi के माध्यम से किया जाता है — यह रेजिडेंशियल से सस्ता है और यदि साइट की एंटी-बॉट सिस्टम बहुत आक्रामक नहीं है तो यह काफी प्रभावी है। और उन कार्यों के लिए जहां साइट सक्रिय रूप से मोबाइल नेटवर्क की जांच करती है (जैसे, API के माध्यम से मोबाइल ऐप के संस्करणों की परसिंग), मोबाइल प्रॉक्सी का उपयोग किया जाता है — वे ऑपरेटर नेटवर्क की प्रतिष्ठा के कारण अतिरिक्त स्तर की विश्वसनीयता प्रदान करते हैं।

बिना डिटेक्ट के परसिंग सेटअप की चेकलिस्ट

परसिंग को उत्पादन में चलाने से पहले जांच को एक प्रक्रिया में संकलित करें:

tls.peet.ws के माध्यम से अपने स्क्रिप्ट के JA4 हैश को मापें और इसे उसी संस्करण के वास्तविक ब्राउज़र के साथ तुलना करें।
TLS-इम्पर्सनैशन का समर्थन करने वाली पुस्तकालय का उपयोग करें: curl_cffi (Python), tls-client (Go), CycleTLS (Node.js)।
TLS प्रोफाइल (impersonate) के संस्करण को User-Agent में संस्करण के साथ समन्वयित करें।
HTTP हेडर के क्रम की जांच करें — यह वास्तविक ब्राउज़र के साथ मेल खाना चाहिए, न कि वर्णानुक्रम में।
अपने कार्य के भूगोल के तहत साफ़ रेजिडेंशियल या मोबाइल IP कनेक्ट करें।
IP रोटेशन को TLS प्रोफाइल से अलग सेट करें — एक को दूसरे के साथ कठोरता से न जोड़ें।
Chrome के नए संस्करणों के जारी होने पर नियमित रूप से TLS प्रोफाइल को अपडेट करें — पुराने सिग्नेचर एंटी-बॉट डेटाबेस में तेजी से पहुंचते हैं।
JS-चेक वाले परिदृश्यों (Cloudflare Challenge) के लिए, साफ़ HTTP क्लाइंट के बजाय stealth पैच के साथ headless ब्राउज़र का उपयोग करें।

पुस्तकों और उपकरणों की तुलना

उपकरण	ब्राउज़र का TLS-फ़िंगरप्रिंट	गति	कब उपयोग करें
requests / httpx	नहीं, स्क्रिप्ट देता है	उच्च	TLS डिटेक्ट के बिना साइटें, आंतरिक API
curl_cffi	हाँ, सटीक प्रतिकृति	उच्च	मार्केटप्लेस, Cloudflare/Akamai एंटी-बॉट
tls-client (Go)	हाँ	बहुत उच्च	उच्च लोड, बड़े पैमाने पर परसिंग
Playwright / Puppeteer	हाँ, असली इंजन	कम	JS-रेन्डर, Cloudflare Challenge, जटिल SPA
Scrapy (मानक)	नहीं	उच्च	साइटें बिना सख्त एंटी-बॉट सुरक्षा

निष्कर्ष

TLS-फ़िंगरप्रिंट एक सुरक्षा स्तर है, जिसे कई परसर्स पूरी तरह से अनदेखा करते हैं, आदर्श IP और User-Agent के चयन पर संसाधन खर्च करते हैं, लेकिन यह भूल जाते हैं कि TLS हैंडशेक की संरचना स्वचालन को सर्वर के हेडर पर नज़र डालने से पहले ही प्रकट कर देती है। समाधान है TLS-इम्पर्सनैशन का समर्थन करने वाली पुस्तकालयों का उपयोग करना (curl_cffi, tls-client), प्रोफाइल संस्करण को User-Agent के साथ समन्वयित करना और स्केल पर चलाने से पहले अंतिम JA4 हैश की जांच करना।

IP फिर भी एक महत्वपूर्ण कारक बना रहता है — बिना साफ़ पते के, यहां तक कि आदर्श TLS-फ़िंगरप्रिंट भी नेटवर्क की प्रतिष्ठा के आधार पर ब्लॉक को बायपास करने में मदद नहीं करेगा। मार्केटप्लेस पर परसिंग और कीमतों की निगरानी के लिए, सही TLS सेटअप को रेजिडेंशियल प्रॉक्सी के साथ संयोजित करना समझदारी है — यह संयोजन दोनों डिटेक्ट स्तरों को बंद करता है और परसिंग के लंबे सत्रों में बैन प्रतिशत को काफी कम करता है।