TLS फिंगरप्रिंटिंग और JA3: यह स्क्रेपिंग को कैसे प्रभावित करता है

TLS फिंगरप्रिंटिंग, किसी HTTP क्लाइंट की पहचान उसके TLS हैंडशेक की संरचना से करती है, इससे पहले कि कोई एप्लिकेशन डेटा भेजा जाए। JA3 और JA4, ClientHello मैसेज के फ़ील्ड्स को एक छोटे हैश में बदलते हैं, और एंटी-बॉट सिस्टम उस हैश की तुलना ज्ञात ब्राउज़र और बॉट सिग्नेचर से करते हैं। दावा किए गए ब्राउज़र और हैश के बीच बेमेल होने पर अनुरोध के हेडर पढ़े जाने से पहले ही अस्वीकार किया जा सकता है।

नीचे दी गई हर तालिका में प्रयुक्त लीजेंड: ✅ वेंडर द्वारा डॉक्यूमेंटेड · ❌ ऑफर नहीं किया गया या डॉक्यूमेंटेड नहीं · ⚠️ सीमाओं के साथ डॉक्यूमेंटेड · 💡 व्यावहारिक टिप। इस पेज पर कोई अन्य चिह्न उपयोग नहीं किए गए हैं।

TLS फिंगरप्रिंट क्या है

TLS फिंगरप्रिंट एक छोटा सिग्नेचर है जो उन फ़ील्ड्स से बनता है जो कोई HTTP क्लाइंट tls हैंडशेक के दौरान अपने client hello मैसेज में भेजता है, यानी एन्क्रिप्शन शुरू होने से भी पहले। JA3 क्या है इसे समझना यहीं से शुरू होता है: JA3 इनमें से पाँच फ़ील्ड्स को पढ़ता है और उन्हें एक ही हैश में बदल देता है। हर क्लाइंट, चाहे वह Chrome हो, curl हो, या कोई Python स्क्रिप्ट हो, cipher suites, extensions और elliptic curves को अपने विशेष क्रम में सूचीबद्ध करता है। सर्वर इस डेटा को plaintext में पढ़ते हैं, क्योंकि अभी न तो किसी पक्ष ने एन्क्रिप्शन कीज़ पर सहमति दी है।

Client hello एक alpn एक्सटेंशन भी ले जाता है, जो सर्वर को बताता है कि कनेक्शन HTTP/1.1 पसंद करता है या HTTP/2। अलग-अलग लाइब्रेरीज़ इन फ़ील्ड्स को अलग तरीके से जोड़ती हैं, जो नीचे की TLS स्टैक पर निर्भर करता है, जैसे OpenSSL बनाम BoringSSL बनाम NSS। यही वह कच्चा सामग्री है जिस पर JA3 और JA4 दोनों काम करते हैं।

💡 टिप: अगर दो अनुरोधों में एक ही फिंगरप्रिंट है लेकिन घोषित ब्राउज़र अलग-अलग हैं, तो यह असंगति अकेले ही, बिना किसी हेडर ट्रिक के, संदेह पैदा कर सकती है।

JA3 और JA4 की गणना कैसे होती है

JA3 फिंगरप्रिंट की गणना ClientHello के पाँच फ़ील्ड्स को एक स्ट्रिंग में जोड़कर और उसे MD5 से हैश करके की जाती है, जिससे एक 32-कैरेक्टर का सिग्नेचर बनता है (Scrapfly, JA3/JA4 TLS Fingerprinting Guide, 2026)। John Althouse, Jeff Atkinson और Josh Atkins ने 2017 में Salesforce पर यह मूल मेथड प्रकाशित किया, और यह आज भी ज़्यादातर TLS आधारित बॉट जाँचों की रीढ़ है। उस हैश में जाने वाले पाँच फ़ील्ड्स हैं TLS संस्करण, cipher suites, extensions, elliptic curves और point formats, जो एक निश्चित क्रम में जुड़ते हैं।

1. TLS संस्करण निकालें, जिसे दशमलव संख्या के रूप में व्यक्त किया जाता है, जैसे TLS 1.2 के लिए 771।
2. Cipher suites को ठीक उसी क्रम में सूचीबद्ध करें जिस क्रम में क्लाइंट ने भेजा, हाइफ़न से अलग करके।
3. TLS एक्सटेंशन को भेजे गए क्रम में सूचीबद्ध करें, हाइफ़न से अलग करते हुए, GREASE वैल्यूज़ को छोड़ते हुए।
4. समर्थित elliptic curves और point formats जोड़ें।
5. सभी पाँच फ़ील्ड्स को कॉमा से जोड़ें और परिणामी स्ट्रिंग को MD5 से हैश करें ताकि ja3 हैश मिले।

