يعمل البارسر محليًا، لكنه يتعرض للحظر على الخادم: 7 أسباب وكيفية إصلاح ذلك

حالة كلاسيكية: سكربت لمراقبة الأسعار على Wildberries أو Ozon يعمل بشكل ممتاز على الكمبيوتر المحمول المنزلي، ولكن بعد نقله إلى VPS يبدأ في تلقي 403، أو كابتشا، أو حظر فوري بناءً على IP. يقوم المطور بتغيير العناوين، ويضيف تأخيرات - لكن النتيجة لا تتغير. المشكلة غالبًا ليست في كود المحلل بحد ذاته، بل في البيئة التي يقوم منها بإجراء الطلبات. نحلل 7 أسباب محددة وماذا يجب تغييره لجعل المحلل يعمل بشكل مستقر على الخادم.

لماذا يعمل كل شيء محليًا، لكن على الخادم - حظر

عندما تقوم بتشغيل المحلل من جهاز الكمبيوتر المنزلي، يرى الموقع الطلب من عنوان IP سكني عادي لمزود الخدمة الخاص بك، من منطقة مألوفة، مع بيئة متصفح حقيقية، إذا كنت تستخدم Selenium أو Playwright مع ملف تعريف حقيقي. بمجرد أن ينتقل نفس السكربت إلى VPS في ألمانيا أو هولندا أو الولايات المتحدة، تتغير الصورة تمامًا: IP ينتمي إلى مركز بيانات، قد تختلف بصمة TLS بسبب إصدار مختلف من المكتبات، المنطقة الزمنية للخادم لا تتطابق مع الجغرافيا الخاصة بـ IP، وتزداد وتيرة الطلبات بشكل حاد، لأن الخادم يعمل 24/7 بدون توقف.

أنظمة مكافحة الروبوتات في Wildberries وOzon وAvito ومعظم الأسواق الكبرى لم تعد تنظر فقط إلى User-Agent. إنها تحلل مجموعة من عشرات الإشارات: نوع IP، سرعة وتكرار الطلبات، سلوك الصفحة، تطابق العناوين ومعلمات TLS، وجود ملفات تعريف الارتباط وتاريخ الجلسة. تمر الآلة المحلية بالتحقق عن طريق الصدفة في معظم النقاط، بينما يفشل الخادم تقريبًا في جميعها. أدناه - تحليل مفصل لكل سبب.

السبب 1: IP مركز البيانات بدلاً من IP السكني

هذا هو السبب رقم 1 في 80% من الحالات. عناوين IP الخاصة بـ VPS والخوادم السحابية (AWS وDigitalOcean وHetzner، واستضافات VDS العادية) موجودة في قواعد بيانات مراكز البيانات - ASN لهذه المزودين معروفة علنًا وتستخدمها أنظمة مكافحة الروبوتات لتصفية الحركة على الفور. تستخدم الأسواق مثل هذه القوائم في المقام الأول، لأن 95% من عمليات التحليل الآلي تأتي من عناوين IP الخوادم.

الحل هو استخدام IP لا تختلف بصريًا عن المستخدم العادي للإنترنت. لتحليل Wildberries وOzon وAvito، فإن أفضل الخيارات هي بروكسي سكنية: هذه هي عناوين IP حقيقية لمزودي الخدمة المنزلية، مُعطاة للمشتركين العاديين. ترى أنظمة مكافحة الروبوتات هذا الطلب كحركة من مستخدم حقيقي، وليس من خادم في مركز بيانات، مما يزيل جزءًا كبيرًا من الحظر على الفور.

السبب 2: عدم وجود تدوير IP وحدود لتكرار الطلبات

على الجهاز المحلي، تقوم بإجراء 20-50 طلبًا يدويًا أثناء الاختبارات، ولا يلاحظ الموقع ذلك. على الخادم، يتم تشغيل السكربت عبر cron كل 5 دقائق ويعالج آلاف بطاقات المنتجات بشكل متتابع من IP واحد. هذا النمط هو إشارة مباشرة لنظام مكافحة الروبوتات: لا يمكن لشخص حقيقي فتح 3000 صفحة من الكتالوج في ساعة واحدة دون أي توقف.

