خطأ 429 أثناء التحليل: 6 أسباب بخلاف البروكسي

هل تقوم بتغيير البروكسي، وشراء مجموعة جديدة من عناوين IP، ولكن المحلل لا يزال يسقط مع خطأ 429 Too Many Requests؟ هذه حالة كلاسيكية: 70% من حالات الحظر ليست مرتبطة بعنوان IP، بل بكيفية ظهور الطلب نفسه. نستعرض ستة أسباب حقيقية تجعل الموقع يستمر في حظرك حتى بعد تغيير البروكسي - وما يجب القيام به في كل حالة.

ماذا يعني خطأ 429 ولماذا البروكسي ليس حلاً سحريًا

رمز HTTP 429 Too Many Requests يعني رسميًا "تم تجاوز حد الطلبات". ولكن على أرض الواقع، تستخدم المواقع - خاصة Wildberries وOzon وAvito وYandex.Market - هذا الرمز كإشارة عالمية "نحن نعتقد أنك بوت". قد تكون السبب في تكرار الطلبات، ولكن بنفس الاحتمالية - في العناوين، بصمة المتصفح، عدم وجود جلسة كوكيز، أو في الحدود المرتبطة بحسابك وليس بعنوان IP الخاص بك.

لهذا السبب، غالبًا ما لا يساعد تغيير البروكسي: إذا كانت النظام تحظر ليس عنوان IP، بل نمط الطلب (البصمة، العناوين، سرعة النقرات)، فستحصل على نفس 429 من عنوان IP الجديد بعد بضع دقائق. دعونا نستعرض كل سبب بالتفصيل ونوضح كيفية التحقق منه وحله دون شراء مجموعة جديدة من البروكسي.

من المهم: تظل البروكسي أداة ضرورية - ولكن فقط كجزء من النظام، وليس كحل وحيد. تقلل عناوين IP السكنية والمحمولة من احتمال الدخول في القوائم السوداء بسبب سمعة IP، لكنها لا تحمي من الحظر بسبب السلوك أو العناوين.

السبب 1: تكرار الطلبات بشكل مفرط

السبب الأكثر وضوحًا، ولكنه أيضًا الأكثر تشخيصًا بشكل خاطئ. يعتقد الكثيرون: "طالما أغير البروكسي لكل طلب - فإن التكرار ليس مهمًا". هذا غير صحيح. تقوم أنظمة مكافحة البوت الحديثة (على سبيل المثال، تستخدم Wildberries وOzon حلولًا من مستوى Cloudflare أو WAF الخاص بها) بتحليل ليس فقط تكرار الطلبات من عنوان IP واحد، ولكن أيضًا الحمل الكلي على نقطة نهاية API أو صفحة المنتج في وحدة الزمن من جميع المصادر مع إشارات سلوكية.

إذا كان المحلل الخاص بك يقوم بـ 50-100 طلب في الثانية على نفس قسم الكتالوج، فإن النظام يرى زيادة غير طبيعية في حركة المرور بغض النظر عن عدد عناوين IP المختلفة التي تستخدمها. الحل ليس تغيير البروكسي، بل إدخال تأخيرات اصطناعية (throttling) بين الطلبات: 1-3 ثواني من التأخير العشوائي بدلاً من فترة ثابتة، بالإضافة إلى backoff أسي عند الحصول على 429 (زيادة فترة الانتظار بمقدار الضعف بعد كل حظر).

import time, random

def safe_request(session, url):
    for attempt in range(5):
        response = session.get(url)
        if response.status_code == 429:
            wait = (2 ** attempt) + random.uniform(0, 1)
            time.sleep(wait)
            continue
        return response
    return None

إذا كنت تستخدم محلل جاهز بدون كود (مثل خدمة مراقبة الأسعار السحابية)، تحقق من إعدادات الفاصل الزمني بين الطلبات - في معظم هذه الأدوات، يوجد شريط تمرير "سرعة المسح". غالبًا ما يؤدي تقليل السرعة بنسبة 30-40% إلى إزالة 429 تمامًا، حتى دون تغيير البروكسي.

السبب 2: عناوين غير صحيحة أو مفقودة

يرسل العديد من المحللين الطلبات بأقل مجموعة من العناوين أو يستخدمون User-Agent الخاص بالمكتبة بشكل افتراضي (مثل "python-requests/2.28.1"). هذا العنوان يكشف البوت على الفور - حيث يرسل المتصفح الحقيقي عشرات العناوين: Accept وAccept-Language وAccept-Encoding وSec-Fetch-* وReferer وغيرها بترتيب محدد بدقة.

تقوم Wildberries وOzon بمقارنة مجموعة العناوين مع "بصمة" المتصفح الحقيقي Chrome أو Safari. إذا كانت العناوين قليلة جدًا، أو ليست بالترتيب الصحيح، أو إذا كان User-Agent لا يتوافق مع المعلمات الأخرى (على سبيل المثال، تم الإبلاغ عن Chrome على Windows، ولكن بصمة TLS تشبه Python) - يتم حظر الطلب على 429 بغض النظر عن IP.