ClientHello से JA3 हैश कैसे बनता है

नई मेथड चरण 3 में क्रम की समस्या को छोड़ देती है। एक्सटेंशन को भेजे गए रूप में दर्ज करने के बजाय, यह उन्हें hexadecimal वैल्यू के अनुसार सॉर्ट करती है, जिससे JA4 फिंगरप्रिंट स्थिर रहता है, भले ही ब्राउज़रों ने 2023 में एक्सटेंशन क्रम को रैंडमाइज़ करना शुरू कर दिया हो (Scrapfly, 2026)। यह उत्तराधिकारी हैश MD5 को छोड़कर truncated SHA-256 अपनाता है और ALPN तथा QUIC सपोर्ट भी जोड़ता है, विवरण जो JA3 ने कभी कैप्चर नहीं किए।

अपने क्लाइंट का परीक्षण करने वाले किसी भी व्यक्ति के लिए ये संरचनात्मक अंतर मायने रखते हैं। एक तरीके से गणना किया गया फिंगरप्रिंट दूसरी मेथड के लिए बनाए गए डेटाबेस से मेल नहीं खाएगा।

अकेले प्रॉक्सी फिंगरप्रिंटिंग की समस्या क्यों हल नहीं करते

प्रॉक्सी उस IP पते को बदलते हैं जिससे अनुरोध आता है; वे tls हैंडशेक को किसी तरह नहीं छूते, इसलिए TLS फिंगरप्रिंटिंग हमेशा वही लाइब्रेरी देखती है जिसने कनेक्शन शुरू किया। हैंडशेक सीधे क्लाइंट और गंतव्य सर्वर के बीच होता है, और CONNECT मेथड का उपयोग करने वाला एक स्टैंडर्ड HTTPS प्रॉक्सी सिर्फ़ एन्क्रिप्टेड बाइट्स को बिना छुए टनल करता है (Shifter, TLS fingerprint glossary, 2026)। इसका मतलब है कि एक साफ़ residential IP के साथ डिफ़ॉल्ट Python क्लाइंट अभी भी वही फिंगरप्रिंट देता है जो स्क्रिप्ट पढ़ाता है, ब्राउज़र नहीं।

हमारे परीक्षण में, अगस्त 2026, एक डिफ़ॉल्ट requests सेशन जिसे तीन अलग प्रॉक्सी प्रकारों से रूट किया गया, हर बार एक ही हैश लौटाता था, चाहे IP रेप्युटेशन या भौगोलिक स्थिति कुछ भी हो। केवल नीचे की TLS लाइब्रेरी बदलने से ही परिणाम बदला। बातचीत का यही ईमानदार हिस्सा है: IP क्वालिटी और फिंगरप्रिंट मैचिंग दो अलग समस्याएँ हल करते हैं, और एक को दूसरी का इलाज समझने में तेज़ी से निराशा मिलती है।

"TLS फिंगरप्रिंटिंग पहले HTTP बाइट पहुँचने से पहले होती है। IP पता बदलना उसके नीचे के हैंडशेक पर कुछ असर नहीं डालता।" - Insocks इंजीनियरिंग नोट्स, अगस्त 2026

• ❌ एक residential IP cipher suite क्रम को नहीं बदलता।
• ❌ रोटेटिंग प्रॉक्सी TLS हैंडशेक फ़ील्ड्स को नहीं छूते।

प्रॉक्सी क्या बदलता है और क्या वैसा ही छोड़ देता है

• ✅ किसी असली ब्राउज़र की TLS स्टैक से मिलाना ही वास्तव में फिंगरप्रिंट बदलता है।

एंटी-बॉट सिस्टम TLS फिंगरप्रिंट का उपयोग कैसे करते हैं

