Accept-Language، العملة وملف تعريف الارتباط الجغرافي: نقوم بإصلاح المحلل

يتم تشغيل المحلل، الكود لا يتعطل، البيانات تصل - لكن الأسعار بالدولار بدلاً من الروبل، والنص باللغة الإنجليزية، والمنتجات تختلف عن تلك التي يراها المستخدم الحقيقي من روسيا. هذه واحدة من أكثر المشاكل شيوعًا وإحباطًا في التحليل: من الناحية الفنية، كل شيء يعمل، لكن المحتوى "ليس صحيحًا". نحلل سبب حدوث ذلك وكيفية جمع الطلب الذي يحصل على النسخة الصحيحة من الصفحة التي تحتاجها.

الأعراض: كيف نفهم أن المحلل يرى نسخة غير صحيحة

قبل إصلاح المشكلة، من المهم تشخيصها بشكل صحيح. هناك ثلاثة سيناريوهات نموذجية تؤدي إلى حصول المحلل على بيانات تختلف عن تلك التي يراها المستخدم العادي في المتصفح:

لغة المحتوى لا تتطابق - تتوقع نصًا باللغة الروسية، لكنك تتلقى النسخة الإنجليزية أو الأوكرانية من الصفحة.
العملة والأسعار تختلف - يعرض الموقع السعر بالدولار الأمريكي أو اليورو، بينما في المتصفح من روسيا ترى الروبل، أو الأرقام ببساطة مختلفة (تسعير إقليمي).
فهرس المنتجات/المحتوى مختلف - توفر المنتجات، العروض، واجهة العرض بالكامل تعتمد على المنطقة التي "رآها" الموقع لديك.

السبب غالبًا ما يكون واحدًا من الثلاثة (أو مزيج منها): رأس 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، لكن IP من المنطقة B" ويقوم بإعادة تعيين الجلسة. لمهام مراقبة الأسعار، من الأفضل تثبيت IP واحد على مدار جلسة التحليل في منطقة معينة، بدلاً من تدويره أثناء جمع البيانات.

أي نوع من البروكسي يجب اختياره للمهمة

يؤثر اختيار نوع البروكسي بشكل مباشر على مدى دقة الموقع في تحديد منطقتك وعدم الاشتباه في الأتمتة. إليك مقارنة للمهام النموذجية لتحليل النسخ الإقليمية من المواقع:

نوع البروكسي	دقة الجغرافيا	متى تستخدم
بروكسي مراكز البيانات	متوسط، الدولة صحيحة، لكن IP قد يتم وضع علامة عليه كـ "غير سكني"	تحليل المواقع بدون حماية صارمة ضد الروبوتات، سرعة عالية وحجم طلبات كبير
بروكسي سكنية	عالية، تصل إلى المدينة	مراقبة الأسعار على الأسواق، محتوى إقليمي، تجاوز فحوصات GeoIP
بروكسي محمولة	عالية، بالإضافة إلى علامة مزود الخدمة المحمولة	مواقع وتطبيقات تعمل بشكل مختلف مع حركة المرور المحمولة من دولة معينة

إذا كانت المهمة هي مراقبة الفهرس والأسعار على الأسواق من مدن مختلفة، فإن البروكسي السكنية عادةً ما تعطي نتائج أكثر توقعًا: ترى قواعد GeoIP عنوان سكني حقيقي، وليس نطاق مركز بيانات، الذي تعالجه بعض المواقع منطقياً بشكل منفصل.

الخاتمة

مشكلة "المحلل يرى نسخة غير صحيحة من الصفحة" تتكون تقريبًا دائمًا من ثلاثة عوامل: رأس Accept-Language، الذي يحدد اللغة المفضلة للاستجابة؛ الكوكيز، التي تتذكر المنطقة والعملات المختارة سابقًا؛ وجغرافيا عنوان IP، التي يحددها الخادم لتحديد الدولة عند الزيارة الأولى. للحصول على النسخة الصحيحة من الموقع التي يراها المستخدم الحقيقي، يجب مزامنة جميع هذه المعلمات في وقت واحد، بدلاً من إصلاحها بشكل منفصل.

إذا كنت تقوم بتحليل النسخ الإقليمية من المواقع بانتظام، أو مراقبة أسعار المنافسين على الأسواق أو جمع البيانات من دول مختلفة، من الأفضل أن تبدأ باختيار IP المناسب - يتم بناء الإعدادات الأخرى (الرؤوس، الكوكيز، المنطقة الزمنية) حوله. للحصول على دقة في الوصول إلى المنطقة المطلوبة، نوصي بتجربة البروكسي السكنية, التي توفر جغرافيا متوقعة وتقلل من خطر الحصول على النسخة الدولية الافتراضية من الموقع بدلاً من النسخة المحلية.