العنوان	خطأ شائع	الحل
User-Agent	إصدار قديم أو سلسلة مكتبية واضحة	UA حالي من Chrome/Safari الحقيقي، تدوير من المجموعة
Accept-Language	مفقود أو لا يتوافق مع الموقع الجغرافي لعنوان IP	ru-RU للأسواق الروسية
Referer	فارغ، على الرغم من أن الانتقال الحقيقي دائمًا مع Referer	تحديد الصفحة السابقة من الكتالوج
Sec-Fetch-*	مفقودة تمامًا (ليس عميل متصفح)	نسخ المجموعة الكاملة من DevTools من المتصفح الحقيقي

أسهل طريقة هي نسخ المجموعة الكاملة من العناوين من علامة Network في DevTools من المتصفح الحقيقي، بفتح الصفحة المطلوبة يدويًا، واستخدام هذه المجموعة بالضبط في المحلل - مع مراعاة ترتيب العناوين، إذا كانت المكتبة تسمح بذلك (مثل curl_cffi أو httpx مع ترتيب صريح).

السبب 3: عدم وجود تدوير للجلسات والكوكيز

خطأ غالبًا ما يتم تجاهله: يقوم المحلل بتغيير IP في كل طلب، ولكنه يستخدم نفس جلسة الكوكيز أو لا يحتفظ بالكوكيز على الإطلاق. يحصل المستخدم الحقيقي عند الزيارة الأولى على مجموعة من الكوكيز (رموز الجلسة، معرفات الجهاز، علامات حماية ضد البوت مثل Cloudflare __cf_bm أو ما يعادلها في Ozon/WB) ويستخدمها في جميع الطلبات اللاحقة ضمن الجلسة.

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

import requests

session = requests.Session()
session.headers.update({
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
    "Accept-Language": "ru-RU,ru;q=0.9"
})

# تسخين الجلسة
session.get("https://www.wildberries.ru/catalog/0/search.aspx")
time.sleep(1.5)

# الطلب الرئيسي مع الكوكيز
response = session.get(target_url)

إذا كنت تستخدم متصفحًا مضادًا للكشف مثل Dolphin Anty أو AdsPower لمراقبة بطاقات المنتجات يدويًا أو من خلال الأتمتة المدمجة، تأكد من أن الملف الشخصي يحتفظ بالكوكيز بين الجلسات ولا يبدأ كل مرة "من الصفر" - فهذا أيضًا يثير شكوك النظام.

السبب 4: سلوك مشابه للبوت

حتى مع العناوين المثالية والكوكيز، يمكن أن يظهر المحلل نفسه من خلال أنماط سلوكية: ترتيب صارم خطي للوصول إلى المنتجات (حسب زيادة ID)، نفس الفاصل الزمني بين الطلبات حتى المللي ثانية، عدم وجود "طلبات زائدة" للموارد الثابتة (صور، CSS، JS) التي يقوم المتصفح العادي بتحميلها تلقائيًا.

تقوم أنظمة الحماية المتقدمة في Wildberries وOzon بتحليل ليس فقط طلبات HTTP، ولكن أيضًا ما إذا تم تنفيذ JavaScript على الصفحة (من خلال اكتشاف headless)، هل كانت "الفأرة" تتحرك، هل كان هناك تمرير. إذا كنت تقوم بإجراء طلبات HTTP نظيفة دون تنفيذ JS، بينما يتوقع الموقع تنفيذ السكربت للحصول على رمز (على سبيل المثال، تحدي JavaScript ضد البوت)، فإن الطلب بدون تنفيذ هذا السكربت يحصل تلقائيًا على 429 أو 403.

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

السبب 5: بصمة TLS/JA3 وHTTP/2

هذه هي أكثر الأسباب التقنية "خفاءً"، التي لا يعرفها 90% من الأشخاص الذين يقومون بالتحليل دون إعداد تقني عميق. يترك كل عميل TLS (مكتبة requests، curl، urllib) بصمة فريدة عند إنشاء اتصال HTTPS - مجموعة من التشفيرات المدعومة، وإصدارات البروتوكول، وامتدادات TLS. تُعرف هذه البصمة باسم بصمة JA3/JA4.

تقوم أنظمة مكافحة البوت على مستوى Cloudflare وAkamai وحلول خاصة من الأسواق الكبيرة بمقارنة بصمة JA3 مع قاعدة بيانات معروفة للبوتات والمكتبات. تحتوي مكتبة Python requests القياسية أو وحدة https في Node.js على بصمة يمكن اكتشافها بسهولة، تختلف تمامًا عن بصمة Chrome الحقيقية. حتى مع العناوين المثالية والكوكيز، يتم حظر الطلب على مستوى TLS-handshake، قبل أن يرى الخادم عناوين HTTP.