एंटी-बॉट सिस्टम हर आने वाले ClientHello से एक हैश गणना करते हैं और उसे ज्ञात ब्राउज़र तथा बॉट फिंगरप्रिंट के डेटाबेस से जाँचते हैं, फिर ब्लॉक, चैलेंज या पास का निर्णय लेने से पहले उस सिग्नल को अन्य लेयर्स के साथ जोड़ते हैं। TLS फिंगरप्रिंटिंग HTTP हेडर से पूरी तरह नीचे बैठती है, इसीलिए सही हेडर के साथ एक स्क्रिप्टेड TLS स्टैक अभी भी पकड़ा जाता है। Cloudflare अपने bot management प्रोडक्ट में JA3 और JA4 फ़ील्ड्स को डॉक्यूमेंट करता है, और अन्य वेंडर्स भी ऐसी ही जाँचें चलाते हैं (Scrapfly, 2026)। स्कोरिंग TLS सिग्नल को अनुरोध टाइमिंग, IP रेप्युटेशन और बिहेवियरल डेटा के साथ मिलाती है बजाय किसी एक फ़ील्ड पर भरोसा किए।

कुछ वेंडर्स हैंडशेक जाँच के ऊपर http2 फिंगरप्रिंटिंग भी जोड़ते हैं, पढ़ते हुए कि क्लाइंट TLS लेयर पूरा होने के बाद stream priorities और window sizes के लिए कैसे बातचीत करता है। यह दूसरी लेयर JA3 और JA4 हैश के साथ व्यापक anti bot डिटेक्शन स्कोरिंग में जाती है। वेंडर्स ब्राउज़र संस्करणों के साथ इन डेटाबेस को अपडेट रखते हैं, और पिछली तिमाही में पास होने वाला फिंगरप्रिंट ब्राउज़र अपडेट के बाद फेल होना शुरू कर सकता है जब उसके डिफ़ॉल्ट बदल जाते हैं।

लेयर्स में स्थिरता: TLS, HTTP/2, हेडर और IP

लेयर्स में स्थिरता का मतलब है कि tls हैंडशेक, http2 settings फ़्रेम, घोषित User-Agent, और IP का नेटवर्क प्रकार — सबको एक ही कहानी की ओर इशारा करना चाहिए, कोई असली ब्राउज़र या असली क्लाइंट, बेमेल सिग्नल का संयोजन नहीं। Http2 फिंगरप्रिंटिंग देखती है कि क्लाइंट हैंडशेक पूरा होने के बाद stream priorities और window sizes के लिए कैसे बातचीत करता है, और यह दूसरी लेयर है जिसे कुछ एंटी-बॉट वेंडर्स JA3 और JA4 डेटा के साथ जाँचते हैं (Scrapfly, 2026)। वह स्क्रेपर जो अपनी TLS स्टैक ठीक करता है लेकिन HTTP/2 सेटिंग्स को नज़रअंदाज़ करता है, अभी भी एक स्पष्ट कमी छोड़ता है।

एक अनुरोध जो चार लेयर्स प्रकट करता है, और हर एक क्या दिखाता है

User agent स्थिरता भी मायने रखती है, क्योंकि Chrome 124 का दावा करता User-Agent स्ट्रिंग पुराने JA4 फिंगरप्रिंट प्रोफ़ाइल के साथ अपने आप में ही एक विरोधाभास पढ़ाता है। एंटी-बॉट वेंडर्स ठीक इसी तरह के बेमेल को फ़्लैग करते हैं, भले ही हर व्यक्तिगत हेडर सही दिखे। इन जाँचों के लिए लक्ष्य साइट पर कुछ भी बायपास करने की ज़रूरत नहीं है; वे सिर्फ़ यह पुष्टि करते हैं कि किसी क्लाइंट के अपने सिग्नल अनुरोध जाने से पहले आपस में सहमत हों।

अपना TLS फिंगरप्रिंट कैसे टेस्ट करें

फिंगरप्रिंट का परीक्षण एक जाँच एंडपॉइंट को साफ़ अनुरोध भेजने से शुरू होता है, फिर उसी एंडपॉइंट को ले जाने वाले असली ब्राउज़र से साइड-बाय-साइड तुलना। JA4 फिंगरप्रिंट TLS संस्करण, cipher संख्या, एक्सटेंशन संख्या और पहली ALPN वैल्यू को एक पढ़ने योग्य स्ट्रिंग में समूहित करता है, जिससे दिखावटी तुलना रॉ हैश पढ़ने से आसान हो जाती है (Scrapfly, JA3/JA4 fingerprint tool, 2026)। अलग-अलग दिनों में एक ही परीक्षण दो बार चलाने से यह भी पुष्टि होती है कि परिणाम लाइब्रेरी अपडेट्स के बीच स्थिर रहता है।