يجب إدخال تدوير IP على مجموعة البروكسي وتحديد عدد الطلبات إلى عنوان واحد في وحدة زمنية. القاعدة العملية: لا تزيد عن 30-60 طلبًا من IP واحد في الدقيقة لبطاقات المنتجات، مع تغيير تلقائي للعناوين بعد كل دفعة من الطلبات. مثال على إعداد التدوير في Python عبر مجموعة البروكسي:

import requests

proxies_pool = [
    "http://user:[email protected]:9000",
    "http://user:[email protected]:9001",
    "http://user:[email protected]:9002",
]

def get_page(url, session_id):
    proxy = proxies_pool[session_id % len(proxies_pool)]
    resp = requests.get(
        url,
        proxies={"http": proxy, "https": proxy},
        headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"},
        timeout=10
    )
    return resp.text

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

السبب 3: العناوين وUser-Agent لا تشبه المتصفح

العديد من المحللات على requests أو aiohttp ترسل طلبًا مع مجموعة محدودة من العناوين أو مع User-Agent القياسي للمكتبة، الذي يكشف السكربت على الفور (على سبيل المثال python-requests/2.31.0). على الجهاز المحلي عبر المتصفح، تكون مجموعة العناوين كاملة: Accept وAccept-Language وAccept-Encoding وSec-Ch-Ua وReferer وغيرها - مجموعتها تبدو طبيعية.

يجب نسخ مجموعة كاملة من العناوين من متصفح حقيقي، بما في ذلك ترتيب إرسالها - بعض أنظمة مكافحة الروبوتات تتحقق حتى من ذلك. بالإضافة إلى ذلك، من المهم تدوير User-Agent بالتزامن مع إصدار بصمة TLS (انظر النقطة التالية)، وإلا فإن عدم التطابق بين عنوان المتصفح وعميل TLS الحقيقي سيصبح إشارة جديدة للروبوت.

السبب 4: بصمة TLS/JA3 تكشف السكربت

هذه سبب أقل شهرة، لكنها شائعة جدًا للحظر على الخادم. تستخدم مكتبات requests وurllib وaiohttp تنفيذها الخاص من TLS handshake، الذي يختلف عن التنفيذ في Chrome أو Firefox. تحسب أنظمة مكافحة الروبوتات بصمة JA3/JA4 للاتصال TLS - وهي مختلفة تمامًا في السكربتات المكتوبة بلغة بايثون عن بصمة المتصفح الحقيقي، حتى لو كانت العناوين منسوخة بشكل مثالي.

الحل هو استخدام مكتبات تحاكي بصمة TLS للمتصفح (مثل curl_cffi وtls-client في بايثون، أو متصفح headless كامل قائم على Chromium عبر Playwright/Puppeteer). الخيار الثاني هو العمل ليس عبر عميل HTTP نقي، بل عبر محرك متصفح مُدار بالتعاون مع أداة مكافحة الكشف، حيث يتم تشكيل TLS والعناوين بواسطة نواة المتصفح الحقيقية، وليس بمحاكاة المكتبة.

السبب 5: المنطقة الزمنية، اللغة وخادم DNS

إذا كان السكربت يحاكي المتصفح عبر Selenium أو Playwright، يمكن لنظام مكافحة الروبوتات التحقق من المنطقة الزمنية للنظام، ولغة الواجهة، ومحلل DNS، وحتى تسرب WebRTC لعنوان IP الحقيقي للخادم. VPS في مركز بيانات فرانكفورت مع منطقة زمنية نظامية UTC ومزود DNS لمضيف، بينما يستخدم بروكسي مع IP من موسكو، يخلق عدم تطابق واضح في البيانات الجغرافية - هذه واحدة من أكثر الإشارات موثوقية للكشف.

يجب أن تتطابق جميع معلمات البيئة - المنطقة الزمنية، لغة المتصفح، DNS، الجغرافيا عبر WebRTC - مع منطقة عنوان IP المستخدم لإجراء الطلب. تم إنشاء متصفحات مكافحة الكشف لحل هذه المشكلة: تسمح أدوات مثل Dolphin Anty وAdsPower وMultilogin وOcto Browser وGoLogin بتكوين "ملف تعريف متصفح" منفصل لكل بروكسي، حيث يتم تلقائيًا ضبط المنطقة الزمنية واللغة ودقة الشاشة وWebRTC وفقًا للجغرافيا الخاصة بـ IP.

