2026 में साइट्स हेडलेस ब्राउज़रों का पता कैसे लगाती हैं: CDP लीक, सुसंगति जांच और क्या मदद करता है

आप रॉ HTTP से एक असली ब्राउज़र पर चले गए। TLS फिंगरप्रिंट: सचमुच Chrome का। IP: रेज़िडेंशियल। और फिर भी साइट जानती है। 2026 में, हेडलेस ब्राउज़र डिटेक्शन navigator.webdriver से बहुत आगे निकल चुका है — चेक्स की वर्तमान पीढ़ी ऑटोमेशन प्रोटोकॉल को ही पहचानती है, और अधिकांश "स्टेल्थ" प्लगइन्स कल के सिग्नल्स को पैच करते हैं जबकि आज के सिग्नल्स को ज़ोर-शोर से प्रदर्शित करते हैं।

यह लेख यह मैप करता है कि साइट्स अब वास्तव में क्या चेक करती हैं, लगभग उसी क्रम में जिस क्रम में वे चेक करती हैं, और हर परत पर सचमुच क्या मदद करता है। यह डिटेक्शन त्रयी को JA3/JA4 TLS फिंगरप्रिंटिंग (नेटवर्क परत) और IP रेप्युटेशन और ASN (एड्रेस परत) के साथ पूरा करता है — यह ब्राउज़र परत है।

टियर 1: क्लासिक्स (हल हो चुके, लेकिन अब भी चेक किए जाते हैं)

• navigator.webdriver — स्पेसिफिकेशन के अनुसार ऑटोमेशन के तहत true होना ज़रूरी है। Playwright/Puppeteer स्टेल्थ सेटअप इसे छिपा देते हैं; Chrome का --disable-blink-features=AutomationControlled इसे नेटिव रूप से संभालता है। साइट्स अब भी इसे चेक करती हैं क्योंकि यह मुफ़्त है और नौसिखिए बॉट्स को पकड़ता है।
• हेडलेस UA स्ट्रिंग्स — User-Agent में HeadlessChrome/। नए हेडलेस मोड (headless=new) द्वारा ठीक किया गया, जो असली Chrome बाइनरी पाथ का उपयोग करता है।
• गायब ब्राउज़र फर्निचर — शून्य navigator.plugins, कोई chrome.runtime नहीं, 0×0 outerWidth। पुराना हेडलेस मोड इन सभी में विफल रहता था; नया हेडलेस ज़्यादातर पास हो जाता है।

यदि कोई टारगेट केवल टियर 1 चेक करता है, तो headless=new के साथ आधुनिक Playwright आसानी से पार हो जाता है। गंभीर टारगेट्स वर्षों पहले आगे बढ़ चुके हैं।

टियर 2: CDP डिटेक्शन — 2026 का वर्कहॉर्स

Playwright और Puppeteer Chrome को Chrome DevTools Protocol के माध्यम से चलाते हैं, और CDP ऐसे रनटाइम साइड इफेक्ट्स छोड़ता है जिन्हें पेज JavaScript देख सकता है:

// The classic CDP leak: serialization callbacks
const err = new Error();
Object.defineProperty(err, "stack", {
  get() {
    // This getter fires DURING console serialization -
    // which only happens when DevTools/CDP is attached
    window.__cdp_detected = true;
  },
});
console.debug(err);

इसके वेरिएंट्स — console सीरियलाइज़ेशन के दौरान getter साइड इफेक्ट्स, Runtime.evaluate में टाइमिंग की विसंगतियाँ, पैच किए गए नेटिव फंक्शन्स पर toString() का व्यवहार — हर कमर्शियल एंटी-बॉट बंडल में हैं। महत्वपूर्ण बात: यह प्रोटोकॉल को पहचानता है, हेडलेस मोड को नहीं। एक हेडेड, स्टेल्थ-पैच्ड, बिल्कुल इंसान जैसा दिखने वाला Chrome भी विफल हो जाता है यदि उसे CDP के माध्यम से चलाया जा रहा हो।

क्या मदद करता है:

• पैच किए गए रनटाइम — पुनर्निर्मित ड्राइवर (उदा. patchright, rebrowser-patches) जो CDP साइड इफेक्ट्स को पेज-ऑब्ज़र्वेबल स्पेस से बाहर ले जाते हैं। वे अपस्ट्रीम रिलीज़ से पीछे रहते हैं; वर्शन पिन करें और हर बम्प के बाद फिर से टेस्ट करें।
• नॉन-CDP ऑटोमेशन — ऐसे टूल जो ब्राउज़र को OS-स्तरीय इनपुट या एक्सेसिबिलिटी APIs के माध्यम से चलाते हैं, पेज में कोई प्रोटोकॉल आर्टिफैक्ट नहीं छोड़ते, गति और APIs की कीमत पर।
• उद्देश्य-निर्मित स्टेल्थ ब्राउज़र — Camoufox (हार्डन्ड Firefox) जैसे इंजन Chromium-CDP चेक्स को पूरी तरह से दरकिनार कर देते हैं; Firefox का ऑटोमेशन सरफेस अलग है और कम-टार्गेटेड है।

टियर 3: एनवायरनमेंट सुसंगति