इसके लिए बने टूल्स, जिनमें Scrapfly का अपना चेकर और curl impersonate जैसी थर्ड पार्टी लाइब्रेरीज़ शामिल हैं — यहाँ एक टूल नाम केवल पहचान के लिए उपयोग हुआ है — बिना अंदाज़े के यह तुलना संभव बनाने के लिए ही मौजूद हैं। Playwright या Puppeteer चलाने वाला हेडलेस ब्राउज़र भी तुलना के लिए असली हैंडशेक देता है, क्योंकि यह स्क्रिप्टेड TLS स्टैक नहीं बल्कि असली ब्राउज़र इंजन लॉन्च करता है।

• चरण 1. जाँच के दायरे में वाले क्लाइंट से एक फिंगरप्रिंट टेस्टिंग एंडपॉइंट को अनुरोध भेजें और लौटाया गया हैश रिकॉर्ड करें।
• चरण 2. एक असली, वर्तमान ब्राउज़र में वही एंडपॉइंट खोलें और तुलना के लिए उसका अपना हैश नोट करें।
• चरण 3. cipher suites, एक्सटेंशन संख्याओं और ALPN वैल्यू की साइड-बाय-साइड तुलना करें, केवल हैश मैच के आधार पर निर्णय न करें।
• चरण 4. जाँचें कि घोषित User-Agent हेडर वास्तव में देखे गए TLS प्रोफ़ाइल से मेल खाता है या नहीं।
• चरण 5. परिणाम को तारीख़ के साथ लॉग करें, क्योंकि लाइब्रेरी या ब्राउज़र अपडेट के बाद हैश बदल सकता है।

👉 देखना चाहते हैं कि एक ठीक से कॉन्फ़िगर किया क्लाइंट एंड-टू-एंड कैसा व्यवहार करता है?  डेमो ट्राई करें Insocks के साथ, पूरा टेस्ट बैच चलाने से पहले।

स्थिर डेटा संग्रह के लिए व्हाइट-हैट प्रैक्टिसेज

व्हाइट-हैट डेटा संग्रह लक्ष्य साइट के अपने नियमों से शुरू होता है: पहले आधिकारिक APIs, robots.txt का सम्मान, और अनुरोध दर को उस स्तर से बहुत नीचे रखना जो सर्वर पर दबाव डाल सके। JA3 क्या है इसे दोबारा देखने से समझ आता है कि पूरे ब्राउज़र इंजन, हेडर ट्रिक्स नहीं, सबसे स्थिर परिणाम क्यों देते हैं, क्योंकि असली ब्राउज़र की TLS स्टैक डिफ़ॉल्ट रूप से ही उसकी घोषित पहचान से मेल खाती है। Playwright, Puppeteer और Selenium तीनों असली ब्राउज़र इंजन लॉन्च करते हैं, इसलिए बिना किसी अतिरिक्त कॉन्फ़िगरेशन के उनका हैंडशेक Chrome या Firefox जैसा दिखता है (Scrapfly, 2026)।

जब कोई पूरा ब्राउज़र काम के लिए बहुत भारी हो, तो कुछ टीमें curl impersonate या इसी तरह की लाइब्रेरीज़ का सहारा लेती हैं, और यह एक उचित समझौता है बशर्ते परिणामी फिंगरप्रिंट को पहले असली ब्राउज़र से टेस्ट किया गया हो। किसी भी तरीके को समझदार टाइमिंग और एक स्पष्ट User-Agent के साथ जोड़ने से संग्रह प्रक्रिया अनुमानित और बाद में ऑडिट करने में आसान रहती है।

• ✅ जहाँ आधिकारिक APIs और डॉक्यूमेंटेड एंडपॉइंट मौजूद हों, वहाँ उन्हें उपयोग करें।
• ✅ robots.txt और लक्ष्य साइट की प्रकाशित शर्तों का सम्मान करें।
• ✅ एक ही एंडपॉइंट पर बर्स्ट फायर करने के बजाय अनुरोधों के बीच अंतराल रखें।
• ✅ टुकड़ों में हेडर या TLS स्पूफिंग के बजाय पूर्ण ब्राउज़र ऑटोमेशन को प्राथमिकता दें।
• 💡 एक धीमा, स्थिर संग्रह शेड्यूल आमतौर पर तेज़, बर्स्टी शेड्यूल से कम सपोर्ट टिकट पैदा करता है।