السبب 6: نمط الطلبات "آلي" للغاية

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

ماذا يجب تغييره: إضافة تأخيرات عشوائية (ليست ثانيتين ثابتتين، بل عشوائية من 1.5 إلى 6 ثوانٍ)، والدخول بشكل دوري إلى الصفحات الوسيطة (الفئة → البطاقة، وليس طلبًا مباشرًا إلى API)، ومحاكاة التمرير وحركات الفأرة عند العمل عبر متصفح headless. هذا يزيد من وقت جمع البيانات، لكنه يقلل بشكل حاد من عدد الحظر.

السبب 7: الجلسات وملفات تعريف الارتباط لا تُحفظ بين الطلبات

غالبًا ما يقوم المحلل على الخادم بإنشاء جلسة جديدة من requests لكل طلب - بدون ملفات تعريف الارتباط، بدون توكن تفويض محفوظ، بدون تاريخ الزيارات. تمنح الأسواق مثل Wildberries وOzon ملفات تعريف ارتباط مؤقتة وتوكنات عند الزيارة الأولى، وتبدو الطلبات اللاحقة بدونها مشبوهة، كما لو أن كل طلب يقوم به زائر مجهول جديد.

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

قائمة التحقق: ماذا يجب تغييره بالترتيب

إذا كان المحلل يتعرض للحظر بشكل مستمر على الخادم، لكنه يعمل محليًا، تحقق من التغييرات بهذا الترتيب - ستجد السبب بشكل أسرع:

الخطوة	ما يجب التحقق منه	ما يجب تغييره
1	نوع IP الخادم	الانتقال إلى بروكسي سكنية بدلاً من IP مباشر للاستضافة
2	تكرار الطلبات	إدخال تدوير IP وحدود للطلبات إلى العنوان
3	عناوين الطلب	نسخ مجموعة كاملة من العناوين من متصفح حقيقي
4	بصمة TLS	استخدام curl_cffi / متصفح headless بدلاً من requests النقي
5	المنطقة الزمنية واللغة	تكوين ملف تعريف في Dolphin Anty / AdsPower وفقًا لمنطقة IP
6	نمط السلوك	عشوائية التأخيرات، إضافة صفحات وسيطة
7	الجلسات وملفات تعريف الارتباط	ربط جلسة واحدة بـ IP واحد طوال دورة الطلبات

لتحليل الكتالوجات عالية التردد لـ Wildberries وOzon، حيث تكون سرعة تصفح آلاف الصفحات مهمة، غالبًا ما يتم دمج نوعين من البروكسي: بروكسي مراكز البيانات للطلبات الفنية الأولية (التحقق من الوصول، رموز الحالة) والسكنية - لجمع البيانات النهائية من البطاقات، حيث تكون التمويه كأنها مستخدم حقيقي أمرًا مهمًا. بالنسبة لتطبيقات الهواتف المحمولة للأسواق وAvito، قد تكون بروكسي الهواتف المحمولة أكثر فعالية، حيث أنها نادرًا ما تقع في قوائم الحظر التلقائي حسب ASN.

الخاتمة

يرتبط حظر المحلل على الخادم عند تشغيل النسخة المحلية غالبًا ليس بمنطق السكربت، بل بالبيئة: نوع IP، بصمة TLS، العناوين، المنطقة الزمنية، نمط الطلبات وإدارة الجلسات. من خلال التحقق من كل سبب من الأسباب السبعة بالترتيب - من الأكثر شيوعًا (IP مركز البيانات) إلى الأقل وضوحًا (عدم تطابق المنطقة الزمنية ومنطقة IP) - يمكن استعادة عمل المحلل بشكل مستقر دون تغيير منطق الأعمال الأساسي لجمع البيانات.

إذا كنت تجمع الأسعار والمخزونات على Wildberries أو Ozon أو Avito بكميات كبيرة، ابدأ بتغيير IP: جرب بروكسي سكنية بدلاً من عنوان VPS القياسي - في معظم الحالات، هذا يلغي حتى 70% من الحظر قبل أن تبدأ في ضبط العناوين وبصمات TLS.