आर्टिफैक्ट्स से परे, आधुनिक सिस्टम यह चेक करते हैं कि आपके ब्राउज़र की कहानी आंतरिक रूप से सुसंगत है या नहीं:

चेक	बॉट का संकेत
Canvas / WebGL रेंडर हैश	SwiftShader/llvmpipe सॉफ़्टवेयर रेंडरिंग = सर्वर GPU; या 10,000 "अलग-अलग यूज़र्स" द्वारा साझा एक हैश
फॉन्ट्स और कोडेक्स	Windows User-Agent के तहत Linux सर्वर फॉन्ट सेट
टाइमज़ोन × लोकेल × IP जियो	Intl कहता है UTC, IP कहता है Texas, Accept-Language कहता है de-DE
स्क्रीन मेट्रिक्स	1920×1080 शून्य टास्कबार के साथ, devicePixelRatio बिल्कुल 1, विंडो कभी रीसाइज़ नहीं हुई
हार्डवेयर कन्करेंसी / मेमोरी	एक फोन होने का दावा करने वाले पेज को 96 कोर रिपोर्ट किए गए
बिहेवियरल माइक्रो-सिग्नल्स	कोई माउस एन्ट्रॉपी नहीं, तुरंत फॉर्म भरना, समान 100px स्टेप्स में स्क्रॉल

यहीं DIY स्टेल्थ मर जाता है: आप जो भी पैच लगाते हैं, वह हर दूसरे सिग्नल से सहमत होना चाहिए। एक Linux कंटेनर पर एक स्पूफ किया गया Windows UA फॉन्ट्स, GPU स्ट्रिंग्स, और TCP फिंगरप्रिंट्स का एक साथ खंडन करता है। सुसंगति पूर्णता को हरा देती है — एक ईमानदार हेडेड Linux Chrome एक खराब-स्पूफ किए गए "Windows" वाले से बेहतर स्कोर करता है।

और नीचे की परत अब भी लागू होती है

यदि एड्रेस परत जल चुकी है तो इनमें से कुछ भी मायने नहीं रखता: एक डेटासेंटर ASN पर एक निर्दोष ब्राउज़र अब भी "एक डेटासेंटर में एक निर्दोष ब्राउज़र" ही है — और हेडलेस डिटेक्शन थ्रेशोल्ड IP रेप्युटेशन के अनुकूल होते हैं। एक फ्लैग किए गए IP से वही ब्राउज़र अधिक JavaScript चैलेंज पाता है। रेज़िडेंशियल एग्ज़िट्स प्रभावी रूप से उस जांच को कम कर देते हैं जिसे ब्राउज़र परत को झेलना पड़ता है:

browser = p.chromium.launch(
    headless=False,                      # headed survives more checks
    args=["--disable-blink-features=AutomationControlled"],
    proxy={
        "server": "us.jibaoproxy.com:913",
        "username": "USERNAME", "password": "PASSWORD",
    },
)

व्यावहारिक चेकलिस्ट

1. नया हेडलेस या हेडेड मोड का उपयोग करें; कभी भी लीगेसी हेडलेस का नहीं।
2. किसी भी गंभीर टारगेट पर CDP डिटेक्शन मान लें — पैच किया गया रनटाइम, नॉन-CDP ड्राइवर, या एक हार्डन्ड नॉन-Chromium इंजन।
3. स्टेल्थ प्लगइन्स को आँख मूंदकर ढेर न करें; हर अनपैच्ड toString() अपने आप में एक सिग्नल है। कम, सुसंगत पैच जीतते हैं।
4. पूरी कहानी का मिलान करें: टाइमज़ोन = IP जियो = लोकेल; दावा किए गए OS के लिए GPU प्रशंसनीय हो।
5. इनपुट एन्ट्रॉपी जोड़ें — घुमावदार माउस पाथ, परिवर्तनशील विलंब, कभी-कभी स्क्रॉल-बैक।
6. असली टारगेट से पहले एक तटस्थ ऑब्ज़र्वर के विरुद्ध टेस्ट करें।

सारांश

• टियर 1 (webdriver फ्लैग, हेडलेस UA) न्यूनतम आवश्यकता है — नया हेडलेस मोड इसे पास कर लेता है।
• टियर 2 वह है जहाँ 2026 डिटेक्शन रहता है: CDP प्रोटोकॉल आर्टिफैक्ट्स हेडेड, स्टेल्थ-पैच्ड Chrome को भी पकड़ लेते हैं; पैच किए गए रनटाइम या नॉन-CDP ड्राइवर का उपयोग करें।
• टियर 3 सुसंगति है: हर स्पूफ किया गया मान OS, GPU, फॉन्ट्स, टाइमज़ोन, और IP जियो से सहमत होना चाहिए।
• डिटेक्शन थ्रेशोल्ड IP रेप्युटेशन के अनुकूल होते हैं — साफ रेज़िडेंशियल एग्ज़िट्स आपके ब्राउज़र को कुछ छूट दिलाते हैं।
• हर डिपेंडेंसी अपडेट के बाद अनुभवजन्य रूप से सत्यापित करें; स्टेल्थ तेज़ी से सड़ती है।