स्वीकृत-भाषा, मुद्रा और भू-कोकी: पार्सर को ठीक कर रहे हैं

पार्सर शुरू होता है, कोड क्रैश नहीं होता, डेटा आता है — लेकिन कीमतें डॉलर में हैं, जबकि रुपये में नहीं, टेक्स्ट अंग्रेजी में है, और उत्पाद वे हैं जो एक जीवित उपयोगकर्ता रूस से देखता है। यह पार्सिंग की सबसे सामान्य और निराशाजनक समस्याओं में से एक है: तकनीकी रूप से सब कुछ काम कर रहा है, लेकिन सामग्री "वह नहीं है"। हम समझते हैं कि यह क्यों होता है और कैसे एक अनुरोध तैयार करें, जो वास्तव में उस पृष्ठ के संस्करण को प्राप्त करता है, जिसकी आपको आवश्यकता है।

लक्षण: कैसे समझें कि पार्सर गलत संस्करण देख रहा है

समस्या को ठीक करने से पहले, इसे सही तरीके से निदान करना महत्वपूर्ण है। तीन सामान्य परिदृश्य हैं, जिनके कारण पार्सर को डेटा मिलता है, जो सामान्य ब्राउज़र उपयोगकर्ता द्वारा देखे जाने वाले डेटा से भिन्न होता है:

सामग्री की भाषा मेल नहीं खाती — आप रूसी टेक्स्ट की उम्मीद करते हैं, लेकिन अंग्रेजी या यूक्रेनी संस्करण आता है।
मुद्रा और कीमतें भिन्न हैं — वेबसाइट USD या EUR में कीमत दिखाती है, जबकि रूस से ब्राउज़र में आप रुपये देखते हैं, या संख्याएँ बस अलग हैं (क्षेत्रीय मूल्य निर्धारण)।
उत्पाद/सामग्री की सूची अलग है — उत्पादों की उपलब्धता, प्रचार, पूरी विंडो उस क्षेत्र पर निर्भर करती है, जिसे वेबसाइट ने आपके पास "देखा"।

कारण लगभग हमेशा तीन में से एक (या उनका संयोजन) होता है: Accept-Language हेडर, अनुपस्थित या गलत कुकी, या IP पते की भू-स्थानिकता, जिससे अनुरोध किया जा रहा है। हम प्रत्येक को क्रम से समझते हैं।

Accept-Language: सर्वर प्रतिक्रिया की भाषा कैसे चुनता है

ब्राउज़र प्रत्येक अनुरोध पर Accept-Language हेडर भेजता है, जिसमें उपयोगकर्ता की पसंदीदा भाषाएँ और उनके वजन (q-मान) सूचीबद्ध होते हैं। उदाहरण के लिए, जो वास्तव में Chrome रूसी स्थानीयकरण के साथ भेजता है:

Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7