بالإضافة إلى ذلك، تتطلب العديد من الأسواق HTTP/2 مع معلمات معينة (ترتيب إطارات SETTINGS، أولوية التدفقات) - تبرز المكتبات التي تعتمد على HTTP/1.1 تلقائيًا في هذا السياق. الحل هو استخدام المكتبات التي تحاكي بصمة المتصفح الحقيقي: curl_cffi (تحاكي بصمة TLS لـ Chrome)، tls-client، أو متصفحات headless كاملة تعتمد على Chromium، والتي تعطي بصمة "حقيقية" من حيث التعريف.

pip install curl_cffi

مثال: curl_cffi.requests.get(url, impersonate="chrome120") - تقوم المكتبة تلقائيًا بإدراج بصمة TLS، المطابقة لـ Chrome الحقيقي 120.

السبب 6: حد على مستوى الحساب أو مفتاح API

إذا كنت تعمل من خلال API رسمي أو شبه رسمي للسوق (مثل API بائع Wildberries أو Ozon Seller API)، فقد يكون 429 مرتبطًا ليس بعنوان IP، بل بحساب البائع نفسه أو رمز API. في هذه الحالة، فإن تغيير البروكسي يكون عديم الفائدة تمامًا - الحد يتم تخزينه على جانب الخادم مرتبطًا بمعرف حسابك، وأي IP من هذا الحساب سيحصل على نفس القيود.

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

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

كيف تشخص السبب الحقيقي

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

ثم قارن عناوين المحلل الخاص بك مع عناوين المتصفح الحقيقي من خلال DevTools (علامة Network → Copy as cURL). إذا كانت الفروق ضئيلة، تحقق من بصمة TLS من خلال خدمات مثل tls.peet.ws - أرسل طلبًا من مكتبتك وقارن هاش JA3 مع المتصفح المرجعي. إذا سقط الطلب في مرحلة TLS-handshake (تم قطع الاتصال قبل الحصول على استجابة HTTP) - فإن السبب في البصمة، وليس في التكرار أو العناوين.

بعد ذلك، تحقق مما إذا كان الحد مرتبطًا بعنوان IP أو بالحساب: قم بإجراء طلب من IP جديد نظيف بدون تفويض. إذا اختفى 429 - كانت المشكلة في سمعة عنوان IP السابق أو في التكرار من هذا العنوان. إذا استمر 429 - ابحث عن السبب في العناوين أو TLS أو السلوك، وليس في البروكسي.

قائمة فحص لحل 429 دون تغيير البروكسي

أضف تأخيرات عشوائية من 1-4 ثواني بين الطلبات بدلاً من فترة ثابتة.
انسخ المجموعة الكاملة من عناوين المتصفح الحقيقي، بما في ذلك Sec-Fetch-* وAccept-Language.
احفظ ومرر الكوكيز ضمن نفس الجلسة، بدءًا من تسخين الصفحة الرئيسية.
تحقق من بصمة TLS لمكتبتك - استخدم curl_cffi أو متصفح headless بدلاً من عميل HTTP النقي.
عشوائية ترتيب تصفح الصفحات وأضف طلبات "ضوضائية" للموارد الثابتة.
قم بتوزيع الحمل بين حساب API والمراقبة غير المصرح بها على تدفقات مختلفة.
قم بتنفيذ backoff أسي عند الحصول على 429، وليس إعادة الطلب على الفور.
فقط بعد التحقق من جميع النقاط المذكورة أعلاه - قم بتغيير البروكسي أو توسيع مجموعة IP.

متى تحتاج البروكسي وما الذي يجب اختياره

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

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

إذا كانت المهمة تتعلق بالتحقق من النسخة المحمولة من الموقع، أو العمل من خلال تطبيق السوق، أو اختبار الإعلانات في TikTok Ads وFacebook Ads بدقة جغرافية تصل إلى المدينة، فإن البروكسي المحمولة تكون مناسبة - حيث تتمتع بأعلى مستوى من الثقة لدى معظم أنظمة الحماية، لأن عناوين IP تعود لمشغلي الشبكات الحقيقية.

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

نوع البروكسي	متى يحل 429	متى لا يساعد
سكنية	IP موجود بالفعل في القائمة السوداء بسبب السمعة	حظر بسبب بصمة TLS أو العناوين
محمولة	تحتاج إلى أعلى مستوى من ثقة IP للسيناريوهات الحساسة	الحد مرتبط بالحساب، وليس بـ IP
مركز البيانات	تحليل بسيط للصفحات المفتوحة دون تفويض	أنظمة مكافحة البوت الصارمة مع التحقق من سمعة النطاقات

الخاتمة

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

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