इस तरीके का उपयोग करके, संयुक्त राज्य अमेरिका से कोई टीम पुष्टि करती है कि उसकी संग्रह प्रक्रिया वर्तमान अमेरिकी कानून और लक्ष्य साइट की अपनी सेवा शर्तों के भीतर रहती है।

सामान्य गलतियाँ

कुछ प्रक्रिया की गलतियाँ बार-बार सामने आती हैं जब टीमें अपना सेटअप जाँचती हैं। एक बार टेस्ट करके लाइब्रेरी अपडेट के बाद दोबारा जाँच न करना सबसे आम है, क्योंकि TLS फिंगरप्रिंटिंग परिणाम उसी पल बदल सकते हैं जब कोई डिपेंडेंसी अपना TLS बैकएंड अपग्रेड करता है। एक ऐसे staging एनवायरनमेंट में परीक्षण चलाना जो प्रोडक्शन से मेल नहीं खाता, दूसरी है, क्योंकि वास्तविक अनुरोध पथ ही मायने रखता है, लोकल शेल नहीं।

• ❌ एक बार टेस्ट करके मान लेना कि परिणाम हमेशा वैध रहेगा।
• ❌ उस एनवायरनमेंट से अलग जगह फिंगरप्रिंट जाँचना जहाँ काम वास्तव में चलता है।
• ❌ दूसरे तुलना बिंदु के बिना एक ही सत्यापन सेवा पर भरोसा करना।
• ❌ केवल TLS लेयर का पीछा करते हुए HTTP/2 सेटिंग्स को नज़रअंदाज़ करना।

प्रॉक्सी क्वालिटी इस तस्वीर में कैसे फिट होती है

डिस्क्लोज़र: Insocks हमारी सेवा है, और यह सेक्शन बताता है कि प्रॉक्सी इंफ्रास्ट्रक्चर एक व्यापक संग्रह स्टैक के भीतर वास्तव में क्या करता है। अच्छा प्रॉक्सी इंफ्रास्ट्रक्चर IP-लेयर की समस्याएँ ठीक करता है: भौगोलिक स्थिति, IP रेप्युटेशन और कनेक्शन स्थिरता, जबकि TLS फिंगरप्रिंटिंग एक अलग लेयर बनी रहती है जिसे अकेला प्रॉक्सी नहीं छू सकता। भरोसेमंद uptime और साफ़ IP पूल्स IP-आधारित रेट लिमिट से बचने के लिए मायने रखते हैं, लेकिन वे हैंडशेक के भीतर cipher suite क्रम या एक्सटेंशन सूचियों के बारे में कुछ नहीं बताते।

संग्रह कार्य के लिए हम residential प्रॉक्सी और स्टैटिक IP प्रॉक्सी बेचते हैं, दोनों डॉक्यूमेंटेड प्रोटोकॉल सपोर्ट और लोकेशन डेटा के साथ। ठोस प्रॉक्सी इंफ्रास्ट्रक्चर को एक ठीक से कॉन्फ़िगर किए क्लाइंट के साथ जोड़ना — चाहे वह पूरा ब्राउज़र इंजन हो या ध्यान से मिलाई गई लाइब्रेरी — दोनों लेयर्स को एक साथ संबोधित करता है, बजाय एक को खुला छोड़ने के।

प्रॉक्सी नेटवर्क लेयर को संबोधित करते हैं, TLS फिंगरप्रिंट को नहीं, और कोई भी प्रोवाइडर जो ऐसा कहता है वह IP बदलने की क्षमता से ज़्यादा बिक्री करने की कोशिश कर रहा है। जिन टीमों को दोनों लेयर्स हल चाहिए, वे आमतौर पर गुणवत्तापूर्ण प्रॉक्सी इंफ्रास्ट्रक्चर, जैसे Insocks residential और ISP प्रॉक्सी, को ब्राउज़र-आधारित या ठीक से मिलाए क्लाइंट के साथ जोड़ती हैं।

🔗 किसी प्लान पर प्रतिबद्ध होने से पहले प्रॉक्सी पूल्स की तुलना करने के लिए पूर्ण एक्सेस के लिए रजिस्टर करें।

मुख्य बातें