पार्सिंग के लिए पुस्तकालय (requests, httpx, scrapy) डिफ़ॉल्ट रूप से या तो इस हेडर को भेजते नहीं हैं, या कुछ ऐसा भेजते हैं जैसे */*. इस मामले में, सर्वर या तो डिफ़ॉल्ट भाषा (अधिकतर अंग्रेजी) देता है, या IP के आधार पर भाषा निर्धारित करता है — और यहीं भू-भाग का हिस्सा खेल में आता है, जिसके बारे में नीचे बताया गया है।

एक महत्वपूर्ण बिंदु: कई वेबसाइटें "Accept-Language + IP भू-स्थान" के संयोजन का उपयोग करती हैं, न कि केवल एक। इसका मतलब है कि भले ही आप सही भाषा हेडर भेजें, लेकिन अनुरोध किसी अन्य देश के IP से आ रहा है, वेबसाइट फिर भी आपको उस क्षेत्र के लिए अंग्रेजी या स्थानीय संस्करण पर स्विच कर सकती है, जहां से वास्तव में अनुरोध आया है।

मुद्रा और स्थानीयकरण: वेबसाइट कीमतें कहाँ से लेती है

मुद्रा लगभग कभी भी सीधे Accept-Language हेडर द्वारा निर्धारित नहीं होती है। अक्सर तीन में से एक तंत्र (या उनका संयोजन) का उपयोग किया जाता है:

GeoIP-आधार — सर्वर देखता है कि IP किस देश से आया है, और पहले दौरे पर स्वचालित रूप से संबंधित मुद्रा और स्थानीयकरण डालता है।
पहले से चुने गए क्षेत्र की कुकी — यदि उपयोगकर्ता ने कभी मैन्युअल रूप से देश और मुद्रा चुनी है, तो वेबसाइट इसे कुकी में सहेजती है और IP की फिर से जांच नहीं करती।
URL में पैरामीटर या उपडोमेन — कुछ प्लेटफ़ॉर्म स्पष्ट मार्कर का उपयोग करते हैं जैसे ?country=ru या ru.example.com.

व्यावहारिक रूप से, यदि आप एक ऑनलाइन स्टोर को पार्स कर रहे हैं और डॉलर में कीमतें देख रहे हैं बजाय रुपये के, 80% मामलों में समस्या हेडर में नहीं है, बल्कि अनुरोध के IP पते में है। वेबसाइट ने बस "देखा" कि IP रूसी नहीं है और डिफ़ॉल्ट अंतरराष्ट्रीय विंडो डाल दी।

एक बार जब वेबसाइट ने आपके क्षेत्र का निर्धारण कर लिया (IP द्वारा या "अपने शहर का चयन करें" बैनर पर मैन्युअल चयन द्वारा), तो यह इस निर्णय को कुकी में सहेजती है — आमतौर पर नामों के साथ जैसे region, geo_city, currency या locale. इसके बाद सभी अनुरोध इस कुकी के साथ सहेजे गए क्षेत्र के अनुसार संसाधित होते हैं — भले ही IP अचानक बदल जाए।

यह पार्सर के लिए एक जाल बनाता है: यदि आपने एक बार "गलत" संस्करण प्राप्त किया और सत्र की कुकी सहेज ली, तो सभी बाद के अनुरोध उसी त्रुटि को दोहराएंगे, भले ही आप हेडर या प्रॉक्सी को ठीक करें। इसलिए निदान करते समय हमेशा एक साफ सत्र के साथ पार्सिंग की जांच करें — पिछले लॉन्च से सहेजी गई कुकी के बिना।

इसी तंत्र का विपरीत पक्ष उपयोगी है: यदि आप आवश्यक कुकी का नाम और उसके सही मान को लक्षित क्षेत्र के लिए जानते हैं (उदाहरण के लिए, इसे आवश्यक स्थान पर ब्राउज़र के DevTools में देखा), तो आप IP को बदले बिना इस मान को अनुरोध में मजबूर कर सकते हैं। यह उन साइटों के लिए काम करता है, जहां क्षेत्र केवल कुकी-फ्लैग के माध्यम से निर्धारित होता है, लेकिन यह तब काम नहीं करता जब सर्वर हर अनुरोध पर IP को GeoIP-आधार के साथ फिर से जांचता है।

क्षेत्र का निर्धारण करने में IP पते और प्रॉक्सी की भूमिका

GeoIP-निर्धारण — वेबसाइट के लिए यह समझने का सबसे विश्वसनीय तरीका है कि अनुरोध वास्तव में कहाँ से आया है, क्योंकि हेडर और कुकी को धोखा दिया जा सकता है, लेकिन IP पते को धोखा नहीं दिया जा सकता (केवल इसे किसी अन्य वास्तविक में बदलना संभव है)। इसलिए, "सही" क्षेत्रीय संस्करण के पृष्ठ को स्थिरता से प्राप्त करने के लिए केवल HTTP हेडर पर्याप्त नहीं हैं — एक IP की आवश्यकता है, जो वास्तव में आवश्यक देश का है।

यहाँ IP पते के प्रकारों के बीच एक महत्वपूर्ण अंतर है:

डेटा सेंटर IP — GeoIP-आधार अक्सर उन्हें देश के अनुसार सही तरीके से पहचानते हैं, लेकिन कई बड़े वेबसाइटें (विशेष रूप से मार्केटप्लेस और बॉट सुरक्षा सेवाएँ) डेटा सेंटर की रेंज को संदिग्ध के रूप में चिह्नित करती हैं और भू-स्थान के बावजूद सामग्री के संकुचित या डिफ़ॉल्ट संस्करण को दिखा सकती हैं।
रिहायशी IP — वास्तविक प्रदाताओं और भौतिक पते से संबंधित होते हैं, इसलिए GeoIP क्षेत्र को अधिक सटीक रूप से निर्धारित करता है, और वेबसाइट अनुरोध को उस देश/शहर के सामान्य उपयोगकर्ता के रूप में मानती है।
मोबाइल IP — विशेष देश के मोबाइल ऑपरेटरों से जुड़े होते हैं, जो विशेष रूप से महत्वपूर्ण है उन साइटों और अनुप्रयोगों के लिए, जो मोबाइल और डेस्कटॉप ट्रैफ़िक के साथ अलग-अलग काम करते हैं।

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

व्यवहार: Python पर सही अनुरोध तैयार करना

हम एक ऐसा अनुरोध तैयार करेंगे, जो तीनों समस्याओं को एक साथ हल करता है: सही Accept-Language भेजता है, आवश्यक कुकी के साथ एक साफ सत्र का उपयोग करता है और आवश्यक क्षेत्र के IP के माध्यम से जाता है।

import requests

proxies = {
    "http": "http://user:[email protected]:8080",
    "https": "http://user:[email protected]:8080",
}

headers = {
    "Accept-Language": "ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7",
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) "
                  "Chrome/124.0.0.0 Safari/537.36",
}

cookies = {
    "region": "ru",
    "currency": "RUB",
}

session = requests.Session()
response = session.get(
    "https://example.com/catalog",
    headers=headers,
    cookies=cookies,
    proxies=proxies,
    timeout=15,
)

print(response.status_code)
print(response.text[:500])

इस कोड में कुछ महत्वपूर्ण बिंदु हैं:

यह requests.Session() का उपयोग करता है, न कि एकल requests.get(), ताकि यदि आवश्यक हो, तो सर्वर अतिरिक्त कुकी स्थापित कर सके, और वे एक ही पार्सिंग सत्र के अनुरोधों के बीच सहेजे जा सकें।
कुकी के मान region और currency — सशर्त हैं, उनके वास्तविक नाम और मान को लक्षित साइट पर आवश्यक स्थान पर ब्राउज़र के DevTools में देखना होगा (Application → Cookies टैब)।
प्रॉक्सी वास्तव में आवश्यक देश में होना चाहिए — अन्यथा सही हेडर और कुकी भी सर्वर द्वारा भू-स्थान की फिर से पहचान के दौरान ओवरराइट किए जा सकते हैं।

JS-साइटें: Playwright और हेडर/कुकी प्रबंधन

यदि वेबसाइट सामग्री को JavaScript के माध्यम से रेंडर करती है (कीमतें पृष्ठ लोड होने के बाद एक अलग अनुरोध के माध्यम से लोड होती हैं), तो साधारण requests अनुरोध पर्याप्त नहीं है — एक हेडलेस ब्राउज़र की आवश्यकता होती है। Playwright में, स्थानीयकरण, भाषा और प्रॉक्सी ब्राउज़र के संदर्भ स्तर पर सेट किए जाते हैं:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    context = browser.new_context(
        locale="ru-RU",
        timezone_id="Europe/Moscow",
        proxy={
            "server": "http://gate.proxycove.com:8080",
            "username": "user",
            "password": "pass",
        },
    )
    context.add_cookies([
        {"name": "region", "value": "ru", "domain": "example.com", "path": "/"},
        {"name": "currency", "value": "RUB", "domain": "example.com", "path": "/"},
    ])

    page = context.new_page()
    page.goto("https://example.com/catalog")
    page.wait_for_selector(".price")
    print(page.content()[:500])

    browser.close()

timezone_id पैरामीटर पर ध्यान दें — कई वेबसाइटें अतिरिक्त रूप से ब्राउज़र के समय क्षेत्र की अपेक्षित क्षेत्र के साथ तुलना करती हैं, और विसंगति (उदाहरण के लिए, IP रूस से है, लेकिन ब्राउज़र का समय क्षेत्र अमेरिकी है) अपने आप में एंटी-बॉट सिस्टम के लिए एक संकेत हो सकता है कि अनुरोध संदिग्ध है, भले ही भाषा और मुद्रा औपचारिक रूप से सही हों।

सामान्य गलतियाँ और लॉन्च से पहले चेकलिस्ट

पार्सर को प्रोडक्शन में लॉन्च करने से पहले, एक संक्षिप्त चेकलिस्ट पर जाएँ — यह डिबगिंग के घंटों को बचाता है:

✅ Accept-Language हेडर सेट किया गया है और अपेक्षित क्षेत्र से मेल खाता है।
✅ सत्र साफ है — कुकी पिछले असफल अनुरोध से विरासत में नहीं मिली है।
✅ प्रॉक्सी का IP भौतिक रूप से आवश्यक देश में है (पार्सिंग से पहले किसी भी geo-IP चेकर्स के माध्यम से जांचें)।
✅ User-Agent वास्तविक ब्राउज़र के अनुरूप है और हेडलेस मोड के संकेत नहीं देता।
✅ ब्राउज़र का समय क्षेत्र और स्थानीयकरण (Playwright/Selenium के लिए) IP के देश के साथ मेल खाते हैं।
✅ यदि वेबसाइट बैनर पर क्षेत्र का मैन्युअल चयन करती है — तो इस चयन की कुकी मैन्युअल रूप से भेजी जाती है।

प्रॉक्सी के रोटेशन के बारे में अलग से कहना चाहिए: यदि आप प्रत्येक अनुरोध पर IP बदलते हैं, जबकि सत्र की कुकी वही रहती है, तो वेबसाइट "क्षेत्र A की कुकी, लेकिन क्षेत्र B का IP" असंगति देख सकती है और सत्र को रीसेट कर सकती है। कीमतों की निगरानी जैसी कार्यों के लिए, बेहतर है कि एक IP को विशेष क्षेत्र के पार्सिंग सत्र के लिए संलग्न करें, न कि डेटा संग्रह के बीच में इसे रोटेट करें।

कार्य के लिए किस प्रकार की प्रॉक्सी चुनें

प्रॉक्सी के प्रकार का चयन सीधे इस पर प्रभाव डालता है कि वेबसाइट आपके क्षेत्र को कितनी सटीकता से निर्धारित करेगी और स्वचालन के लिए संदेह नहीं करेगी। यहाँ क्षेत्रीय संस्करणों की वेबसाइटों के लिए सामान्य पार्सिंग कार्यों के लिए तुलना है:

प्रॉक्सी का प्रकार	भू-स्थान की सटीकता	कब उपयोग करें
डेटा सेंटर प्रॉक्सी	औसत, देश सही है, लेकिन IP "अविभाज्य" के रूप में चिह्नित किया जा सकता है	कड़ी एंटी-बॉट सुरक्षा के बिना वेबसाइटों की पार्सिंग, उच्च गति और अनुरोधों की मात्रा
रिहायशी प्रॉक्सी	उच्च, शहर तक	मार्केटप्लेस पर कीमतों की निगरानी, क्षेत्रीय सामग्री, GeoIP-चेक को बायपास करना
मोबाइल प्रॉक्सी	उच्च, साथ में मोबाइल ऑपरेटर का टैग	विशिष्ट देश के मोबाइल ट्रैफिक के साथ अलग-अलग काम करने वाली वेबसाइटें और अनुप्रयोग

यदि कार्य विशेष रूप से विभिन्न शहरों से मार्केटप्लेस पर कैटलॉग और कीमतों की निगरानी करना है, तो रिहायशी प्रॉक्सी आमतौर पर सबसे पूर्वानुमानित परिणाम देती हैं: GeoIP-आधार वास्तविक आवासीय पते को देखता है, न कि डेटा सेंटर की रेंज, जिसे कुछ वेबसाइटें अलग लॉजिक के साथ संसाधित करती हैं।

निष्कर्ष

"पार्सर गलत पृष्ठ संस्करण देखता है" की समस्या लगभग हमेशा तीन कारकों से बनती है: Accept-Language हेडर, जो प्रतिक्रिया की पसंदीदा भाषा निर्धारित करता है; कुकी, जो पहले चुने गए क्षेत्र और मुद्रा को याद रखती है; और IP पते की भू-स्थानिकता, जिसके आधार पर सर्वर पहले दौरे पर अनुरोध के देश का निर्धारण करता है। वेबसाइट का वह संस्करण प्राप्त करने के लिए, जिसे एक जीवित उपयोगकर्ता देखता है, सभी तीन पैरामीटर को एक साथ समन्वयित करना आवश्यक है, न कि उन्हें अलग-अलग ठीक करना।

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