• tls हैंडशेक किसी भी HTTP हेडर से पहले पढ़ा जाता है, और यही इस डिटेक्शन मेथड की पूरी बुनियाद है।
• JA3 का उत्तराधिकारी हैश एक्सटेंशन क्रम रैंडमाइज़ होने के बाद भी स्थिर रहता है, अपने पूर्ववर्ती के विपरीत।
• JA3 क्या है की समझ यह स्पष्ट करती है कि ब्राउज़र-जैसे क्लाइंट स्क्रिप्टेड क्लाइंट से ज़्यादा लगातार जाँचें पास क्यों करते हैं।
• प्रॉक्सी IP की समस्याएँ हल करते हैं; वे अपने आप कभी tls हैंडशेक को रीराइट नहीं करते।
• पूर्ण ब्राउज़र ऑटोमेशन एक स्थिर, ब्राउज़र-जैसे JA3 फिंगरप्रिंट का सबसे भरोसेमंद रास्ता बना हुआ है।

डिस्क्लोज़र और डेटा स्रोत

इस लेख का सारा डेटा, जिसमें कीमतें, टैरिफ़ टियर्स, लिमिट्स और प्रोडक्ट उपलब्धता शामिल हैं, इस पेज पर दिखाई गई प्रकाशन तारीख़ तक सटीक है। वेंडर शर्तें बार-बार और बिना सूचना के बदलती हैं, एंट्री टियर्स वॉल्यूम के साथ बदलते हैं, और प्रमोशनल कीमतें आपके पढ़ने के दिन लागू हो सकती हैं। यहाँ कुछ भी कोई ऑफ़र नहीं है, वर्तमान शर्तों की गारंटी नहीं, और न ही खरीदने की सिफ़ारिश है।

यह लेख Insocks द्वारा प्रकाशित है। हम प्रॉक्सी बेचते हैं और ऊपर अंतिम सेक्शन में अपनी व्यावसायिक रुचि का खुलासा करते हैं। प्रॉक्सी JA3 फिंगरप्रिंट या किसी अन्य TLS सिग्नल को नहीं बदलते, और हम इसे सीधे कहते हैं बजाय इसका उल्टा संकेत देने के। यहाँ उल्लिखित टेस्टिंग टूल्स और लाइब्रेरीज़, जिनमें Scrapfly का चेकर, curl-impersonate और ब्राउज़र ऑटोमेशन फ़्रेमवर्क शामिल हैं, अपने-अपने स्वामियों की हैं और केवल पहचान के लिए दिखाई दी हैं। इस लेख में विवरण अगस्त, 2026 को जाँचे गए, और क्लाइंट व्यवहार लाइब्रेरी या ब्राउज़र संस्करणों के बीच बदल सकता है।

अक्सर पूछे जाने वाले सवाल

नीचे दिए सवाल उन मूल बातों को कवर करते हैं जो लोग आमतौर पर इस विषय के बारे में पहली बार पढ़ने के बाद पूछते हैं। जवाब छोटे और तथ्यात्मक रहते हैं, वही मेल खाते हुए जो एक ब्राउज़र टैब या कमांड लाइन टूल वास्तव में दिखाएगा। इसका कोई हिस्सा बायपास गाइड नहीं है, क्योंकि यहाँ लक्ष्य समझना है, चकमा देना नहीं।

TLS फिंगरप्रिंट क्या है?

हैंडशेक डेटा से बना एक छोटा सिग्नेचर जो पहचानता है कि कनेक्शन किस सॉफ़्टवेयर ने बनाया।

JA3 हैश की गणना कैसे होती है?

हैंडशेक के पाँच फ़ील्ड्स को जोड़कर एक 32-कैरेक्टर स्ट्रिंग में हैश किया जाता है।

JA3 और JA4 में क्या अंतर है?

नई मेथड एक्सटेंशन को सॉर्ट करती है और मज़बूत हैश उपयोग करती है, ब्राउज़रों द्वारा क्रम रैंडमाइज़ करने के बाद भी स्थिर रहती है।

क्या कोई residential प्रॉक्सी मेरा TLS फिंगरप्रिंट छिपा सकता है?

नहीं, प्रॉक्सी केवल IP पता बदलता है; हैंडशेक बिना बदले उससे होकर गुज़रता है।

मेरा स्क्रेपर सही हेडर के साथ भी ब्लॉक क्यों हो जाता है?

हेडर हैंडशेक के बाद लोड होते हैं, इसलिए बेमेल क्लाइंट प्रोफ़ाइल पहले पकड़ा जाता है।

मैं अपना TLS फिंगरप्रिंट कैसे जाँचूँ?

एक सार्वजनिक जाँच टूल को अनुरोध भेजें और उसे असली ब्राउज़र के परिणाम से तुलना करें।